[PATCH 0/2] KVM: arm64: vgic-v4: Don't allocate vPEs that a VM can't use

[PATCH 0/2] KVM: arm64: vgic-v4: Don't allocate vPEs that a VM can't use

[Fuad Tabba]

Hi folks,

Two fixes for vgic_its_create() allocating vPEs for a VM that never
uses them. Nothing frees them when the VM is destroyed, and each
doorbell handler stays registered with a freed vCPU.

The first is for a GICv2 VM, which KVM can run on a GICv4.0 host whose
CPU interface supports legacy operation. The second is for a GICv3 VM
whose VMM cleared nASSGIcap on a GICv4.1 host with vSGIs.

Tested on AEM FVP, with has-gicv4.1=0 for the GICv2 case and =1 for the
other. With my reproducer (clear nASSGIcap for the second case,
initialise the vgic, create an ITS, destroy the VM), the kernel without
the fix leaves four "vcpu" doorbells in /proc/interrupts in each case,
and the fixed one doesn't leave any.

It doesn't conflict with my vgic init error-path series [1].

Based on Linux 7.3-rc3 (fd73f4a665989; also applies to kvmarm-7.4).

Cheers,
/fuad

[1] https://lore.kernel.org/all/20260921072958.2918477-1-fuad.tabba@linux.dev/

Fuad Tabba (2):
  KVM: arm64: vgic-v4: Don't allocate vPEs for a GICv2 VM
  KVM: arm64: vgic-v4: Don't allocate vPEs when userspace clears
    nASSGIcap

 arch/arm64/kvm/vgic/vgic-v4.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)


base-commit: fd73f4a6659897191fa0d40695fe370925dd3780
-- 
2.47.3

[PATCH 1/2] KVM: arm64: vgic-v4: Don't allocate vPEs for a GICv2 VM

[Fuad Tabba]

KVM can run a GICv2 VM on a GICv4.0 host whose CPU interface supports
legacy operation. Such a VM has no LPIs and never uses vPEs, so
vgic_supports_direct_irqs() is false for it and kvm_vgic_dist_destroy()
never tears them down. However, userspace can still create an ITS for
it. Once the vgic is initialised, vgic_its_create() calls
vgic_v4_init(), which allocates the vPEs and requests a doorbell IRQ for
each vCPU. They're then never freed, and each doorbell handler stays
registered with a vCPU that's freed with the VM.

Only allocate vPEs for a GICv3 VM.

Fixes: 74fe55dc9ab77 ("KVM: arm/arm64: GICv4: Add init/teardown of the per-VM vPE irq domain")
Cc: stable@vger.kernel.org
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 arch/arm64/kvm/vgic/vgic-v4.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
index ed236f083f0d7..a01de4de608a6 100644
--- a/arch/arm64/kvm/vgic/vgic-v4.c
+++ b/arch/arm64/kvm/vgic/vgic-v4.c
@@ -248,7 +248,7 @@ int vgic_v4_init(struct kvm *kvm)
 
 	lockdep_assert_held(&kvm->arch.config_lock);
 
-	if (!kvm_vgic_global_state.has_gicv4)
+	if (!kvm_vgic_global_state.has_gicv4 || dist->vgic_model != KVM_DEV_TYPE_ARM_VGIC_V3)
 		return 0; /* Nothing to see here... move along. */
 
 	if (dist->its_vm.vpes)
-- 
2.47.3

Re: [PATCH 1/2] KVM: arm64: vgic-v4: Don't allocate vPEs for a GICv2 VM

[Oliver Upton]

On Mon, Oct 26, 2026 at 03:26:38PM +0000, Fuad Tabba wrote:
> KVM can run a GICv2 VM on a GICv4.0 host whose CPU interface supports
> legacy operation.

I'm pretty sure there's no IP out there that has GICv4.0 and legacy
mode...

