From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: paul@xen.org, kvm@vger.kernel.org,
Ivan Orlov <iorlov@amazon.co.uk>,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
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>,
linux-kernel@vger.kernel.org
Subject: Re: KVM: x86/xen: Allow 'out of range' event channel ports in IRQ routing table.
Date: Mon, 23 Jun 2025 09:48:33 -0700 [thread overview]
Message-ID: <aFmFYZlrxlLE2ZzY@google.com> (raw)
In-Reply-To: <7cc618b80681e8e1402c73886505f6247c810db8.camel@infradead.org>
On Mon, Jun 23, 2025, David Woodhouse wrote:
> On Mon, 2025-05-12 at 10:29 +0100, Paul Durrant wrote:
> > On 08/05/2025 21:30, David Woodhouse wrote:
> > > From: David Woodhouse <dwmw@amazon.co.uk>
> > >
> > > To avoid imposing an ordering constraint on userspace, allow 'invalid'
> > > event channel targets to be configured in the IRQ routing table.
> > >
> > > This is the same as accepting interrupts targeted at vCPUs which don't
> > > exist yet, which is already the case for both Xen event channels *and*
> > > for MSIs (which don't do any filtering of permitted APIC ID targets at
> > > all).
> > >
> > > If userspace actually *triggers* an IRQ with an invalid target, that
> > > will fail cleanly, as kvm_xen_set_evtchn_fast() also does the same range
> > > check.
> > >
> > > If KVM enforced that the IRQ target must be valid at the time it is
> > > *configured*, that would force userspace to create all vCPUs and do
> > > various other parts of setup (in this case, setting the Xen long_mode)
> > > before restoring the IRQ table.
> > >
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> > > ---
> > > arch/x86/kvm/xen.c | 14 ++++++++++++--
> > > 1 file changed, 12 insertions(+), 2 deletions(-)
> > >
> >
> > Reviewed-by: Paul Durrant <paul@xen.org>
>
> Ping?
Almost there :-) I've got it applied (for 6.16), just need to run my generic
test stuff before making it "official".
next prev parent reply other threads:[~2025-06-23 16:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-08 20:30 KVM: x86/xen: Allow 'out of range' event channel ports in IRQ routing table David Woodhouse
2025-05-12 9:29 ` Paul Durrant
2025-06-23 16:44 ` David Woodhouse
2025-06-23 16:48 ` Sean Christopherson [this message]
2025-06-24 19:38 ` Sean Christopherson
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=aFmFYZlrxlLE2ZzY@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=hpa@zytor.com \
--cc=iorlov@amazon.co.uk \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.