1 .. SPDX-License-Identifier: GPL-2.0 1 .. SPDX-License-Identifier: GPL-2.0
2 2
3 =================================== 3 ===================================
4 The LoongArch paravirtual interface 4 The LoongArch paravirtual interface
5 =================================== 5 ===================================
6 6
7 KVM hypercalls use the HVCL instruction with c 7 KVM hypercalls use the HVCL instruction with code 0x100 and the hypercall
8 number is put in a0. Up to five arguments may 8 number is put in a0. Up to five arguments may be placed in registers a1 - a5.
9 The return value is placed in v0 (an alias of 9 The return value is placed in v0 (an alias of a0).
10 10
11 Source code for this interface can be found in 11 Source code for this interface can be found in arch/loongarch/kvm*.
12 12
13 Querying for existence 13 Querying for existence
14 ====================== 14 ======================
15 15
16 To determine if the host is running on KVM, we 16 To determine if the host is running on KVM, we can utilize the cpucfg()
17 function at index CPUCFG_KVM_BASE (0x40000000) 17 function at index CPUCFG_KVM_BASE (0x40000000).
18 18
19 The CPUCFG_KVM_BASE range, spanning from 0x400 19 The CPUCFG_KVM_BASE range, spanning from 0x40000000 to 0x400000FF, The
20 CPUCFG_KVM_BASE range between 0x40000000 - 0x4 20 CPUCFG_KVM_BASE range between 0x40000000 - 0x400000FF is marked as reserved.
21 Consequently, all current and future processor 21 Consequently, all current and future processors will not implement any
22 feature within this range. 22 feature within this range.
23 23
24 On a KVM-virtualized Linux system, a read oper 24 On a KVM-virtualized Linux system, a read operation on cpucfg() at index
25 CPUCFG_KVM_BASE (0x40000000) returns the magic 25 CPUCFG_KVM_BASE (0x40000000) returns the magic string 'KVM\0'.
26 26
27 Once you have determined that your host is run 27 Once you have determined that your host is running on a paravirtualization-
28 capable KVM, you may now use hypercalls as des 28 capable KVM, you may now use hypercalls as described below.
29 29
30 KVM hypercall ABI 30 KVM hypercall ABI
31 ================= 31 =================
32 32
33 The KVM hypercall ABI is simple, with one scra 33 The KVM hypercall ABI is simple, with one scratch register a0 (v0) and at most
34 five generic registers (a1 - a5) used as input 34 five generic registers (a1 - a5) used as input parameters. The FP (Floating-
35 point) and vector registers are not utilized a 35 point) and vector registers are not utilized as input registers and must
36 remain unmodified during a hypercall. 36 remain unmodified during a hypercall.
37 37
38 Hypercall functions can be inlined as it only 38 Hypercall functions can be inlined as it only uses one scratch register.
39 39
40 The parameters are as follows: 40 The parameters are as follows:
41 41
42 ======== ================= 42 ======== ================= ================
43 Register IN 43 Register IN OUT
44 ======== ================= 44 ======== ================= ================
45 a0 function number 45 a0 function number Return code
46 a1 1st parameter 46 a1 1st parameter -
47 a2 2nd parameter 47 a2 2nd parameter -
48 a3 3rd parameter 48 a3 3rd parameter -
49 a4 4th parameter 49 a4 4th parameter -
50 a5 5th parameter 50 a5 5th parameter -
51 ======== ================= 51 ======== ================= ================
52 52
53 The return codes may be one of the following: 53 The return codes may be one of the following:
54 54
55 ==== ====================== 55 ==== =========================
56 Code Meaning 56 Code Meaning
57 ==== ====================== 57 ==== =========================
58 0 Success 58 0 Success
59 -1 Hypercall not implemen 59 -1 Hypercall not implemented
60 -2 Bad Hypercall paramete 60 -2 Bad Hypercall parameter
61 ==== ====================== 61 ==== =========================
62 62
63 KVM Hypercalls Documentation 63 KVM Hypercalls Documentation
64 ============================ 64 ============================
65 65
66 The template for each hypercall is as follows: 66 The template for each hypercall is as follows:
67 67
68 1. Hypercall name 68 1. Hypercall name
69 2. Purpose 69 2. Purpose
70 70
71 1. KVM_HCALL_FUNC_IPI 71 1. KVM_HCALL_FUNC_IPI
72 ------------------------ 72 ------------------------
73 73
74 :Purpose: Send IPIs to multiple vCPUs. 74 :Purpose: Send IPIs to multiple vCPUs.
75 75
76 - a0: KVM_HCALL_FUNC_IPI 76 - a0: KVM_HCALL_FUNC_IPI
77 - a1: Lower part of the bitmap for destination 77 - a1: Lower part of the bitmap for destination physical CPUIDs
78 - a2: Higher part of the bitmap for destinatio 78 - a2: Higher part of the bitmap for destination physical CPUIDs
79 - a3: The lowest physical CPUID in the bitmap 79 - a3: The lowest physical CPUID in the bitmap
80 80
81 The hypercall lets a guest send multiple IPIs 81 The hypercall lets a guest send multiple IPIs (Inter-Process Interrupts) with
82 at most 128 destinations per hypercall. The de 82 at most 128 destinations per hypercall. The destinations are represented in a
83 bitmap contained in the first two input regist 83 bitmap contained in the first two input registers (a1 and a2).
84 84
85 Bit 0 of a1 corresponds to the physical CPUID 85 Bit 0 of a1 corresponds to the physical CPUID in the third input register (a3)
86 and bit 1 corresponds to the physical CPUID in 86 and bit 1 corresponds to the physical CPUID in a3+1, and so on.
87 87
88 PV IPI on LoongArch includes both PV IPI multi 88 PV IPI on LoongArch includes both PV IPI multicast sending and PV IPI receiving,
89 and SWI is used for PV IPI inject since there 89 and SWI is used for PV IPI inject since there is no VM-exits accessing SWI registers.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.