projects / deliverable / linux.git / blame
| Commit | Line | Data |
|---|---|---|
| fc161239 R |
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. | |
| 9bc6cbeb R |
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. |