From: Alex Williamson <alex.williamson@redhat.com>
To: Keith Busch <keith.busch@intel.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH 2/2] PCI: NVMe device specific reset quirk
Date: Mon, 23 Jul 2018 17:08:12 -0600 [thread overview]
Message-ID: <20180723170812.177a7161@t450s.home> (raw)
In-Reply-To: <20180723224507.GA11656@localhost.localdomain>
On Mon, 23 Jul 2018 16:45:08 -0600
Keith Busch <keith.busch@intel.com> wrote:
> On Mon, Jul 23, 2018 at 04:24:31PM -0600, Alex Williamson wrote:
> > Take advantage of NVMe devices using a standard interface to quiesce
> > the controller prior to reset, including device specific delays before
> > and after that reset. This resolves several NVMe device assignment
> > scenarios with two different vendors. The Intel DC P3700 controller
> > has been shown to only work as a VM boot device on the initial VM
> > startup, failing after reset or reboot, and also fails to initialize
> > after hot-plug into a VM. Adding a delay after FLR resolves these
> > cases. The Samsung SM961/PM961 (960 EVO) sometimes fails to return
> > from FLR with the PCI config space reading back as -1. A reproducible
> > instance of this behavior is resolved by clearing the enable bit in
> > the configuration register and waiting for the ready status to clear
> > (disabling the NVMe controller) prior to FLR.
> >
> > As all NVMe devices make use of this standard interface and the NVMe
> > specification also requires PCIe FLR support, we can apply this quirk
> > to all devices with matching class code.
>
> Shouldn't this go in the nvme driver's reset_prepare/reset_done callbacks?
The scenario I'm trying to fix is device assignment, the nvme driver
isn't in play there. The device is bound to the vfio-pci driver at the
time of these resets. Thanks,
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@redhat.com>
To: Keith Busch <keith.busch@intel.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH 2/2] PCI: NVMe device specific reset quirk
Date: Mon, 23 Jul 2018 17:08:12 -0600 [thread overview]
Message-ID: <20180723170812.177a7161@t450s.home> (raw)
In-Reply-To: <20180723224507.GA11656@localhost.localdomain>
On Mon, 23 Jul 2018 16:45:08 -0600
Keith Busch <keith.busch@intel.com> wrote:
> On Mon, Jul 23, 2018 at 04:24:31PM -0600, Alex Williamson wrote:
> > Take advantage of NVMe devices using a standard interface to quiesce
> > the controller prior to reset, including device specific delays before
> > and after that reset. This resolves several NVMe device assignment
> > scenarios with two different vendors. The Intel DC P3700 controller
> > has been shown to only work as a VM boot device on the initial VM
> > startup, failing after reset or reboot, and also fails to initialize
> > after hot-plug into a VM. Adding a delay after FLR resolves these
> > cases. The Samsung SM961/PM961 (960 EVO) sometimes fails to return
> > from FLR with the PCI config space reading back as -1. A reproducible
> > instance of this behavior is resolved by clearing the enable bit in
> > the configuration register and waiting for the ready status to clear
> > (disabling the NVMe controller) prior to FLR.
> >
> > As all NVMe devices make use of this standard interface and the NVMe
> > specification also requires PCIe FLR support, we can apply this quirk
> > to all devices with matching class code.
>
> Shouldn't this go in the nvme driver's reset_prepare/reset_done callbacks?
The scenario I'm trying to fix is device assignment, the nvme driver
isn't in play there. The device is bound to the vfio-pci driver at the
time of these resets. Thanks,
Alex
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
WARNING: multiple messages have this Message-ID (diff)
From: alex.williamson@redhat.com (Alex Williamson)
Subject: [PATCH 2/2] PCI: NVMe device specific reset quirk
Date: Mon, 23 Jul 2018 17:08:12 -0600 [thread overview]
Message-ID: <20180723170812.177a7161@t450s.home> (raw)
In-Reply-To: <20180723224507.GA11656@localhost.localdomain>
On Mon, 23 Jul 2018 16:45:08 -0600
Keith Busch <keith.busch@intel.com> wrote:
> On Mon, Jul 23, 2018@04:24:31PM -0600, Alex Williamson wrote:
> > Take advantage of NVMe devices using a standard interface to quiesce
> > the controller prior to reset, including device specific delays before
> > and after that reset. This resolves several NVMe device assignment
> > scenarios with two different vendors. The Intel DC P3700 controller
> > has been shown to only work as a VM boot device on the initial VM
> > startup, failing after reset or reboot, and also fails to initialize
> > after hot-plug into a VM. Adding a delay after FLR resolves these
> > cases. The Samsung SM961/PM961 (960 EVO) sometimes fails to return
> > from FLR with the PCI config space reading back as -1. A reproducible
> > instance of this behavior is resolved by clearing the enable bit in
> > the configuration register and waiting for the ready status to clear
> > (disabling the NVMe controller) prior to FLR.
> >
> > As all NVMe devices make use of this standard interface and the NVMe
> > specification also requires PCIe FLR support, we can apply this quirk
> > to all devices with matching class code.
>
> Shouldn't this go in the nvme driver's reset_prepare/reset_done callbacks?
The scenario I'm trying to fix is device assignment, the nvme driver
isn't in play there. The device is bound to the vfio-pci driver at the
time of these resets. Thanks,
Alex
next prev parent reply other threads:[~2018-07-23 23:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-23 22:24 [PATCH 0/2] PCI: NVMe reset quirk Alex Williamson
2018-07-23 22:24 ` Alex Williamson
2018-07-23 22:24 ` [PATCH 1/2] PCI: Export pcie_has_flr() Alex Williamson
2018-07-23 22:24 ` Alex Williamson
2018-07-23 22:24 ` Alex Williamson
2018-07-23 22:24 ` [PATCH 2/2] PCI: NVMe device specific reset quirk Alex Williamson
2018-07-23 22:24 ` Alex Williamson
2018-07-23 22:24 ` Alex Williamson
2018-07-23 22:45 ` Keith Busch
2018-07-23 22:45 ` Keith Busch
2018-07-23 22:45 ` Keith Busch
2018-07-23 23:08 ` Alex Williamson [this message]
2018-07-23 23:08 ` Alex Williamson
2018-07-23 23:08 ` Alex Williamson
2018-07-23 22:45 ` Bjorn Helgaas
2018-07-23 22:45 ` Bjorn Helgaas
2018-07-23 22:45 ` Bjorn Helgaas
2018-07-24 0:11 ` Alex Williamson
2018-07-24 0:11 ` 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=20180723170812.177a7161@t450s.home \
--to=alex.williamson@redhat.com \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.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.