Re: [PATCH 0/2] genirq, KVM: arm64: Avoid the irq descriptor lock on vCPU load

[Marc Zyngier <maz@kernel.org>]

On Sat, 24 Oct 2026 03:24:48 +0100,
Amir Noohi <amirmnoohi@gmail.com> wrote:
> 
> KVM/arm64 vCPUs slow each other down even when every vCPU has a physical
> CPU to itself. On a 32 CPU Ampere Altra (GICv3, VHE) running mainline,
> with an in-kernel GICv3 and each vCPU thread pinned to its own otherwise
> idle CPU, a vCPU which exits to userspace in a loop manages 320k exits/s
> on its own, 120k when 16 vCPUs do the same and 59k with 31. The aggregate
> rate stops growing at 8 vCPUs. No two vCPUs share a CPU and nothing is
> over-subscribed.
> 
> The cause is the interrupt descriptor lock of the host timer interrupts.
> Every vCPU load sets their active state with irq_set_irqchip_state()
> (twice on VHE: virtual and physical timer). The timer interrupts are per
> CPU interrupts, so all CPUs share one descriptor and its lock, while the
> state being written is per CPU (a redistributor register on GICv3, a
> system register on GICv5). The lock serializes nothing but CPUs updating
> their own state. At 8 vCPUs, 99.9% of all lock contention events during
> the test have __irq_get_desc_lock() or irq_set_irqchip_state() on the
> stack.

Looking at the test case, this really isn't a representative or
realistic workload.  This is a contrived setup that has trapping to
userspace as its only purpose.

I'm not saying that this is useless observation. But it is not
something that represents something exacerbated by "real" VMs.

I'll look at the patches shortly.

Thanks,

	M.

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