On Tue, 2024-02-06 at 10:41 -0800, Sean Christopherson wrote: > > This has an obvious-in-hindsight recursive deadlock bug. If KVM actually needs > to inject a timer IRQ, and the fast path fails, i.e. the gpc is invalid, > kvm_xen_set_evtchn() will attempt to acquire xen.xen_lock, which is already held Hm, right. In fact, kvm_xen_set_evtchn() shouldn't actually *need* the xen_lock in an ideal world; it's only taking it in order to work around the fact that the gfn_to_pfn_cache doesn't have its *own* self- sufficient locking. I have patches for that... I think the *simplest* of the "patches for that" approaches is just to use the gpc->refresh_lock to cover all activate, refresh and deactivate calls. I was waiting for Paul's series to land before sending that one, but I'll work on it today, and double-check my belief that we can then just drop xen_lock from kvm_xen_set_evtchn().
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
