Benjamin Herrenschmidt | c73e377 | 2012-06-18 20:21:37 +0000 | [diff] [blame] | 1 | When used with the "pseries" machine type, QEMU-system-ppc64 implements |
| 2 | a 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 |
| 4 | adheres too. |
| 5 | |
| 6 | The subset is selected based on the requirements of Linux as a guest. |
| 7 | |
| 8 | In addition to those calls, we have added our own private hypervisor |
| 9 | calls which are mostly used as a private interface between the firmware |
| 10 | running in the guest and QEMU. |
| 11 | |
| 12 | All those hypercalls start at hcall number 0xf000 which correspond |
| 13 | to a implementation specific range in PAPR. |
| 14 | |
| 15 | - H_RTAS (0xf000) |
| 16 | |
| 17 | RTAS is a set of runtime services generally provided by the firmware |
| 18 | inside the guest to the operating system. It predates the existence |
| 19 | of hypervisors (it was originally an extension to Open Firmware) and |
| 20 | is still used by PAPR to provide various services that aren't performance |
| 21 | sensitive. |
| 22 | |
| 23 | We 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 |
| 25 | calls our private H_RTAS hypervisor call to pass the RTAS calls to QEMU. |
| 26 | |
| 27 | Arguments: |
| 28 | |
| 29 | r3 : H_RTAS (0xf000) |
| 30 | r4 : Guest physical address of RTAS parameter block |
| 31 | |
| 32 | Returns: |
| 33 | |
| 34 | H_SUCCESS : Successully 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 | |
| 40 | When the guest runs in "real mode" (in powerpc lingua this means |
| 41 | with MMU disabled, ie guest effective == guest physical), it only |
| 42 | has access to a subset of memory and no IOs. |
| 43 | |
| 44 | PAPR provides a set of hypervisor calls to perform cachable or |
| 45 | non-cachable accesses to any guest physical addresses that the |
| 46 | guest can use in order to access IO devices while in real mode. |
| 47 | |
| 48 | This is typically used by the firmware running in the guest. |
| 49 | |
| 50 | However, doing a hypercall for each access is extremely inefficient |
| 51 | (even more so when running KVM) when accessing the frame buffer. In |
| 52 | that case, things like scrolling become unusably slow. |
| 53 | |
| 54 | This hypercall allows the guest to request a "memory op" to be applied |
| 55 | to memory. The supported memory ops at this point are to copy a range |
| 56 | of memory (supports overlap of source and destination) and XOR which |
| 57 | is used by our SLOF firmware to invert the screen. |
| 58 | |
| 59 | Arguments: |
| 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 | |
| 74 | Returns: |
| 75 | |
| 76 | H_SUCCESS : Success |
| 77 | H_PARAMETER : Invalid argument |
| 78 | |