[RFC PATCH 01/13] KVM: Introduce config option for per-vCPU vLPI enablement

[Marc Zyngier]

On Thu, 20 Nov 2025 14:02:50 +0000,
Maximilian Dittgen <mdittgen at 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 at 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.

-- 
Without deviation from the norm, progress is not possible.