xref: /OK3568_Linux_fs/kernel/Documentation/virt/kvm/hypercalls.rst (revision 4882a59341e53eb6f0b4789bf948001014eff981)
1*4882a593Smuzhiyun.. SPDX-License-Identifier: GPL-2.0
2*4882a593Smuzhiyun
3*4882a593Smuzhiyun===================
4*4882a593SmuzhiyunLinux KVM Hypercall
5*4882a593Smuzhiyun===================
6*4882a593Smuzhiyun
7*4882a593SmuzhiyunX86:
8*4882a593Smuzhiyun KVM Hypercalls have a three-byte sequence of either the vmcall or the vmmcall
9*4882a593Smuzhiyun instruction. The hypervisor can replace it with instructions that are
10*4882a593Smuzhiyun guaranteed to be supported.
11*4882a593Smuzhiyun
12*4882a593Smuzhiyun Up to four arguments may be passed in rbx, rcx, rdx, and rsi respectively.
13*4882a593Smuzhiyun The hypercall number should be placed in rax and the return value will be
14*4882a593Smuzhiyun placed in rax.  No other registers will be clobbered unless explicitly stated
15*4882a593Smuzhiyun by the particular hypercall.
16*4882a593Smuzhiyun
17*4882a593SmuzhiyunS390:
18*4882a593Smuzhiyun  R2-R7 are used for parameters 1-6. In addition, R1 is used for hypercall
19*4882a593Smuzhiyun  number. The return value is written to R2.
20*4882a593Smuzhiyun
21*4882a593Smuzhiyun  S390 uses diagnose instruction as hypercall (0x500) along with hypercall
22*4882a593Smuzhiyun  number in R1.
23*4882a593Smuzhiyun
24*4882a593Smuzhiyun  For further information on the S390 diagnose call as supported by KVM,
25*4882a593Smuzhiyun  refer to Documentation/virt/kvm/s390-diag.rst.
26*4882a593Smuzhiyun
27*4882a593SmuzhiyunPowerPC:
28*4882a593Smuzhiyun  It uses R3-R10 and hypercall number in R11. R4-R11 are used as output registers.
29*4882a593Smuzhiyun  Return value is placed in R3.
30*4882a593Smuzhiyun
31*4882a593Smuzhiyun  KVM hypercalls uses 4 byte opcode, that are patched with 'hypercall-instructions'
32*4882a593Smuzhiyun  property inside the device tree's /hypervisor node.
33*4882a593Smuzhiyun  For more information refer to Documentation/virt/kvm/ppc-pv.rst
34*4882a593Smuzhiyun
35*4882a593SmuzhiyunMIPS:
36*4882a593Smuzhiyun  KVM hypercalls use the HYPCALL instruction with code 0 and the hypercall
37*4882a593Smuzhiyun  number in $2 (v0). Up to four arguments may be placed in $4-$7 (a0-a3) and
38*4882a593Smuzhiyun  the return value is placed in $2 (v0).
39*4882a593Smuzhiyun
40*4882a593SmuzhiyunKVM Hypercalls Documentation
41*4882a593Smuzhiyun============================
42*4882a593Smuzhiyun
43*4882a593SmuzhiyunThe template for each hypercall is:
44*4882a593Smuzhiyun1. Hypercall name.
45*4882a593Smuzhiyun2. Architecture(s)
46*4882a593Smuzhiyun3. Status (deprecated, obsolete, active)
47*4882a593Smuzhiyun4. Purpose
48*4882a593Smuzhiyun
49*4882a593Smuzhiyun1. KVM_HC_VAPIC_POLL_IRQ
50*4882a593Smuzhiyun------------------------
51*4882a593Smuzhiyun
52*4882a593Smuzhiyun:Architecture: x86
53*4882a593Smuzhiyun:Status: active
54*4882a593Smuzhiyun:Purpose: Trigger guest exit so that the host can check for pending
55*4882a593Smuzhiyun          interrupts on reentry.
56*4882a593Smuzhiyun
57*4882a593Smuzhiyun2. KVM_HC_MMU_OP
58*4882a593Smuzhiyun----------------
59*4882a593Smuzhiyun
60*4882a593Smuzhiyun:Architecture: x86
61*4882a593Smuzhiyun:Status: deprecated.
62*4882a593Smuzhiyun:Purpose: Support MMU operations such as writing to PTE,
63*4882a593Smuzhiyun          flushing TLB, release PT.
64*4882a593Smuzhiyun
65*4882a593Smuzhiyun3. KVM_HC_FEATURES
66*4882a593Smuzhiyun------------------
67*4882a593Smuzhiyun
68*4882a593Smuzhiyun:Architecture: PPC
69*4882a593Smuzhiyun:Status: active
70*4882a593Smuzhiyun:Purpose: Expose hypercall availability to the guest. On x86 platforms, cpuid
71*4882a593Smuzhiyun          used to enumerate which hypercalls are available. On PPC, either
72*4882a593Smuzhiyun	  device tree based lookup ( which is also what EPAPR dictates)
73*4882a593Smuzhiyun	  OR KVM specific enumeration mechanism (which is this hypercall)
74*4882a593Smuzhiyun	  can be used.
75*4882a593Smuzhiyun
76*4882a593Smuzhiyun4. KVM_HC_PPC_MAP_MAGIC_PAGE
77*4882a593Smuzhiyun----------------------------
78*4882a593Smuzhiyun
79*4882a593Smuzhiyun:Architecture: PPC
80*4882a593Smuzhiyun:Status: active
81*4882a593Smuzhiyun:Purpose: To enable communication between the hypervisor and guest there is a
82*4882a593Smuzhiyun	  shared page that contains parts of supervisor visible register state.
83*4882a593Smuzhiyun	  The guest can map this shared page to access its supervisor register
84*4882a593Smuzhiyun	  through memory using this hypercall.
85*4882a593Smuzhiyun
86*4882a593Smuzhiyun5. KVM_HC_KICK_CPU
87*4882a593Smuzhiyun------------------
88*4882a593Smuzhiyun
89*4882a593Smuzhiyun:Architecture: x86
90*4882a593Smuzhiyun:Status: active
91*4882a593Smuzhiyun:Purpose: Hypercall used to wakeup a vcpu from HLT state
92*4882a593Smuzhiyun:Usage example:
93*4882a593Smuzhiyun  A vcpu of a paravirtualized guest that is busywaiting in guest
94*4882a593Smuzhiyun  kernel mode for an event to occur (ex: a spinlock to become available) can
95*4882a593Smuzhiyun  execute HLT instruction once it has busy-waited for more than a threshold
96*4882a593Smuzhiyun  time-interval. Execution of HLT instruction would cause the hypervisor to put
97*4882a593Smuzhiyun  the vcpu to sleep until occurrence of an appropriate event. Another vcpu of the
98*4882a593Smuzhiyun  same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall,
99*4882a593Smuzhiyun  specifying APIC ID (a1) of the vcpu to be woken up. An additional argument (a0)
100*4882a593Smuzhiyun  is used in the hypercall for future use.
101*4882a593Smuzhiyun
102*4882a593Smuzhiyun
103*4882a593Smuzhiyun6. KVM_HC_CLOCK_PAIRING
104*4882a593Smuzhiyun-----------------------
105*4882a593Smuzhiyun:Architecture: x86
106*4882a593Smuzhiyun:Status: active
107*4882a593Smuzhiyun:Purpose: Hypercall used to synchronize host and guest clocks.
108*4882a593Smuzhiyun
109*4882a593SmuzhiyunUsage:
110*4882a593Smuzhiyun
111*4882a593Smuzhiyuna0: guest physical address where host copies
112*4882a593Smuzhiyun"struct kvm_clock_offset" structure.
113*4882a593Smuzhiyun
114*4882a593Smuzhiyuna1: clock_type, ATM only KVM_CLOCK_PAIRING_WALLCLOCK (0)
115*4882a593Smuzhiyunis supported (corresponding to the host's CLOCK_REALTIME clock).
116*4882a593Smuzhiyun
117*4882a593Smuzhiyun       ::
118*4882a593Smuzhiyun
119*4882a593Smuzhiyun		struct kvm_clock_pairing {
120*4882a593Smuzhiyun			__s64 sec;
121*4882a593Smuzhiyun			__s64 nsec;
122*4882a593Smuzhiyun			__u64 tsc;
123*4882a593Smuzhiyun			__u32 flags;
124*4882a593Smuzhiyun			__u32 pad[9];
125*4882a593Smuzhiyun		};
126*4882a593Smuzhiyun
127*4882a593Smuzhiyun       Where:
128*4882a593Smuzhiyun               * sec: seconds from clock_type clock.
129*4882a593Smuzhiyun               * nsec: nanoseconds from clock_type clock.
130*4882a593Smuzhiyun               * tsc: guest TSC value used to calculate sec/nsec pair
131*4882a593Smuzhiyun               * flags: flags, unused (0) at the moment.
132*4882a593Smuzhiyun
133*4882a593SmuzhiyunThe hypercall lets a guest compute a precise timestamp across
134*4882a593Smuzhiyunhost and guest.  The guest can use the returned TSC value to
135*4882a593Smuzhiyuncompute the CLOCK_REALTIME for its clock, at the same instant.
136*4882a593Smuzhiyun
137*4882a593SmuzhiyunReturns KVM_EOPNOTSUPP if the host does not use TSC clocksource,
138*4882a593Smuzhiyunor if clock type is different than KVM_CLOCK_PAIRING_WALLCLOCK.
139*4882a593Smuzhiyun
140*4882a593Smuzhiyun6. KVM_HC_SEND_IPI
141*4882a593Smuzhiyun------------------
142*4882a593Smuzhiyun
143*4882a593Smuzhiyun:Architecture: x86
144*4882a593Smuzhiyun:Status: active
145*4882a593Smuzhiyun:Purpose: Send IPIs to multiple vCPUs.
146*4882a593Smuzhiyun
147*4882a593Smuzhiyun- a0: lower part of the bitmap of destination APIC IDs
148*4882a593Smuzhiyun- a1: higher part of the bitmap of destination APIC IDs
149*4882a593Smuzhiyun- a2: the lowest APIC ID in bitmap
150*4882a593Smuzhiyun- a3: APIC ICR
151*4882a593Smuzhiyun
152*4882a593SmuzhiyunThe hypercall lets a guest send multicast IPIs, with at most 128
153*4882a593Smuzhiyun128 destinations per hypercall in 64-bit mode and 64 vCPUs per
154*4882a593Smuzhiyunhypercall in 32-bit mode.  The destinations are represented by a
155*4882a593Smuzhiyunbitmap contained in the first two arguments (a0 and a1). Bit 0 of
156*4882a593Smuzhiyuna0 corresponds to the APIC ID in the third argument (a2), bit 1
157*4882a593Smuzhiyuncorresponds to the APIC ID a2+1, and so on.
158*4882a593Smuzhiyun
159*4882a593SmuzhiyunReturns the number of CPUs to which the IPIs were delivered successfully.
160*4882a593Smuzhiyun
161*4882a593Smuzhiyun7. KVM_HC_SCHED_YIELD
162*4882a593Smuzhiyun---------------------
163*4882a593Smuzhiyun
164*4882a593Smuzhiyun:Architecture: x86
165*4882a593Smuzhiyun:Status: active
166*4882a593Smuzhiyun:Purpose: Hypercall used to yield if the IPI target vCPU is preempted
167*4882a593Smuzhiyun
168*4882a593Smuzhiyuna0: destination APIC ID
169*4882a593Smuzhiyun
170*4882a593Smuzhiyun:Usage example: When sending a call-function IPI-many to vCPUs, yield if
171*4882a593Smuzhiyun	        any of the IPI target vCPUs was preempted.
172