On Thu, 20 Nov 2025 14:02:50 +0000, Maximilian Dittgen mdittgen@amazon.de wrote:
Add CONFIG_ARM_GIC_V3_PER_VCPU_VLPI to control whether vLPI direct injection is to be enabled on a system-wide or a per-vCPU basis.
When enabled, vPEs can be allocated/deallocated to vCPUs on an ad-hoc, per-vCPU basis in runtime. When disabled, keep current vgic_v4_init behavior of automatic vCPU vPE allocation upon VM initialization.
We declare three ioctls numbers to manage per-vCPU vLPI enablement:
- KVM_ENABLE_VCPU_VLPI, which given a vCPU ID, allocates a vPE and
initializes the vCPU for receiving direct vLPI interrupts.
- KVM_DISABLE_VCPU_VLPI, which given a vCPU ID, disables the vCPU’s
ability to receive direct vLPI interrupts and frees its underlying vPE structure.
- KVM_QUERY_VCPU_VLPI, which given a vCPU ID, returns a boolean
describing whether the vCPU is configured to receive direct vLPI interrupts.
This commit declares the kconfig, ioctl numbers, and documentation. Implementation will come throughout this patch set.
Signed-off-by: Maximilian Dittgen mdittgen@amazon.de
Documentation/virt/kvm/api.rst | 56 ++++++++++++++++++++++++++++++++++ arch/arm64/kvm/arm.c | 15 +++++++++ arch/arm64/kvm/vgic/vgic-v4.c | 9 ++++++ arch/arm64/kvm/vgic/vgic.h | 2 ++ drivers/irqchip/Kconfig | 13 ++++++++ include/uapi/linux/kvm.h | 6 ++++ 6 files changed, 101 insertions(+)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 27f726ff8fe0..dcfb326dff10 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6517,6 +6517,62 @@ the capability to be present. `flags` must currently be zero. +4.XXX KVM_ENABLE_VCPU_VLPI +--------------------------
+:Capability: KVM_CAP_ARM_PER_VCPU_VLPI +:Architectures: arm64 +:Type: vm ioctl +:Parameters: int vcpu_id (in) +:Returns: 0 on success, negative value on error
+This ioctl enables GICv4 direct vLPI injection for the specified vCPU. +Allocates vPE structures (doorbell IRQ, vPE table entry, virtual pending +table, vPEID) and upgrades existing software-forwarded LPIs targeting +this vCPU to hardware-forwarded vLPIs.
+If GICv4.1 is supported and vSGIs are disabled on the specified vCPU, +this ioctl enables vCPU vSGI support.
+Requires CONFIG_ARM_GIC_V3_PER_VCPU_VLPI and GICv4 hardware support.
+Returns -EINVAL if vGICv4 is not initialized or if the passed vcpu_id +does not map to a vCPU.
+4.XXX KVM_DISABLE_VCPU_VLPI +---------------------------
+:Capability: KVM_CAP_ARM_PER_VCPU_VLPI +:Architectures: arm64 +:Type: vm ioctl +:Parameters: int vcpu_id (in) +:Returns: 0 on success, negative value on error
+This ioctl disables GICv4 direct vLPI injection for the specified vCPU. +Downgrades hardware-forwarded vLPIs to software-forwarded LPIs and frees +vPE structures. Pending interrupts in the virtual pending table may be +lost.
I'm going to put my foot down on that immediately.
There is no conceivable case where losing interrupts in acceptable. Ever. If that's what you want, please write your own hypervisor. I wish you luck!
+If vSGIs are enabled on the specified vCPU, this ioctl disables them.
So what? Something that didn't have an active state now has one that the guest doesn't know about? There is exactly *one* bit that defines that, and it doesn't exist in some quantum superposition.
This whole thing is completely insane, has not been thought out at all, is ignoring the basis of the architecture, and I'm really sorry that you wasted your time on that.
M.