> Such a VM has no LPIs and never uses vPEs, so
> vgic_supports_direct_irqs() is false for it and kvm_vgic_dist_destroy()
> never tears them down. However, userspace can still create an ITS for
> it. Once the vgic is initialised, vgic_its_create() calls
> vgic_v4_init(), which allocates the vPEs and requests a doorbell IRQ for
> each vCPU. They're then never freed, and each doorbell handler stays
> registered with a vCPU that's freed with the VM.
> 
> Only allocate vPEs for a GICv3 VM.
> 
> Fixes: 74fe55dc9ab77 ("KVM: arm/arm64: GICv4: Add init/teardown of the per-VM vPE irq domain")
> Cc: stable@vger.kernel.org
> Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
> ---
>  arch/arm64/kvm/vgic/vgic-v4.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
> index ed236f083f0d7..a01de4de608a6 100644
> --- a/arch/arm64/kvm/vgic/vgic-v4.c
> +++ b/arch/arm64/kvm/vgic/vgic-v4.c
> @@ -248,7 +248,7 @@ int vgic_v4_init(struct kvm *kvm)
>  
>  	lockdep_assert_held(&kvm->arch.config_lock);
>  
> -	if (!kvm_vgic_global_state.has_gicv4)
> +	if (!kvm_vgic_global_state.has_gicv4 || dist->vgic_model != KVM_DEV_TYPE_ARM_VGIC_V3)

use vgic_is_v3() instead

Thanks,
Oliver

>  		return 0; /* Nothing to see here... move along. */
>  
>  	if (dist->its_vm.vpes)
> -- 
> 2.47.3
> 
> 

Re: [PATCH 1/2] KVM: arm64: vgic-v4: Don't allocate vPEs for a GICv2 VM

[Marc Zyngier]

On Mon, 26 Oct 2026 19:12:23 +0000,
Oliver Upton <oupton@kernel.org> wrote:
> 
> On Mon, Oct 26, 2026 at 03:26:38PM +0000, Fuad Tabba wrote:
> > KVM can run a GICv2 VM on a GICv4.0 host whose CPU interface supports
> > legacy operation.
> 
> I'm pretty sure there's no IP out there that has GICv4.0 and legacy
> mode...

My favourite space heater, HiSi D05, says otherwise: 64 A72,
GICv4.0. Remember that it is the *CPU* that provides compat mode, and
not the GIC.

	M.

-- 
Jazz isn't dead. It just smells funny.

Re: [PATCH 1/2] KVM: arm64: vgic-v4: Don't allocate vPEs for a GICv2 VM

[Oliver Upton]

On Mon, Oct 26, 2026 at 07:55:45PM +0000, Marc Zyngier wrote:
> On Mon, 26 Oct 2026 19:12:23 +0000,
> Oliver Upton <oupton@kernel.org> wrote:
> > 
> > On Mon, Oct 26, 2026 at 03:26:38PM +0000, Fuad Tabba wrote:
> > > KVM can run a GICv2 VM on a GICv4.0 host whose CPU interface supports
> > > legacy operation.
> > 
> > I'm pretty sure there's no IP out there that has GICv4.0 and legacy
> > mode...
> 
> My favourite space heater, HiSi D05, says otherwise: 64 A72,
> GICv4.0. Remember that it is the *CPU* that provides compat mode, and
> not the GIC.

Well I forgot that one got glued together. Good thing you're on the hook
for fixes this round then ;)

Thanks,
Olier

Re: [PATCH 1/2] KVM: arm64: vgic-v4: Don't allocate vPEs for a GICv2 VM

[Fuad Tabba]

On Mon, 26 Oct 2026 at 21:30, Oliver Upton <oupton@kernel.org> wrote:
>
> On Mon, Oct 26, 2026 at 07:55:45PM +0000, Marc Zyngier wrote:
> > On Mon, 26 Oct 2026 19:12:23 +0000,
> > Oliver Upton <oupton@kernel.org> wrote:
> > >
> > > On Mon, Oct 26, 2026 at 03:26:38PM +0000, Fuad Tabba wrote:
> > > > KVM can run a GICv2 VM on a GICv4.0 host whose CPU interface supports
> > > > legacy operation.
> > >
> > > I'm pretty sure there's no IP out there that has GICv4.0 and legacy
> > > mode...
> >
> > My favourite space heater, HiSi D05, says otherwise: 64 A72,
> > GICv4.0. Remember that it is the *CPU* that provides compat mode, and
> > not the GIC.
>
> Well I forgot that one got glued together. Good thing you're on the hook
> for fixes this round then ;)

