| 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. |