Re: [PATCH] KVM: x86/mmu: Protect noncoherent DMA zaps with SRCU

On Mon, 2026-08-24 at 14:49 -0700, Sean Christopherson wrote:
> On Mon, Aug 24, 2026, Kai Huang wrote:
> > On Mon, 2026-08-24 at 10:49 -0700, Sean Christopherson wrote:
> > > Alternatively, what if we have kvm_zap_gfn_range() acquire SRCU?  Nesting "locks"
> > > is a-ok, and two of the three users of kvm_zap_gfn_range() have had this bug (see
> > > commit 074c00800719 ("KVM: x86: Use SRCU to protect zap in
> > > __kvm_set_or_clear_apicv_inhibit()").
> > 
> > kvm_vcpu_srcu_read_lock() doesn't allow nesting lock of KVM's SRCU.
> 
> No, kvm_vcpu_srcu_read_lock() doesn't allow nested usage of itself.  Commit
> 2031f2876896 ("KVM: Add helpers to wrap vcpu->srcu_idx and yell if it's abused")
> added the protection because we had multiple bugs where KVM would clobber
> vcpu->srcu_idx and cause a deadlock by leaking a grace period reference.
> 
> > Doesn't seem to be a problem for this particular case, though, because
> > sev_handle_rmp_fault() calls kvm_zap_gfn_range() after
> > kvm_vcpu_srcu_read_lock() is called.
> 
> kvm_vcpu_srcu_read_lock() can nested inside an existing kvm->srcu critical section,
> just so long as the existing critical section isn't tracking its grace period via
> vcpu->____srcu_idx.

Hmm right, doesn't seem calling kvm_vcpu_srcu_read_lock() inside existing kvm-
>srcu could clobber vcpu->____srcu_idx.  So agree it's safe to explicitly hold
SRCU read lock inside kvm_zap_gfn_range().