79 lines
2.6 KiB
Plaintext
79 lines
2.6 KiB
Plaintext
|
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
|
||
|
|
|