From: Keith Busch <keith.busch@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Derrick, Jonathan" <jonathan.derrick@intel.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
Jens Axboe <axboe@fb.com>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
Alex Gagniuc <alex_gagniuc@dellteam.com>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] nvme-pci: Prevent mmio reads if pci channel offline
Date: Fri, 22 Feb 2019 14:59:38 -0700 [thread overview]
Message-ID: <20190222215938.GG10237@localhost.localdomain> (raw)
In-Reply-To: <CAHk-=wjmjHyovjtzaq=HSegEpiO2SXWaYfJ6qsJrZhXg_YSx5g@mail.gmail.com>
On Fri, Feb 22, 2019 at 01:28:42PM -0800, Linus Torvalds wrote:
> On Thu, Feb 21, 2019 at 5:07 PM Jon Derrick <jonathan.derrick@intel.com> wrote:
> >
> > Some platforms don't seem to easily tolerate non-posted mmio reads on
> > lost (hot removed) devices. This has been noted in previous
> > modifications to other layers where an mmio read to a lost device could
> > cause an undesired firmware intervention [1][2].
>
> This is broken, and whatever platform that requires this is broken.
>
> This has absolutely nothing to do with nvme, and should not be handled
> by a driver.
>
> The platform code should be fixed.
This is, of course, the correct answer. We just find platform firmware
uncooperative, so we see these attempts to avoid them.
I really don't like this driver piecemeal approach if we're going to
quirk around these platforms, though. I'd rather see the invalidated
address ranges remapped to a fault handler fixup exception once and be
done with it.
Or we can say you don't get to use this feature if you bought that
hardware.
next prev parent reply other threads:[~2019-02-22 21:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-22 1:05 [PATCH] nvme-pci: Prevent mmio reads if pci channel offline Jon Derrick
2019-02-22 21:28 ` Linus Torvalds
2019-02-22 21:59 ` Keith Busch [this message]
2019-02-24 20:37 ` Alex_Gagniuc
2019-02-24 22:42 ` Linus Torvalds
2019-02-24 23:27 ` Alex_Gagniuc
2019-02-25 0:43 ` Linus Torvalds
2019-02-25 15:55 ` Keith Busch
2019-02-26 22:37 ` Alex_Gagniuc
2019-02-27 1:01 ` Linus Torvalds
2019-02-27 16:42 ` Alex_Gagniuc
2019-02-27 17:51 ` Keith Busch
2019-02-27 18:07 ` Alex_Gagniuc
2019-02-27 17:55 ` Austin.Bolen
2019-02-27 20:04 ` Austin.Bolen
2019-02-28 14:16 ` Christoph Hellwig
2019-02-28 23:10 ` Austin.Bolen
2019-02-28 23:20 ` Keith Busch
2019-02-28 23:43 ` Austin.Bolen
2019-03-01 0:30 ` Keith Busch
2019-03-01 1:52 ` Austin.Bolen
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=20190222215938.GG10237@localhost.localdomain \
--to=keith.busch@intel.com \
--cc=alex_gagniuc@dellteam.com \
--cc=axboe@fb.com \
--cc=hch@lst.de \
--cc=jonathan.derrick@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox