From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
linux-pci@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Juergen Gross <jgross@suse.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH v3 3/3] PCI/MSI: Convert pci_msi_ignore_mask to per MSI domain flag
Date: Wed, 26 Mar 2025 12:14:09 +0100 [thread overview]
Message-ID: <Z-PhgWQMHjxbac3b@macbook.local> (raw)
In-Reply-To: <20250326110455.GAZ-PfV3kOiQw97fDj@fat_crate.local>
On Wed, Mar 26, 2025 at 12:04:55PM +0100, Borislav Petkov wrote:
> + Linus so that he can whack it before it spreads any further.
>
> On Wed, Feb 19, 2025 at 10:20:57AM +0100, Roger Pau Monne wrote:
> > Setting pci_msi_ignore_mask inhibits the toggling of the mask bit for both
> > MSI and MSI-X entries globally, regardless of the IRQ chip they are using.
> > Only Xen sets the pci_msi_ignore_mask when routing physical interrupts over
> > event channels, to prevent PCI code from attempting to toggle the maskbit,
> > as it's Xen that controls the bit.
> >
> > However, the pci_msi_ignore_mask being global will affect devices that use
> > MSI interrupts but are not routing those interrupts over event channels
> > (not using the Xen pIRQ chip). One example is devices behind a VMD PCI
> > bridge. In that scenario the VMD bridge configures MSI(-X) using the
> > normal IRQ chip (the pIRQ one in the Xen case), and devices behind the
> > bridge configure the MSI entries using indexes into the VMD bridge MSI
> > table. The VMD bridge then demultiplexes such interrupts and delivers to
> > the destination device(s). Having pci_msi_ignore_mask set in that scenario
> > prevents (un)masking of MSI entries for devices behind the VMD bridge.
> >
> > Move the signaling of no entry masking into the MSI domain flags, as that
> > allows setting it on a per-domain basis. Set it for the Xen MSI domain
> > that uses the pIRQ chip, while leaving it unset for the rest of the
> > cases.
> >
> > Remove pci_msi_ignore_mask at once, since it was only used by Xen code, and
> > with Xen dropping usage the variable is unneeded.
> >
> > This fixes using devices behind a VMD bridge on Xen PV hardware domains.
> >
> > Albeit Devices behind a VMD bridge are not known to Xen, that doesn't mean
> > Linux cannot use them. By inhibiting the usage of
> > VMD_FEAT_CAN_BYPASS_MSI_REMAP and the removal of the pci_msi_ignore_mask
> > bodge devices behind a VMD bridge do work fine when use from a Linux Xen
> > hardware domain. That's the whole point of the series.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> > Acked-by: Juergen Gross <jgross@suse.com>
>
> Did anyone actually test this on a normal KVM guest?
Sorry, not on KVM, I've tested on Xen and native. It also seems to be
somewhat tied to the Kconfig, as I couldn't reproduce it with my
Kconfig, maybe didn't have the required VirtIO options enabled.
It's fixed by:
https://lore.kernel.org/xen-devel/87v7rxzct0.ffs@tglx/
Waiting for Thomas to formally sent that.
Thanks, Roger.
next prev parent reply other threads:[~2025-03-26 11:14 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-19 9:20 [PATCH v3 0/3] xen: Fix usage of devices behind a VMD bridge Roger Pau Monne
2025-02-19 9:20 ` [PATCH v3 1/3] xen/pci: Do not register devices with segments >= 0x10000 Roger Pau Monne
2025-02-19 9:20 ` [PATCH v3 2/3] PCI: vmd: Disable MSI remapping bypass under Xen Roger Pau Monne
2025-03-03 14:16 ` Roger Pau Monné
2025-03-20 21:06 ` Bjorn Helgaas
2025-02-19 9:20 ` [PATCH v3 3/3] PCI/MSI: Convert pci_msi_ignore_mask to per MSI domain flag Roger Pau Monne
2025-03-20 21:07 ` Bjorn Helgaas
2025-03-21 8:00 ` Jürgen Groß
2025-03-24 14:29 ` Daniel Gomez
2025-03-24 17:51 ` Roger Pau Monné
2025-03-24 18:58 ` Daniel Gomez
2025-03-24 19:18 ` Roger Pau Monné
2025-03-24 20:45 ` Daniel Gomez
2025-03-25 8:11 ` Thomas Gleixner
2025-03-25 9:20 ` Thomas Gleixner
2025-03-25 9:47 ` Daniel Gomez
2025-03-25 10:22 ` Roger Pau Monné
2025-03-25 10:27 ` Thomas Gleixner
2025-03-25 10:55 ` Roger Pau Monné
2025-03-26 8:14 ` Thomas Gleixner
2025-03-26 8:10 ` Roger Pau Monné
2025-03-26 11:26 ` Marek Szyprowski
2025-03-26 12:05 ` [PATCH] PCI/MSI: Handle the NOMASK flag correctly for all PCI/MSI backends Thomas Gleixner
2025-03-26 12:09 ` Jürgen Groß
2025-03-26 12:46 ` Thomas Gleixner
2025-03-26 12:16 ` Juergen Gross
2025-03-26 14:39 ` [tip: timers/urgent] " tip-bot2 for Thomas Gleixner
2025-03-30 14:57 ` [PATCH] " Bert Karwatzki
2025-03-26 11:04 ` [PATCH v3 3/3] PCI/MSI: Convert pci_msi_ignore_mask to per MSI domain flag Borislav Petkov
2025-03-26 11:14 ` Roger Pau Monné [this message]
2025-03-26 11:21 ` Borislav Petkov
2025-03-06 8:48 ` [PATCH v3 0/3] xen: Fix usage of devices behind a VMD bridge Roger Pau Monné
2025-03-20 16:21 ` Roger Pau Monné
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=Z-PhgWQMHjxbac3b@macbook.local \
--to=roger.pau@citrix.com \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.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.