Re: [PATCH] KVM: x86/xen: bail in IRQ context on PREEMPT_RT in kvm_xen_set_evtchn_fast()

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

On Thu, 2026-05-07 at 09:12 +0200, Sebastian Andrzej Siewior wrote:
> On 2026-05-07 07:58:00 [+0100], David Woodhouse wrote:
> > > > I am not comfortable applying this patch.  As shown by the need for the next patch
> > > > to optimize unrelated invalidations, switching to read_trylock() is more subtle
> > > > than it seems at first glance.  Specifically, there are no fairness guarantees.
> > 
> > I'm OK with that in this case. Because kvm_xen_set_evtchn_fast(), as
> > with *everything* called from kvm_arch_set_irq_inatomic(), is
> > explicitly designed to be a 'best effort' and allowed to return
> > -EWOULDBLOCK when it's too hard.
> > 
> > And the write lock being held here should a *rare* case, as the GPC for
> > the shared_info and vcpu_info pages should basically *never* get
> > invalidated while the guest is running.
> > 
> > I've taken the same read_trylock() approach in 
> > https://lore.kernel.org/all/1d6712ed413ea66ef376d1410811997c3b416e99.camel@infradead.org/
> 
> So the cited patch does not look bad. That read-trylock should be fine
> on RT (as in I don't see anything wrong with it). What did happen to it?

Nothing, but it's addressing a different problem, not the
kvm_xen_set_evtchn_fast() problem.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]