mirrors/qemu
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
c5f048d8fb
qemu/docs/specs/ppc-spapr-hcalls.txt

79 lines
2.6 KiB
Plaintext
Raw Normal View History

spapr: Add "memop" hypercall This adds a qemu-specific hypervisor call to the pseries machine which allows to do what amounts to memmove, memcpy and xor over regions of physical memory such as the framebuffer. This is the simplest way to get usable framebuffer speed from SLOF since the framebuffer isn't mapped in the VRMA and so would otherwise require an hcall per 8 bytes access. The performance is still not great but usable, and can be improved with a more complex implementation of the hcall itself if needed. This also adds some documentation for the qemu-specific hypercalls that we add to PAPR along with a new qemu,hypertas-functions property that mirrors ibm,hypertas-functions and provides some discoverability for the new calls. Note: I chose note to advertise H_RTAS to the guest via that mechanism. This is done on purpose, the guest uses the normal RTAS interfaces provided by qemu (including SLOF) which internally calls H_RTAS. We might in the future implement part (or even all) of RTAS inside the guest like IBM's firmware does and replace H_RTAS with some finer grained set of private hypercalls. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Alexander Graf <agraf@suse.de>
2012-06-19 00:21:37 +04:00
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:
Spelling fixes in comments and documentation These wrong spellings were detected by codespell: * successully -> successfully * alot -> a lot * wanna -> want to * infomation -> information * occured -> occurred ["also is" -> "is also" and "ressources" -> "resources" suggested by Peter Maydell <peter.maydell@linaro.org>] Signed-off-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2012-08-11 00:03:25 +04:00
H_SUCCESS : Successfully called the RTAS function (RTAS result
spapr: Add "memop" hypercall This adds a qemu-specific hypervisor call to the pseries machine which allows to do what amounts to memmove, memcpy and xor over regions of physical memory such as the framebuffer. This is the simplest way to get usable framebuffer speed from SLOF since the framebuffer isn't mapped in the VRMA and so would otherwise require an hcall per 8 bytes access. The performance is still not great but usable, and can be improved with a more complex implementation of the hcall itself if needed. This also adds some documentation for the qemu-specific hypercalls that we add to PAPR along with a new qemu,hypertas-functions property that mirrors ibm,hypertas-functions and provides some discoverability for the new calls. Note: I chose note to advertise H_RTAS to the guest via that mechanism. This is done on purpose, the guest uses the normal RTAS interfaces provided by qemu (including SLOF) which internally calls H_RTAS. We might in the future implement part (or even all) of RTAS inside the guest like IBM's firmware does and replace H_RTAS with some finer grained set of private hypercalls. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Alexander Graf <agraf@suse.de>
2012-06-19 00:21:37 +04:00
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.
typofixes - v4 Signed-off-by: Veres Lajos <vlajos@gmail.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2015-09-09 00:45:14 +03:00
PAPR provides a set of hypervisor calls to perform cacheable or
non-cacheable accesses to any guest physical addresses that the
spapr: Add "memop" hypercall This adds a qemu-specific hypervisor call to the pseries machine which allows to do what amounts to memmove, memcpy and xor over regions of physical memory such as the framebuffer. This is the simplest way to get usable framebuffer speed from SLOF since the framebuffer isn't mapped in the VRMA and so would otherwise require an hcall per 8 bytes access. The performance is still not great but usable, and can be improved with a more complex implementation of the hcall itself if needed. This also adds some documentation for the qemu-specific hypercalls that we add to PAPR along with a new qemu,hypertas-functions property that mirrors ibm,hypertas-functions and provides some discoverability for the new calls. Note: I chose note to advertise H_RTAS to the guest via that mechanism. This is done on purpose, the guest uses the normal RTAS interfaces provided by qemu (including SLOF) which internally calls H_RTAS. We might in the future implement part (or even all) of RTAS inside the guest like IBM's firmware does and replace H_RTAS with some finer grained set of private hypercalls. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Alexander Graf <agraf@suse.de>
2012-06-19 00:21:37 +04:00
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
Reference in New Issue Copy Permalink