ppc-spapr-hcalls.txt (2680B)
1When used with the "pseries" machine type, QEMU-system-ppc64 implements 2a set of hypervisor calls using a subset of the server "PAPR" specification 3(IBM internal at this point), which is also what IBM's proprietary hypervisor 4adheres too. 5 6The subset is selected based on the requirements of Linux as a guest. 7 8In addition to those calls, we have added our own private hypervisor 9calls which are mostly used as a private interface between the firmware 10running in the guest and QEMU. 11 12All those hypercalls start at hcall number 0xf000 which correspond 13to an implementation specific range in PAPR. 14 15- H_RTAS (0xf000) 16 17RTAS is a set of runtime services generally provided by the firmware 18inside the guest to the operating system. It predates the existence 19of hypervisors (it was originally an extension to Open Firmware) and 20is still used by PAPR to provide various services that aren't performance 21sensitive. 22 23We currently implement the RTAS services in QEMU itself. The actual RTAS 24"firmware" blob in the guest is a small stub of a few instructions which 25calls our private H_RTAS hypervisor call to pass the RTAS calls to QEMU. 26 27Arguments: 28 29 r3 : H_RTAS (0xf000) 30 r4 : Guest physical address of RTAS parameter block 31 32Returns: 33 34 H_SUCCESS : Successfully called the RTAS function (RTAS result 35 will have been stored in the parameter block) 36 H_PARAMETER : Unknown token 37 38- H_LOGICAL_MEMOP (0xf001) 39 40When the guest runs in "real mode" (in powerpc lingua this means 41with MMU disabled, ie guest effective == guest physical), it only 42has access to a subset of memory and no IOs. 43 44PAPR provides a set of hypervisor calls to perform cacheable or 45non-cacheable accesses to any guest physical addresses that the 46guest can use in order to access IO devices while in real mode. 47 48This is typically used by the firmware running in the guest. 49 50However, doing a hypercall for each access is extremely inefficient 51(even more so when running KVM) when accessing the frame buffer. In 52that case, things like scrolling become unusably slow. 53 54This hypercall allows the guest to request a "memory op" to be applied 55to memory. The supported memory ops at this point are to copy a range 56of memory (supports overlap of source and destination) and XOR which 57is used by our SLOF firmware to invert the screen. 58 59Arguments: 60 61 r3: H_LOGICAL_MEMOP (0xf001) 62 r4: Guest physical address of destination 63 r5: Guest physical address of source 64 r6: Individual element size 65 0 = 1 byte 66 1 = 2 bytes 67 2 = 4 bytes 68 3 = 8 bytes 69 r7: Number of elements 70 r8: Operation 71 0 = copy 72 1 = xor 73 74Returns: 75 76 H_SUCCESS : Success 77 H_PARAMETER : Invalid argument 78