From: Christoph Hellwig <hch@infradead.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Robert Straw <drbawb@fatalsyntax.com>,
bhelgaas@google.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, alex.williamson@redhat.com
Subject: Re: [PATCH v2] PCI: Disable Samsung SM951/PM951 NVMe before FLR
Date: Thu, 1 Jul 2021 20:59:49 +0100 [thread overview]
Message-ID: <YN4etaP6hInKvSgG@infradead.org> (raw)
In-Reply-To: <20210701193856.GA82535@bjorn-Precision-5520>
On Thu, Jul 01, 2021 at 02:38:56PM -0500, Bjorn Helgaas wrote:
> On Fri, Apr 30, 2021 at 06:01:19PM -0500, Robert Straw wrote:
> > The SM951/PM951, when used in conjunction with the vfio-pci driver and
> > passed to a KVM guest, can exhibit the fatal state addressed by the
> > existing `nvme_disable_and_flr` quirk. If the guest cleanly shuts down
> > the SSD, and vfio-pci attempts an FLR to the device while it is in this
> > state, the nvme driver will fail when it attempts to bind to the device
> > after the FLR due to the frozen config area, e.g:
> >
> > nvme nvme2: frozen state error detected, reset controller
> > nvme nvme2: Removing after probe failure status: -12
> >
> > By including this older model (Samsung 950 PRO) of the controller in the
> > existing quirk: the device is able to be cleanly reset after being used
> > by a KVM guest.
> >
> > Signed-off-by: Robert Straw <drbawb@fatalsyntax.com>
>
> Applied to pci/virtualization for v5.14, thanks!
FYI, I really do not like the idea of the PCIe core messing with NVMe
registers like this.
next prev parent reply other threads:[~2021-07-01 20:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-30 23:01 [PATCH v2] PCI: Disable Samsung SM951/PM951 NVMe before FLR Robert Straw
2021-07-01 19:38 ` Bjorn Helgaas
2021-07-01 19:59 ` Christoph Hellwig [this message]
2021-07-01 20:15 ` Bjorn Helgaas
2021-07-01 21:24 ` Alex Williamson
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=YN4etaP6hInKvSgG@infradead.org \
--to=hch@infradead.org \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=drbawb@fatalsyntax.com \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.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.