rjw | 1f88458 | 2022-01-06 17:20:42 +0800 | [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 | For further information on the S390 diagnose call as supported by KVM, |
| 21 | refer to Documentation/virtual/kvm/s390-diag.txt. |
| 22 | |
| 23 | PowerPC: |
| 24 | It uses R3-R10 and hypercall number in R11. R4-R11 are used as output registers. |
| 25 | Return value is placed in R3. |
| 26 | |
| 27 | KVM hypercalls uses 4 byte opcode, that are patched with 'hypercall-instructions' |
| 28 | property inside the device tree's /hypervisor node. |
| 29 | For more information refer to Documentation/virtual/kvm/ppc-pv.txt |
| 30 | |
| 31 | MIPS: |
| 32 | KVM hypercalls use the HYPCALL instruction with code 0 and the hypercall |
| 33 | number in $2 (v0). Up to four arguments may be placed in $4-$7 (a0-a3) and |
| 34 | the return value is placed in $2 (v0). |
| 35 | |
| 36 | KVM Hypercalls Documentation |
| 37 | =========================== |
| 38 | The template for each hypercall is: |
| 39 | 1. Hypercall name. |
| 40 | 2. Architecture(s) |
| 41 | 3. Status (deprecated, obsolete, active) |
| 42 | 4. Purpose |
| 43 | |
| 44 | 1. KVM_HC_VAPIC_POLL_IRQ |
| 45 | ------------------------ |
| 46 | Architecture: x86 |
| 47 | Status: active |
| 48 | Purpose: Trigger guest exit so that the host can check for pending |
| 49 | interrupts on reentry. |
| 50 | |
| 51 | 2. KVM_HC_MMU_OP |
| 52 | ------------------------ |
| 53 | Architecture: x86 |
| 54 | Status: deprecated. |
| 55 | Purpose: Support MMU operations such as writing to PTE, |
| 56 | flushing TLB, release PT. |
| 57 | |
| 58 | 3. KVM_HC_FEATURES |
| 59 | ------------------------ |
| 60 | Architecture: PPC |
| 61 | Status: active |
| 62 | Purpose: Expose hypercall availability to the guest. On x86 platforms, cpuid |
| 63 | used to enumerate which hypercalls are available. On PPC, either device tree |
| 64 | based lookup ( which is also what EPAPR dictates) OR KVM specific enumeration |
| 65 | mechanism (which is this hypercall) can be used. |
| 66 | |
| 67 | 4. KVM_HC_PPC_MAP_MAGIC_PAGE |
| 68 | ------------------------ |
| 69 | Architecture: PPC |
| 70 | Status: active |
| 71 | Purpose: To enable communication between the hypervisor and guest there is a |
| 72 | shared page that contains parts of supervisor visible register state. |
| 73 | The guest can map this shared page to access its supervisor register through |
| 74 | memory using this hypercall. |
| 75 | |
| 76 | 5. KVM_HC_KICK_CPU |
| 77 | ------------------------ |
| 78 | Architecture: x86 |
| 79 | Status: active |
| 80 | Purpose: Hypercall used to wakeup a vcpu from HLT state |
| 81 | Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest |
| 82 | kernel mode for an event to occur (ex: a spinlock to become available) can |
| 83 | execute HLT instruction once it has busy-waited for more than a threshold |
| 84 | time-interval. Execution of HLT instruction would cause the hypervisor to put |
| 85 | the vcpu to sleep until occurrence of an appropriate event. Another vcpu of the |
| 86 | same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall, |
| 87 | specifying APIC ID (a1) of the vcpu to be woken up. An additional argument (a0) |
| 88 | is used in the hypercall for future use. |
| 89 | |
| 90 | |
| 91 | 6. KVM_HC_CLOCK_PAIRING |
| 92 | ------------------------ |
| 93 | Architecture: x86 |
| 94 | Status: active |
| 95 | Purpose: Hypercall used to synchronize host and guest clocks. |
| 96 | Usage: |
| 97 | |
| 98 | a0: guest physical address where host copies |
| 99 | "struct kvm_clock_offset" structure. |
| 100 | |
| 101 | a1: clock_type, ATM only KVM_CLOCK_PAIRING_WALLCLOCK (0) |
| 102 | is supported (corresponding to the host's CLOCK_REALTIME clock). |
| 103 | |
| 104 | struct kvm_clock_pairing { |
| 105 | __s64 sec; |
| 106 | __s64 nsec; |
| 107 | __u64 tsc; |
| 108 | __u32 flags; |
| 109 | __u32 pad[9]; |
| 110 | }; |
| 111 | |
| 112 | Where: |
| 113 | * sec: seconds from clock_type clock. |
| 114 | * nsec: nanoseconds from clock_type clock. |
| 115 | * tsc: guest TSC value used to calculate sec/nsec pair |
| 116 | * flags: flags, unused (0) at the moment. |
| 117 | |
| 118 | The hypercall lets a guest compute a precise timestamp across |
| 119 | host and guest. The guest can use the returned TSC value to |
| 120 | compute the CLOCK_REALTIME for its clock, at the same instant. |
| 121 | |
| 122 | Returns KVM_EOPNOTSUPP if the host does not use TSC clocksource, |
| 123 | or if clock type is different than KVM_CLOCK_PAIRING_WALLCLOCK. |