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