On 02.12.2020 20:03, Julien Grall wrote: > On 23/11/2020 13:28, Jan Beulich wrote: >> The per-vCPU virq_lock, which is being held anyway, together with there >> not being any call to evtchn_port_set_pending() when v->virq_to_evtchn[] >> is zero, provide sufficient guarantees. > > I agree that the per-vCPU virq_lock is going to be sufficient, however > dropping the lock also means the event channel locking is more complex > to understand (the long comment that was added proves it). > > In fact, the locking in the event channel code was already proven to be > quite fragile, therefore I think this patch is not worth the risk.
I agree this is a very reasonable position to take. I probably would even have remained silent if in the meantime the spin_lock()s there hadn't changed to read_trylock()s. I really think we want to limit this unusual locking model to where we strictly need it. And this change eliminates 50% of them, with the added benefit of making the paths more lightweight. Jan
