projects / mirror_qemu.git / blame
| Commit | Line | Data |
|---|---|---|
| c73e3771 BH |
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 | |
| 9277d81f | 13 | to an implementation specific range in PAPR. |
| c73e3771 BH |
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 | ||
| 0546b8c2 | 34 | H_SUCCESS : Successfully called the RTAS function (RTAS result |
| c73e3771 BH |
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 | ||
| 67cc32eb VL |
44 | PAPR provides a set of hypervisor calls to perform cacheable or |
| 45 | non-cacheable accesses to any guest physical addresses that the | |
| c73e3771 BH |
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 |