[PATCH 0/2] PCI: Wait after FLR for devices that don't honor Immediate Readiness

[PATCH 0/2] PCI: Wait after FLR for devices that don't honor Immediate Readiness

[Alexander Gruhlke]

Since v7.2, VFIO passthrough of a Samsung 990 PRO NVMe [144d:a80c] fails
on the second VM start (QEMU: "invalid PCI interrupt pin 255"), and the
device is inaccessible until reboot.  Reverting 10baa9b4df40 ("PCI: Drop
unnecessary retries when restoring BARs") fixes it.

The drive advertises Immediate Readiness, so pcie_flr() doesn't wait,
but it returns ~0 for 1-7 ms after every FLR.  The config restore is
lost, and vfio-pci then saves and later restores an all-ones config
space.  The Root Port has RRS Software Visibility enabled, and the drive
returns ~0 rather than RRS, so pci_dev_wait() wouldn't catch it either.
That is the same problem as the open d591f6804e7e regression with the
Intel [8086:0a54], hence patch 1.

Tested on v7.2.9 (Ryzen 9 7950X, X670E): with the series, three VM
starts in a row work and pci_dev_wait() reports "ready 1ms" to "ready
7ms after FLR".  Applies to pci/next.

Another user reports the same with a 990 EVO Plus [144d:a80d]:
https://bbs.archlinux.org/viewtopic.php?id=314833

#regzbot introduced: 10baa9b4df40

Alexander Gruhlke (2):
  PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV
  PCI: Wait for readiness after FLR even with Immediate Readiness

 drivers/pci/pci.c | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

-- 
2.56.0

[PATCH 1/2] PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV

[Alexander Gruhlke]

With RRS Software Visibility, pci_dev_wait() considers a device ready as
soon as reading the Vendor ID doesn't return the RRS value.  Some devices
don't respond with RRS while they aren't ready, so the read returns ~0
and pci_dev_wait() stops waiting too early.  This was seen with Intel
[8086:0a54] and Samsung [144d:a80c] NVMe SSDs.

Also check the Command register for ~0, as without RRS Software
Visibility.

Fixes: d591f6804e7e ("PCI: Wait for device readiness with Configuration RRS")
Link: https://lore.kernel.org/r/20250611101442.387378-1-hui.wang@canonical.com
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Alexander Gruhlke <gruhlke@mailbox.org>
---
 drivers/pci/pci.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 350bae907e..26be5d1ca9 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1215,7 +1215,8 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
 	 * If the device is below a Root Port with Configuration RRS
 	 * Software Visibility enabled, reading the Vendor ID returns a
 	 * special data value if the device responded with RRS.  Read the
-	 * Vendor ID until we get non-RRS status.
+	 * Vendor ID until we get non-RRS status, then the Command register
+	 * as below.
 	 *
 	 * If there's no Root Port or Configuration RRS Software Visibility
 	 * is not enabled, the device may still respond with RRS, but
@@ -1235,8 +1236,11 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
 
 		if (root && root->config_rrs_sv) {
 			pci_read_config_dword(dev, PCI_VENDOR_ID, &id);
-			if (!pci_bus_rrs_vendor_id(id))
-				break;
+			if (!pci_bus_rrs_vendor_id(id)) {
+				pci_read_config_dword(dev, PCI_COMMAND, &id);
+				if (!PCI_POSSIBLE_ERROR(id))
+					break;
+			}
 		} else {
 			pci_read_config_dword(dev, PCI_COMMAND, &id);
 			if (!PCI_POSSIBLE_ERROR(id))
-- 
2.56.0

Re: [PATCH 1/2] PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV

[Lukas Wunner]

On Sat, Oct 10, 2026 at 06:05:28PM +0200, Alexander Gruhlke wrote:
> With RRS Software Visibility, pci_dev_wait() considers a device ready as
> soon as reading the Vendor ID doesn't return the RRS value.  Some devices
> don't respond with RRS while they aren't ready, so the read returns ~0
> and pci_dev_wait() stops waiting too early.  This was seen with Intel
> [8086:0a54] and Samsung [144d:a80c] NVMe SSDs.

If I understand the spec correctly (PCIe r7.1 sec 2.3.2), enabling
RRS Software Visibility at the Root Port doesn't mean that every
failed device access has to return 0x0001.

Rather, that value is only returned if the device sent an RRS Completion
to the Root Complex.

It seems support for RRS Completions in Endpoints is optional because the
"Implementation Note: Request Retry Status for Configuration Requests"
at the end of PCIe r7.1 sec 2.3.1 says devices are "permitted" to send
RRS Completions.  That's a spec term used if something is optional.
The device may send such Completions, but it doesn't have to.

Also, the device may not be accessible at all, in which case it's sending
no Completion to the Root Complex.

> @@ -1215,7 +1215,8 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
>  	 * If the device is below a Root Port with Configuration RRS
>  	 * Software Visibility enabled, reading the Vendor ID returns a
>  	 * special data value if the device responded with RRS.  Read the
> -	 * Vendor ID until we get non-RRS status.
> +	 * Vendor ID until we get non-RRS status, then the Command register
> +	 * as below.
>  	 *

The code comment should be rephrased such that "returns" is replaced
with "may return" because of the optionality of RRS Completions.

> @@ -1235,8 +1236,11 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
>  
>  		if (root && root->config_rrs_sv) {
>  			pci_read_config_dword(dev, PCI_VENDOR_ID, &id);
> -			if (!pci_bus_rrs_vendor_id(id))
> -				break;
> +			if (!pci_bus_rrs_vendor_id(id)) {
> +				pci_read_config_dword(dev, PCI_COMMAND, &id);
> +				if (!PCI_POSSIBLE_ERROR(id))
> +					break;
> +			}

I think it's sufficient if you just change the if-condition like this:

-			if (!pci_bus_rrs_vendor_id(id))
+			if (!pci_bus_rrs_vendor_id(id) &&
+			    !PCI_POSSIBLE_ERROR(id)) {

I don't see the need for the extra read of the Command register
you're performing.

Thanks,

Lukas

Re: [PATCH 1/2] PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV

[Alexander Gruhlke]

On Sat, Oct 10, 2026 at 08:36:38PM +0200, Lukas Wunner wrote:
> The code comment should be rephrased such that "returns" is replaced
> with "may return" because of the optionality of RRS Completions.

Will do in v2.

> I think it's sufficient if you just change the if-condition like this:
>
> -			if (!pci_bus_rrs_vendor_id(id))
> +			if (!pci_bus_rrs_vendor_id(id) &&
> +			    !PCI_POSSIBLE_ERROR(id)) {
>
> I don't see the need for the extra read of the Command register
> you're performing.

The Vendor ID of a VF always reads ~0, so with that condition, an FLR
of a VF below a Root Port with RRS SV would poll until the 60 s timeout
and fail.  That's why the branch without RRS SV reads the Command
register, too (see the comment above the loop).  I'll mention it in the
commit message.

Thanks,
Alexander

[PATCH 2/2] PCI: Wait for readiness after FLR even with Immediate Readiness

[Alexander Gruhlke]

pcie_flr() and pci_af_flr() skip pci_dev_wait() if the device advertises
Immediate Readiness.  Since commit 10baa9b4df40 ("PCI: Drop unnecessary
retries when restoring BARs"), the subsequent config restore isn't
retried, so it is lost if the device isn't ready after all.

The Samsung 990 PRO [144d:a80c] advertises Immediate Readiness but
returns ~0 for 1-7 ms after FLR, which breaks VFIO passthrough.  Keep
skipping the 100 ms delay, but call pci_dev_wait().

Fixes: 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring BARs")
Link: https://bbs.archlinux.org/viewtopic.php?id=314833
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Alexander Gruhlke <gruhlke@mailbox.org>
---
 drivers/pci/pci.c | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 26be5d1ca9..59856e3fdf 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4379,18 +4379,15 @@ int pcie_flr(struct pci_dev *dev)
 
 	pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_BCR_FLR);
 
-	if (dev->imm_ready)
-		goto done;
-
 	/*
 	 * Per PCIe r4.0, sec 6.6.2, a device must complete an FLR within
 	 * 100ms, but may silently discard requests while the FLR is in
 	 * progress.  Wait 100ms before trying to access the device.
 	 */
-	msleep(100);
+	if (!dev->imm_ready)
+		msleep(100);
 
 	ret = pci_dev_wait(dev, "FLR", PCIE_RESET_READY_POLL_MS);
-done:
 	pci_dev_reset_iommu_done(dev);
 	return ret;
 }
@@ -4456,19 +4453,16 @@ static int pci_af_flr(struct pci_dev *dev, bool probe)
 
 	pci_write_config_byte(dev, pos + PCI_AF_CTRL, PCI_AF_CTRL_FLR);
 
-	if (dev->imm_ready)
-		goto done;
-
 	/*
 	 * Per Advanced Capabilities for Conventional PCI ECN, 13 April 2006,
 	 * updated 27 July 2006; a device must complete an FLR within
 	 * 100ms, but may silently discard requests while the FLR is in
 	 * progress.  Wait 100ms before trying to access the device.
 	 */
-	msleep(100);
+	if (!dev->imm_ready)
+		msleep(100);
 
 	ret = pci_dev_wait(dev, "AF_FLR", PCIE_RESET_READY_POLL_MS);
-done:
 	pci_dev_reset_iommu_done(dev);
 	return ret;
 }
-- 
2.56.0

Re: [PATCH 2/2] PCI: Wait for readiness after FLR even with Immediate Readiness

[Lukas Wunner]

On Sat, Oct 10, 2026 at 06:05:29PM +0200, Alexander Gruhlke wrote:
> pcie_flr() and pci_af_flr() skip pci_dev_wait() if the device advertises
> Immediate Readiness.  Since commit 10baa9b4df40 ("PCI: Drop unnecessary
> retries when restoring BARs"), the subsequent config restore isn't
> retried, so it is lost if the device isn't ready after all.
> 
> The Samsung 990 PRO [144d:a80c] advertises Immediate Readiness but
> returns ~0 for 1-7 ms after FLR, which breaks VFIO passthrough.  Keep
> skipping the 100 ms delay, but call pci_dev_wait().

The device is incorrectly advertising Immediate Readiness, so I suggest
clearing dev->imm_ready from a DECLARE_PCI_FIXUP_FINAL() quirk and
emitting a message with KERN_INFO severity with something like
"Ignoring incorrectly advertised Immediate Readiness support".

Your patch instead silently works around the problem and that means
whenever a device manufacturer makes this mistake, their validation
engineers don't realize there's a bug and it never gets fixed and
keeps proliferating.  On the other hand, if (as I'm suggesting)
the bug is selectively worked around with a quirk only on affected
devices, then core code isn't polluted with a workaround only needed
by a handful of devices and the emitted message helps validation folks
learn there's a problem and demand a fix from the silicon team.

Thanks,

Lukas

Re: [PATCH 2/2] PCI: Wait for readiness after FLR even with Immediate Readiness

[Alexander Gruhlke]

On Sat, Oct 10, 2026 at 07:51:24PM +0200, Lukas Wunner wrote:
> The device is incorrectly advertising Immediate Readiness, so I suggest
> clearing dev->imm_ready from a DECLARE_PCI_FIXUP_FINAL() quirk and
> emitting a message with KERN_INFO severity with something like
> "Ignoring incorrectly advertised Immediate Readiness support".

Makes sense, I'll do that in v2.

Thanks,
Alexander