mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@kernel.org>
To: Yu Yang via B4 Relay <devnull+yuyang.kylinos.cn@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org, Michael Ellerman <mpe@ellerman.id.au>,
	Brett Creeley <brett.creeley@amd.com>,
	Shannon Nelson <sln@onemain.com>,
	linux-kernel@vger.kernel.org, Yu Yang <yuyang@kylinos.cn>
Subject: Re: [PATCH] PCI/MSI: Skip address mask check for MSI-X entries
Date: Mon, 09 Nov 2026 14:52:12 +0100	[thread overview]
Message-ID: <87mrriun77.ffs@fw13> (raw)
In-Reply-To: <20261109-pci-fix-msix-alloc-failure-v1-1-6370c0b84354@kylinos.cn>

On Mon, Nov 09 2026 at 17:24, Yu Yang via B4 Relay wrote:
> From: Yu Yang <yuyang@kylinos.cn>
>
> The AHCI controller on Zhaoxin ZX-200 platforms supports only 32-bit
> MSI addresses, but its MSI-X capability uses 64-bit message addresses.
> pci_msi_init() therefore sets dev->msi_addr_mask to DMA_BIT_MASK(32)
> based on the MSI capability.
>
> msi_verify_entries() is shared between the MSI and MSI-X setup paths.
> When the irq domain assigns an MSI-X message address above 4GB, the
> 32-bit mask inherited from the MSI capability causes MSI-X setup to
> fail with -EIO:
>
>   ahci 0000:09:0f.0: arch assigned 64-bit MSI address 0x8002a030040
>   above device MSI address mask 0xffffffff.
>   ...
>   ahci: probe of 0000:09:0f.0 failed with error -22.
>
> MSI-X table entries have a 64-bit message address field, so the 32-bit
> limit derived from the MSI capability does not apply to them.

That's just wrong. The limitation is not about the size of the address
field. The limitation is about the ability of the platform/device to
handle DMA to addresses above 4G.

There are devices/platforms out there which have such limitiations.

> Platforms that use msi_addr_mask to constrain MSI-X allocation, e.g.
> powerpc pseries/powernv and ionic on PPC64, already allocate addresses
> that satisfy the mask, so the verification is redundant for MSI-X.

The core cannot rely on random implementation details of drivers and
architecture code. It fails gracefully when the provided address limit
is violated to prevent hard to diagnose subsequent failures.

Coming back to your AHCI controller. That's broken to begin with. Assume
that MSI-X is not supported then MSI setup would fail the same way. You
don't notice because MSI-X is always enabled on x86 platforms.

Something like the uncompiled below should work. You get the idea.

Thanks,

        tglx
---
--- a/drivers/pci/msi/msi.c
+++ b/drivers/pci/msi/msi.c
@@ -430,6 +430,9 @@ int __pci_enable_msi_range(struct pci_de
 	if (!pci_msi_supported(dev, minvec) || dev->current_state != PCI_D0)
 		return -EINVAL;
 
+	if (dev->pci_msi_broken)
+		return -ENOTSUPP;
+
 	/* Check whether driver already requested MSI-X IRQs */
 	if (dev->msix_enabled) {
 		pci_info(dev, "can't enable MSI (MSI-X already enabled)\n");
--- a/drivers/pci/msi/pcidev_msi.c
+++ b/drivers/pci/msi/pcidev_msi.c
@@ -23,6 +23,14 @@ void pci_msi_init(struct pci_dev *dev)
 				      ctrl & ~PCI_MSI_FLAGS_ENABLE);
 	}
 
+	/*
+	 * PCI/MSI support on some devices is broken and would end up
+	 * restricting the MSI address mask which in turn breaks MSI-X support
+	 * on the device.
+	 */
+	if (dev->pci_msi__broken)
+		return;
+
 	if (!(ctrl & PCI_MSI_FLAGS_64BIT))
 		dev->msi_addr_mask = DMA_BIT_MASK(32);
 }
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -6449,6 +6449,12 @@ static void nvidia_ion_ahci_fixup(struct
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, 0x0ab8, nvidia_ion_ahci_fixup);
 
+static void zhaoxin_ahci_fixup(struct pci_dev *pdev)
+{
+	pdev->pci_msi_broken = 1;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ZHAOZIN, 0x????, zhaoxin_ahci_fixup);
+
 static void rom_bar_overlap_defect(struct pci_dev *dev)
 {
 	pci_info(dev, "working around ROM BAR overlap defect\n");
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -515,6 +515,7 @@ struct pci_dev {
 	unsigned int	rom_bar_overlap:1;	/* ROM BAR disable broken */
 	unsigned int	rom_attr_enabled:1;	/* Display of ROM attribute enabled? */
 	unsigned int	non_mappable_bars:1;	/* BARs can't be mapped by CPU or peers */
+	unsigned int	pci_msi_broken:1,	/* PCI/MSI support broken. PCI/MSI-X still works */
 	pci_dev_flags_t dev_flags;
 	atomic_t	enable_cnt;	/* pci_enable_device has been called */
 

      reply	other threads:[~2026-11-09 13:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09  9:24 Yu Yang via B4 Relay
2026-11-09 13:52 ` Thomas Gleixner [this message]

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=87mrriun77.ffs@fw13 \
    --to=tglx@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=brett.creeley@amd.com \
    --cc=devnull+yuyang.kylinos.cn@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=sln@onemain.com \
    --cc=yuyang@kylinos.cn \
    /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

all inboxes | Powered by JetHome®