All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Alexander Gruhlke <gruhlke@mailbox.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Lukas Wunner <lukas@wunner.de>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Alex Williamson <alex@shazbot.org>,
	Hui Wang <hui.wang@canonical.com>, Linux-Fan <info@masysma.net>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	regressions@lists.linux.dev
Subject: Re: [PATCH v3 0/2] PCI: Wait after FLR for devices that don't honor Immediate Readiness
Date: Mon, 12 Oct 2026 17:23:31 -0500	[thread overview]
Message-ID: <20261012222331.GA1411603@bhelgaas> (raw)
In-Reply-To: <20261011190145.23621-1-gruhlke@mailbox.org>

On Sun, Oct 11, 2026 at 09:01:43PM +0200, Alexander Gruhlke wrote:
> Since v7.2, VFIO passthrough of a Samsung 990 PRO NVMe [144d:a80c] fails
> on the second VM start, and the device is inaccessible until reboot.  The
> drive advertises Immediate Readiness but returns ~0 for up to 7 ms after
> FLR, so since 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring
> BARs") the config restore after FLR is lost.
> 
> Patch 1 ignores Immediate Readiness on that drive.  Firmware 8B2QJXD7
> fixes it, but the Revision ID and Subsystem ID don't change, so the
> quirk can't tell firmware versions apart.  A 990 EVO Plus [144d:a80d]
> reports the same errors [1], but it isn't confirmed to advertise
> Immediate Readiness, so it's not included.
> 
> Patch 2 is independent and keeps pci_dev_wait() from treating ~0 as
> ready with RRS Software Visibility, which also affects the Intel
> [8086:0a54] in the open d591f6804e7e regression.  Hui, Linux-Fan: testing
> patch 2 on that drive would be appreciated.
> 
> Tested on v7.2.9 (Ryzen 9 7950X, X670E): with patch 1 and drive firmware
> 1B2QJXD7, three VM starts in a row work, and every FLR reports "ready
> 0ms after FLR".  With firmware 8B2QJXD7, plain v7.2.9 works.
> 
> Patch 2 is only tested for regressions, as the drive no longer shows the
> problem: below a Root Port with RRS SV, three VM starts work and every
> FLR reports "ready 0ms after FLR".  The VF path is untested with the
> patch, but on another machine, an X550 VF below a Root Port with RRS SV
> reads ~0 from the Vendor ID and valid data from the Command register
> 100 ms after FLR.  v1's variant, which read the Command register, was
> tested against the old firmware, and the drive's Vendor ID read ~0
> while it wasn't ready.  Applies to pci/next.
> 
> Changes since v2:
> - Patch 1: add Lukas's Reviewed-by
> - Patch 2: read the Command register on VFs whose Vendor ID reads ~0
>   instead of treating them as ready (Lukas, sashiko)
> 
> v2: https://lore.kernel.org/r/20261011163249.18479-1-gruhlke@mailbox.org
> v1: https://lore.kernel.org/r/20261010160529.27974-1-gruhlke@mailbox.org
> 
> [1] https://bbs.archlinux.org/viewtopic.php?id=314833
> 
> Alexander Gruhlke (2):
>   PCI: Ignore Immediate Readiness on Samsung 990 PRO NVMe
>   PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV
> 
>  drivers/pci/pci.c    | 14 ++++++++++----
>  drivers/pci/quirks.c | 11 +++++++++++
>  2 files changed, 21 insertions(+), 4 deletions(-)

Applied to pci/reset for v7.4, thank you!

      parent reply	other threads:[~2026-10-12 22:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-11 19:01 [PATCH v3 0/2] PCI: Wait after FLR for devices that don't honor Immediate Readiness Alexander Gruhlke
2026-10-11 19:01 ` [PATCH v3 1/2] PCI: Ignore Immediate Readiness on Samsung 990 PRO NVMe Alexander Gruhlke
2026-10-11 19:14   ` sashiko-bot
2026-10-11 19:20     ` Alexander Gruhlke
2026-10-11 19:01 ` [PATCH v3 2/2] PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV Alexander Gruhlke
2026-10-11 19:09   ` sashiko-bot
2026-10-12 10:11   ` Lukas Wunner
2026-10-12 22:23 ` Bjorn Helgaas [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=20261012222331.GA1411603@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=alex@shazbot.org \
    --cc=bhelgaas@google.com \
    --cc=gruhlke@mailbox.org \
    --cc=hui.wang@canonical.com \
    --cc=info@masysma.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=rafael@kernel.org \
    --cc=regressions@lists.linux.dev \
    /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.