Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Mauricio Faria de Oliveira <mfo@igalia.com>
Cc: Paul Durrant <paul@xen.org>,
	Sean Christopherson <seanjc@google.com>,
	 Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	 Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Clark Williams <clrkwllms@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	kernel-dev@igalia.com,  kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org,  linux-rt-devel@lists.linux.dev,
	 syzbot+208f7f3e5f59c11aeb90@syzkaller.appspotmail.com
Subject: Re: [PATCH] KVM: x86/xen: bail in IRQ context on PREEMPT_RT in kvm_xen_set_evtchn_fast()
Date: Thu, 07 May 2026 16:22:26 +0100	[thread overview]
Message-ID: <876c720ab963f550d3166b067f6457fcd78ec415.camel@infradead.org> (raw)
In-Reply-To: <e23df9d183c2c421946ea73b8053e4c4@igalia.com>

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

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@google.com/
> > 
> > ...
> > 
> > > +	/* 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.

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?



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

  reply	other threads:[~2026-05-07 15:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-07  2:36 [PATCH] KVM: x86/xen: bail in IRQ context on PREEMPT_RT in kvm_xen_set_evtchn_fast() Mauricio Faria de Oliveira
2026-05-07  6:58 ` David Woodhouse
2026-05-07  7:12   ` Sebastian Andrzej Siewior
2026-05-07  7:30     ` David Woodhouse
2026-05-07 13:00     ` David Woodhouse
2026-05-07 13:21       ` Sebastian Andrzej Siewior
2026-05-07 13:43         ` David Woodhouse
2026-05-07 14:54           ` Sebastian Andrzej Siewior
2026-05-07 14:56   ` Mauricio Faria de Oliveira
2026-05-07 15:22     ` David Woodhouse [this message]
2026-05-07 16:02       ` Mauricio Faria de Oliveira
2026-05-07 16:15         ` David Woodhouse
2026-05-07 16:34           ` Mauricio Faria de Oliveira
2026-05-07 17:45             ` David Woodhouse
2026-05-08 17:48         ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=876c720ab963f550d3166b067f6457fcd78ec415.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=bigeasy@linutronix.de \
    --cc=bp@alien8.de \
    --cc=clrkwllms@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kernel-dev@igalia.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=mfo@igalia.com \
    --cc=mingo@redhat.com \
    --cc=paul@xen.org \
    --cc=pbonzini@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=seanjc@google.com \
    --cc=syzbot+208f7f3e5f59c11aeb90@syzkaller.appspotmail.com \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox