| When used with the "pseries" machine type, QEMU-system-ppc64 implements |
| a set of hypervisor calls using a subset of the server "PAPR" specification |
| (IBM internal at this point), which is also what IBM's proprietary hypervisor |
| adheres too. |
| |
| The subset is selected based on the requirements of Linux as a guest. |
| |
| In addition to those calls, we have added our own private hypervisor |
| calls which are mostly used as a private interface between the firmware |
| running in the guest and QEMU. |
| |
| All those hypercalls start at hcall number 0xf000 which correspond |
| to a implementation specific range in PAPR. |
| |
| - H_RTAS (0xf000) |
| |
| RTAS is a set of runtime services generally provided by the firmware |
| inside the guest to the operating system. It predates the existence |
| of hypervisors (it was originally an extension to Open Firmware) and |
| is still used by PAPR to provide various services that aren't performance |
| sensitive. |
| |
| We currently implement the RTAS services in QEMU itself. The actual RTAS |
| "firmware" blob in the guest is a small stub of a few instructions which |
| calls our private H_RTAS hypervisor call to pass the RTAS calls to QEMU. |
| |
| Arguments: |
| |
| r3 : H_RTAS (0xf000) |
| r4 : Guest physical address of RTAS parameter block |
| |
| Returns: |
| |
| H_SUCCESS : Successfully called the RTAS function (RTAS result |
| will have been stored in the parameter block) |
| H_PARAMETER : Unknown token |
| |
| - H_LOGICAL_MEMOP (0xf001) |
| |
| When the guest runs in "real mode" (in powerpc lingua this means |
| with MMU disabled, ie guest effective == guest physical), it only |
| has access to a subset of memory and no IOs. |
| |
| PAPR provides a set of hypervisor calls to perform cachable or |
| non-cachable accesses to any guest physical addresses that the |
| guest can use in order to access IO devices while in real mode. |
| |
| This is typically used by the firmware running in the guest. |
| |
| However, doing a hypercall for each access is extremely inefficient |
| (even more so when running KVM) when accessing the frame buffer. In |
| that case, things like scrolling become unusably slow. |
| |
| This hypercall allows the guest to request a "memory op" to be applied |
| to memory. The supported memory ops at this point are to copy a range |
| of memory (supports overlap of source and destination) and XOR which |
| is used by our SLOF firmware to invert the screen. |
| |
| Arguments: |
| |
| r3: H_LOGICAL_MEMOP (0xf001) |
| r4: Guest physical address of destination |
| r5: Guest physical address of source |
| r6: Individual element size |
| 0 = 1 byte |
| 1 = 2 bytes |
| 2 = 4 bytes |
| 3 = 8 bytes |
| r7: Number of elements |
| r8: Operation |
| 0 = copy |
| 1 = xor |
| |
| Returns: |
| |
| H_SUCCESS : Success |
| H_PARAMETER : Invalid argument |
| |
