| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980 |
- Linux KVM Hypercall:
- ===================
- X86:
- KVM Hypercalls have a three-byte sequence of either the vmcall or the vmmcall
- instruction. The hypervisor can replace it with instructions that are
- guaranteed to be supported.
- Up to four arguments may be passed in rbx, rcx, rdx, and rsi respectively.
- The hypercall number should be placed in rax and the return value will be
- placed in rax. No other registers will be clobbered unless explicitly stated
- by the particular hypercall.
- S390:
- R2-R7 are used for parameters 1-6. In addition, R1 is used for hypercall
- number. The return value is written to R2.
- S390 uses diagnose instruction as hypercall (0x500) along with hypercall
- number in R1.
- PowerPC:
- It uses R3-R10 and hypercall number in R11. R4-R11 are used as output registers.
- Return value is placed in R3.
- KVM hypercalls uses 4 byte opcode, that are patched with 'hypercall-instructions'
- property inside the device tree's /hypervisor node.
- For more information refer to Documentation/virtual/kvm/ppc-pv.txt
- KVM Hypercalls Documentation
- ===========================
- The template for each hypercall is:
- 1. Hypercall name.
- 2. Architecture(s)
- 3. Status (deprecated, obsolete, active)
- 4. Purpose
- 1. KVM_HC_VAPIC_POLL_IRQ
- ------------------------
- Architecture: x86
- Status: active
- Purpose: Trigger guest exit so that the host can check for pending
- interrupts on reentry.
- 2. KVM_HC_MMU_OP
- ------------------------
- Architecture: x86
- Status: deprecated.
- Purpose: Support MMU operations such as writing to PTE,
- flushing TLB, release PT.
- 3. KVM_HC_FEATURES
- ------------------------
- Architecture: PPC
- Status: active
- Purpose: Expose hypercall availability to the guest. On x86 platforms, cpuid
- used to enumerate which hypercalls are available. On PPC, either device tree
- based lookup ( which is also what EPAPR dictates) OR KVM specific enumeration
- mechanism (which is this hypercall) can be used.
- 4. KVM_HC_PPC_MAP_MAGIC_PAGE
- ------------------------
- Architecture: PPC
- Status: active
- Purpose: To enable communication between the hypervisor and guest there is a
- shared page that contains parts of supervisor visible register state.
- The guest can map this shared page to access its supervisor register through
- memory using this hypercall.
- 5. KVM_HC_KICK_CPU
- ------------------------
- Architecture: x86
- Status: active
- Purpose: Hypercall used to wakeup a vcpu from HLT state
- Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
- kernel mode for an event to occur (ex: a spinlock to become available) can
- execute HLT instruction once it has busy-waited for more than a threshold
- time-interval. Execution of HLT instruction would cause the hypervisor to put
- the vcpu to sleep until occurence of an appropriate event. Another vcpu of the
- same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall,
- specifying APIC ID (a1) of the vcpu to be woken up. An additional argument (a0)
- is used in the hypercall for future use.
|
