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

[Mauricio Faria de Oliveira]

On 2026-05-07 12:22, David Woodhouse wrote:
> On Thu, 2026-05-07 at 11:56 -0300, Mauricio Faria de Oliveira wrote:
>> On 2026-05-07 03:58, David Woodhouse wrote:
>> > On Wed, 2026-05-06 at 23:36 -0300, Mauricio Faria de Oliveira wrote:
>> > > kvm_xen_set_evtchn_fast() calls read_lock_irqsave(), which might block
>> > > on PREEMPT_RT, but that is invalid in IRQ context, as when it's called
>> > > by xen_timer_callback() (even on PREEMPT_RT per HRTIMER_MODE_ABS_HARD).
>> > > 
>> > > Check for that case, and bail out early.
>> > > 
>> > > Note: there is previous work and discussion on this [1] (~2 years ago),
>> > > which involved continuing to execute the function with changes, but it
>> > > was not merged. That was a different, more complex approach.
>> > > 
>> > > [1] https://lore.kernel.org/lkml/ZdPQVP7eejq3eFjc@xxxxxxxxxx/
>> > 
>> > ...
>> > 
>> > > +	/* Bail in IRQ context on PREEMPT_RT; read_lock_irqsave() might block */
>> > > +	if (IS_ENABLED(CONFIG_PREEMPT_RT) && in_hardirq())
>> > > +		goto out;
>> > 
>> > 
>> > The approach in Paul's earlier patch was better; we absolutely *want*
>> > to deliver the interrupt to the guest immediately whenever we can, and
>> > only fall back to the workqueue in the rare case that the shared info
>> > page has been invalidated.
>> 
>> Certainly, that was better. This was a simple workaround, but with this
>> clarification, it indeed doesn't fit.
>> 
>> > We should switch to plain read_trylock(), *without* the
>> > local_irq_save(). And since this was the *only* case where the GPC lock
>> > was ever taken under IRQ¹, all the GPC locking can drop the _irq part.
>> 
>> Ok, I can take a look. Or do you plan to work on it yourself (as you
>> hit the issue with read_unlock later in this thread)?
> 
> I'm working on it now; thanks.

Ok, thanks; I'll drop this. Could you please Cc me when you send it out?

> Currently confused by the fact that the read_trylock() seems to fail
> more often than it should under RT, causing the fallback path to be
> taken... and the fallback path doesn't seem to work properly...
> 
> Your version should have seen this too, surely? Did the selftest in
> linux/tools/testing/selftests/kvm/x86/xen_shinfo_test work with your
> patch?

Yes, it works, apparently. Timing is similar with/without PREEMPT_RT.

# dmesg -C
# time ./xen_shinfo_test
Random seed: 0x6b8b4567

real    0m4.064s
user    0m1.654s
sys     0m4.915s
# echo $?
0
# dmesg
#

-- 
Mauricio