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 | ||
d9101fca CH |
20 | For further information on the S390 diagnose call as supported by KVM, |
21 | refer to Documentation/virtual/kvm/s390-diag.txt. | |
22 | ||
fc161239 R |
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 | ||
955d8dc3 JH |
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 | ||
fc161239 R |
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. | |
9bc6cbeb R |
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 | |
17180032 | 85 | the vcpu to sleep until occurrence of an appropriate event. Another vcpu of the |
9bc6cbeb R |
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. | |
55dd00a7 MT |
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. | |
4180bf1b WL |
124 | |
125 | 6. KVM_HC_SEND_IPI | |
126 | ------------------------ | |
127 | Architecture: x86 | |
128 | Status: active | |
129 | Purpose: Send IPIs to multiple vCPUs. | |
130 | ||
131 | a0: lower part of the bitmap of destination APIC IDs | |
132 | a1: higher part of the bitmap of destination APIC IDs | |
133 | a2: the lowest APIC ID in bitmap | |
134 | a3: APIC ICR | |
135 | ||
136 | The hypercall lets a guest send multicast IPIs, with at most 128 | |
137 | 128 destinations per hypercall in 64-bit mode and 64 vCPUs per | |
138 | hypercall in 32-bit mode. The destinations are represented by a | |
139 | bitmap contained in the first two arguments (a0 and a1). Bit 0 of | |
140 | a0 corresponds to the APIC ID in the third argument (a2), bit 1 | |
141 | corresponds to the APIC ID a2+1, and so on. | |
142 | ||
143 | Returns the number of CPUs to which the IPIs were delivered successfully. |