[RFC PATCH] KVM: arm64: vgic: Skip vCPU trylock for pre-init register access

[David Woodhouse]

On Mon, 2026-05-11 at 19:03 +0800, Yao Yuan wrote:
> 
> > +	/*
> > +	 * If the VGIC becomes initialized between the above check and taking
> > +	 * config_lock, drop config_lock to lock the VCPUS.
> > +	 */
> > +	if (vgic_initialized(dev->kvm) && !vcpus_locked) {
> > +		mutex_unlock(&dev->kvm->arch.config_lock);
> > +		if (kvm_trylock_all_vcpus(dev->kvm)) {
> > +			mutex_unlock(&dev->kvm->lock);
> > +			return -EBUSY;
> > +		}
> > +		mutex_lock(&dev->kvm->arch.config_lock);
> > +		vcpus_locked = true;
> 
> Question: Why not do vgic_initialized(dev->kvm) and
> reg_allowed_pre_init(attr) checking after take config_lock,
> and depends on the checking result to decide trylocak all
> vcpus or not ?

Yeah... I didn't like that either.

If we attempt to take the vCPU locks while *holding* config_lock, that
gives us a classic ABBA deadlock with the code paths that hold the vCPU
locks first.

Well, maybe it doesn't because we'd only be doing a *trylock*... but
lockdep wouldn't know that and it's fugly as hell. So I settled on the
above.

The long term fix, as I noted, is to kill kvm_trylock_all_vcpus() with
fire in *all* cases, not just the !vgic_initialized() case. On x86 we'd
do this with something like KVM_REQ_MCLOCK_INPROGRESS to kick vCPUs out
of guest mode to prevent concurrent access. Which isn't my favourite
code *either* but at least it works without imposing the awfulness on
the userspace API.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5069 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260511/2e4e2061/attachment.p7s>