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

[Alexander Gruhlke <gruhlke@mailbox.org>]

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