| Raghavendra K T | fc16123 | 2012-08-07 13:09:59 +0530 | [diff] [blame] | 1 | Linux KVM Hypercall: |
| 2 | =================== |
| 3 | X86: |
| 4 | KVM Hypercalls have a three-byte sequence of either the vmcall or the vmmcall |
| 5 | instruction. The hypervisor can replace it with instructions that are |
| 6 | guaranteed to be supported. |
| 7 | |
| 8 | Up to four arguments may be passed in rbx, rcx, rdx, and rsi respectively. |
| 9 | The hypercall number should be placed in rax and the return value will be |
| 10 | placed in rax. No other registers will be clobbered unless explicitly stated |
| 11 | by the particular hypercall. |
| 12 | |
| 13 | S390: |
| 14 | R2-R7 are used for parameters 1-6. In addition, R1 is used for hypercall |
| 15 | number. The return value is written to R2. |
| 16 | |
| 17 | S390 uses diagnose instruction as hypercall (0x500) along with hypercall |
| 18 | number in R1. |
| 19 | |
| 20 | PowerPC: |
| 21 | It uses R3-R10 and hypercall number in R11. R4-R11 are used as output registers. |
| 22 | Return value is placed in R3. |
| 23 | |
| 24 | KVM hypercalls uses 4 byte opcode, that are patched with 'hypercall-instructions' |
| 25 | property inside the device tree's /hypervisor node. |
| 26 | For more information refer to Documentation/virtual/kvm/ppc-pv.txt |
| 27 | |
| 28 | KVM Hypercalls Documentation |
| 29 | =========================== |
| 30 | The template for each hypercall is: |
| 31 | 1. Hypercall name. |
| 32 | 2. Architecture(s) |
| 33 | 3. Status (deprecated, obsolete, active) |
| 34 | 4. Purpose |
| 35 | |
| 36 | 1. KVM_HC_VAPIC_POLL_IRQ |
| 37 | ------------------------ |
| 38 | Architecture: x86 |
| 39 | Status: active |
| 40 | Purpose: Trigger guest exit so that the host can check for pending |
| 41 | interrupts on reentry. |
| 42 | |
| 43 | 2. KVM_HC_MMU_OP |
| 44 | ------------------------ |
| 45 | Architecture: x86 |
| 46 | Status: deprecated. |
| 47 | Purpose: Support MMU operations such as writing to PTE, |
| 48 | flushing TLB, release PT. |
| 49 | |
| 50 | 3. KVM_HC_FEATURES |
| 51 | ------------------------ |
| 52 | Architecture: PPC |
| 53 | Status: active |
| 54 | Purpose: Expose hypercall availability to the guest. On x86 platforms, cpuid |
| 55 | used to enumerate which hypercalls are available. On PPC, either device tree |
| 56 | based lookup ( which is also what EPAPR dictates) OR KVM specific enumeration |
| 57 | mechanism (which is this hypercall) can be used. |
| 58 | |
| 59 | 4. KVM_HC_PPC_MAP_MAGIC_PAGE |
| 60 | ------------------------ |
| 61 | Architecture: PPC |
| 62 | Status: active |
| 63 | Purpose: To enable communication between the hypervisor and guest there is a |
| 64 | shared page that contains parts of supervisor visible register state. |
| 65 | The guest can map this shared page to access its supervisor register through |
| 66 | memory using this hypercall. |
| Raghavendra K T | 9bc6cbe | 2013-08-26 14:18:36 +0530 | [diff] [blame] | 67 | |
| 68 | 5. KVM_HC_KICK_CPU |
| 69 | ------------------------ |
| 70 | Architecture: x86 |
| 71 | Status: active |
| 72 | Purpose: Hypercall used to wakeup a vcpu from HLT state |
| 73 | Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest |
| 74 | kernel mode for an event to occur (ex: a spinlock to become available) can |
| 75 | execute HLT instruction once it has busy-waited for more than a threshold |
| 76 | time-interval. Execution of HLT instruction would cause the hypervisor to put |
| 77 | the vcpu to sleep until occurence of an appropriate event. Another vcpu of the |
| 78 | same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall, |
| 79 | specifying APIC ID (a1) of the vcpu to be woken up. An additional argument (a0) |
| 80 | is used in the hypercall for future use. |