docs/specs/ppc-spapr-hcalls.txt

   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   : Successfully 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