Can I at least get one of those space heaters for my effort? It's that
time of year after all... :)

/fuad

[PATCH 2/2] KVM: arm64: vgic-v4: Don't allocate vPEs when userspace clears nASSGIcap

[Fuad Tabba]

Since commit c652887a92887 ("KVM: arm64: vgic-v3: Allow userspace to
write GICD_TYPER2.nASSGIcap"), userspace can disable vPE allocation for
a VM on a GICv4.1 host with vSGIs by clearing nASSGIcap before the vgic
is initialised. vgic_init() then skips vgic_v4_init(), and
kvm_vgic_dist_destroy() skips vgic_v4_teardown(). vgic_its_create()
still calls vgic_v4_init() for an ITS created after the vgic is
initialised, though, and vgic_v4_init() allocates the vPEs and requests
a doorbell IRQ for each vCPU. Destroying the VM leaks them, and leaves
each doorbell handler registered with a vCPU that's about to be freed.

Rather than gate on vgic_supports_direct_irqs(), which reads has_its
before vgic_its_create() sets it, check for a cleared nASSGIcap in
vgic_v4_init().

Fixes: c652887a92887 ("KVM: arm64: vgic-v3: Allow userspace to write GICD_TYPER2.nASSGIcap")
Cc: stable@vger.kernel.org
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 arch/arm64/kvm/vgic/vgic-v4.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
index a01de4de608a6..12a57921f6af3 100644
--- a/arch/arm64/kvm/vgic/vgic-v4.c
+++ b/arch/arm64/kvm/vgic/vgic-v4.c
@@ -251,6 +251,10 @@ int vgic_v4_init(struct kvm *kvm)
 	if (!kvm_vgic_global_state.has_gicv4 || dist->vgic_model != KVM_DEV_TYPE_ARM_VGIC_V3)
 		return 0; /* Nothing to see here... move along. */
 
+	/* Userspace disabled vPE allocation by clearing nASSGIcap */
+	if (system_supports_direct_sgis() && !vgic_supports_direct_sgis(kvm))
+		return 0;
+
 	if (dist->its_vm.vpes)
 		return 0;
 
-- 
2.47.3

Re: [PATCH 2/2] KVM: arm64: vgic-v4: Don't allocate vPEs when userspace clears nASSGIcap

[Oliver Upton]

Hi Fuad,

On Mon, Oct 26, 2026 at 03:26:39PM +0000, Fuad Tabba wrote:
> Since commit c652887a92887 ("KVM: arm64: vgic-v3: Allow userspace to
> write GICD_TYPER2.nASSGIcap"), userspace can disable vPE allocation for
> a VM on a GICv4.1 host with vSGIs by clearing nASSGIcap before the vgic
> is initialised. vgic_init() then skips vgic_v4_init(), and
> kvm_vgic_dist_destroy() skips vgic_v4_teardown(). vgic_its_create()
> still calls vgic_v4_init() for an ITS created after the vgic is
> initialised, though, and vgic_v4_init() allocates the vPEs and requests
> a doorbell IRQ for each vCPU. Destroying the VM leaks them, and leaves
> each doorbell handler registered with a vCPU that's about to be freed.
> 
> Rather than gate on vgic_supports_direct_irqs(), which reads has_its
> before vgic_its_create() sets it, check for a cleared nASSGIcap in
> vgic_v4_init().
> 
> Fixes: c652887a92887 ("KVM: arm64: vgic-v3: Allow userspace to write GICD_TYPER2.nASSGIcap")
> Cc: stable@vger.kernel.org
> Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
> ---
>  arch/arm64/kvm/vgic/vgic-v4.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
> index a01de4de608a6..12a57921f6af3 100644
> --- a/arch/arm64/kvm/vgic/vgic-v4.c
> +++ b/arch/arm64/kvm/vgic/vgic-v4.c
> @@ -251,6 +251,10 @@ int vgic_v4_init(struct kvm *kvm)
>  	if (!kvm_vgic_global_state.has_gicv4 || dist->vgic_model != KVM_DEV_TYPE_ARM_VGIC_V3)
>  		return 0; /* Nothing to see here... move along. */
>  
> +	/* Userspace disabled vPE allocation by clearing nASSGIcap */
> +	if (system_supports_direct_sgis() && !vgic_supports_direct_sgis(kvm))
> +		return 0;
> +

Looking at both of the patches now, I'd rather we just fix the
predicates and use those to consistently gate GICv4. Untested as always:

diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 9e782a4fea7e..2b22f096a504 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -1866,9 +1866,16 @@ static int vgic_its_create(struct kvm_device *dev, u32 type)
 
 	mutex_lock(&dev->kvm->arch.config_lock);
 
+	/*
+	 * Make an early indication that this VM has an ITS so calls to
+	 * vgic_supports_direct_irqs() work as intended, rolling back state
+	 * if we fail to setup GICv4.
+	 */
+	dev->kvm->arch.vgic.has_its = true;
 	if (vgic_initialized(dev->kvm)) {
 		ret = vgic_v4_init(dev->kvm);
 		if (ret < 0) {
+			dev->kvm->arch.vgic.has_its = false;
 			mutex_unlock(&dev->kvm->arch.config_lock);
 			kfree(its);
 			return ret;
@@ -1893,7 +1900,6 @@ static int vgic_its_create(struct kvm_device *dev, u32 type)
 	xa_init(&its->translation_cache);
 
 	dev->kvm->arch.vgic.msis_require_devid = true;
-	dev->kvm->arch.vgic.has_its = true;
 	its->enabled = false;
 	its->dev = dev;
 
diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
index ed236f083f0d..c65bd8783284 100644
--- a/arch/arm64/kvm/vgic/vgic-v4.c
+++ b/arch/arm64/kvm/vgic/vgic-v4.c
@@ -248,8 +248,8 @@ int vgic_v4_init(struct kvm *kvm)
 
 	lockdep_assert_held(&kvm->arch.config_lock);
 
-	if (!kvm_vgic_global_state.has_gicv4)
-		return 0; /* Nothing to see here... move along. */
+	if (!vgic_supports_direct_irqs(kvm))
+		return 0;
 
 	if (dist->its_vm.vpes)
 		return 0;
diff --git a/arch/arm64/kvm/vgic/vgic.h b/arch/arm64/kvm/vgic/vgic.h
index b71d486ae514..bd1614c9ff05 100644
--- a/arch/arm64/kvm/vgic/vgic.h
+++ b/arch/arm64/kvm/vgic/vgic.h
@@ -509,6 +509,10 @@ static inline bool vgic_supports_direct_irqs(struct kvm *kvm)
 	if (vgic_is_v5(kvm))
 		return true;
 
+	/* GICv2 never supports direct IRQs */
+	if (!vgic_is_v3(kvm))
+		return false;
+
 	return vgic_supports_direct_msis(kvm) || vgic_supports_direct_sgis(kvm);
 }
 
-- 
Thanks,
Oliver

Re: [PATCH 2/2] KVM: arm64: vgic-v4: Don't allocate vPEs when userspace clears nASSGIcap

[Fuad Tabba]

Hi Oliver,

On Mon, 26 Oct 2026 19:39:21 +0000, Oliver Upton <oupton@kernel.org> wrote:
[...]
> Looking at both of the patches now, I'd rather we just fix the
> predicates and use those to consistently gate GICv4. Untested as always:

I open coded the nASSGIcap check because vgic_its_create() only sets
has_its after vgic_v4_init(), but the predicate is the better place for
it.

> diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
[...]
> @@ -1866,9 +1866,16 @@ static int vgic_its_create(struct kvm_device *dev, u32 type)
>  
>          mutex_lock(&dev->kvm->arch.config_lock);
>  
> +        /*
> +         * Make an early indication that this VM has an ITS so calls to
> +         * vgic_supports_direct_irqs() work as intended, rolling back state
> +         * if we fail to setup GICv4.
> +         */
> +        dev->kvm->arch.vgic.has_its = true;

This makes vgic_supports_direct_irqs() true for running vCPUs before
vgic_v4_init() has allocated their vPEs. On GICv4.0, a vCPU loaded in
that window hits the WARN_ON(vgic_v4_load()) in vgic_v3_load()
(vpe->irq is still 0). With an msleep() holding vgic_its_create()
there, my reproducer, which creates an ITS while a vCPU runs, hits it
on the FVP. Keeping the store after vgic_v4_init(), where it is today,
avoids that window (diff below).

[...]
> diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
[...]
> @@ -248,8 +248,8 @@ int vgic_v4_init(struct kvm *kvm)
>  
>          lockdep_assert_held(&kvm->arch.config_lock);
>  
> -        if (!kvm_vgic_global_state.has_gicv4)
> -                return 0; /* Nothing to see here... move along. */
> +        if (!vgic_supports_direct_irqs(kvm))
> +                return 0;

vgic_supports_direct_irqs() is also true for any vGICv5 VM, so with
this, creating an ITS on an initialised one, on a GICv5 host with
legacy support, reaches its_alloc_vcpu_irqs() with no GICv4 irqdomain,
where irq_domain_create_hierarchy() dereferences a NULL vpe_domain_ops.
The diff below keeps the has_gicv4 test.

It gates vgic_v4_init() on the part of vgic_supports_direct_msis()
that doesn't read has_its. That part is false for the GICv2 VM from
patch 1 and for a vGICv5 VM, so the diff drops your vgic.h hunk:

diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
index 5913a20d83019..a60697238a7a7 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
@@ -48,7 +48,7 @@ bool vgic_has_its(struct kvm *kvm)
 	return dist->has_its;
 }
 
-bool vgic_supports_direct_msis(struct kvm *kvm)
+bool vgic_supports_vpes(struct kvm *kvm)
 {
 	/*
 	 * Deliberately conflate vLPI and vSGI support on GICv4.1 hardware,
@@ -58,7 +58,12 @@ bool vgic_supports_direct_msis(struct kvm *kvm)
 	if (system_supports_direct_sgis() && !vgic_supports_direct_sgis(kvm))
 		return false;
 
-	return kvm_vgic_global_state.has_gicv4 && vgic_has_its(kvm);
+	return kvm_vgic_global_state.has_gicv4 && vgic_is_v3(kvm);
+}
+
+bool vgic_supports_direct_msis(struct kvm *kvm)
+{
+	return vgic_supports_vpes(kvm) && vgic_has_its(kvm);
 }
 
 bool system_supports_direct_sgis(void)
diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
index ed236f083f0d7..0a4b9a74425b4 100644
--- a/arch/arm64/kvm/vgic/vgic-v4.c
+++ b/arch/arm64/kvm/vgic/vgic-v4.c
@@ -248,7 +248,7 @@ int vgic_v4_init(struct kvm *kvm)
 
 	lockdep_assert_held(&kvm->arch.config_lock);
 
-	if (!kvm_vgic_global_state.has_gicv4)
+	if (!vgic_supports_vpes(kvm))
 		return 0; /* Nothing to see here... move along. */
 
 	if (dist->its_vm.vpes)
diff --git a/arch/arm64/kvm/vgic/vgic.h b/arch/arm64/kvm/vgic/vgic.h
index b71d486ae5145..7fc29a395a7db 100644
--- a/arch/arm64/kvm/vgic/vgic.h
+++ b/arch/arm64/kvm/vgic/vgic.h
@@ -500,6 +500,7 @@ static inline bool vgic_host_has_gicv5(void)
 }
 
 bool system_supports_direct_sgis(void);
+bool vgic_supports_vpes(struct kvm *kvm);
 bool vgic_supports_direct_msis(struct kvm *kvm);
 bool vgic_supports_direct_sgis(struct kvm *kvm);
 

Tested on the FVP (GICv4.0 and GICv4.1): KVM doesn't leak doorbells in
either patch's case, a GICv3 VM still gets its vPEs when the ITS is
created, and the reproducer above doesn't hit the WARN. Does that work
for you? If so, I'll send it as v2.

Cheers,
/fuad