Re: [PATCH v2 15/20] KVM: x86/xen: Convert kvm_xen_set_evtchn_fast() to gpc's CLASS() APIs

[David Woodhouse]

On Fri, 29 May 2026 12:11:37 -0700, Sean Christopherson wrote:
> On Fri, May 29, 2026, sashiko-bot@xxxxxxxxxx wrote:
> > [Severity: High]
> > Does this unintentionally hold the gpc lock across the IPI kick?
> 
> No, it intentionally holds the gpc lock across _sending_ the IPI kick.
> 
> > [Severity: High]
> > Does this now hold the VM-wide shinfo_cache lock while calling
> > __kvm_xen_set_evtchn_fast() and kicking the vCPU?
> > 
> > Since shinfo_map is a function-scoped CLASS() variable, its destructor
> > won't release the lock until after __kvm_xen_set_evtchn_fast() returns.
> > This creates a nested locking dependency and holds locks over expensive
> > cross-vCPU operations, potentially serializing event channel deliveries
> > across the entire VM on the fast path.
> 
> __kvm_vcpu_kick() is neither expensive nor cross-vCPU.  In the wait=false case,
> which is the behavior of kvm_vcpu_kick(), it sends IPIs via smp_send_reschedule(),
> i.e. it's more or less just __apic_send_IPI(cpu, RESCHEDULE_VECTOR), which is a
> single WRMSR on modern harware.

Hm, if we really are going to use a raw rwlock then I suppose we should
take care not to spend any extra cycles with the lock held unless we
actually *need* to?

In which case I wonder if we really need the scoped CLASS() thing (that
encourages people to run to the end of the function under the lock), or
if the helpers you add for that are sufficient on their own?

Attachment: smime.p7s
Description: S/MIME cryptographic signature