From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alexey Kardashevskiy <aik@ozlabs.ru>,
Bjorn Helgaas <helgaas@kernel.org>,
Hannes Reinecke <hare@suse.de>
Cc: Alexander Duyck <alexander.duyck@gmail.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Babu Moger <babu.moger@oracle.com>,
Paul Mackerras <paulus@samba.org>,
Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access
Date: Wed, 10 Aug 2016 09:59:39 +1000 [thread overview]
Message-ID: <1470787179.3015.78.camel@kernel.crashing.org> (raw)
In-Reply-To: <bc3c39b1-cbff-99a5-8fe7-9add14f2c6f5@ozlabs.ru>
> On Tue, 2016-08-09 at 22:54 +1000, Alexey Kardashevskiy wrote:
> The cxgb3 driver is reading the second bit starting from 0xc00 but since
> the size is wrongly detected as 0x7c, VFIO blocks access beyond it and the
> guest driver fails to probe.
>
> I also cannot find a clause in the PCI 3.0 spec saying that there must be
> just a single block, is it there?
>
> What would the correct fix be? Scanning all 32k of VPD is not an option I
> suppose as this is what this patch is trying to avoid. Thanks.
Additionally, Hannes, Alex, I argue that for platforms with proper HW isolation
(such as ppc with EEH), we shouldn't have VFIO try to virtualize that stuff.
It's the same problem with the bloody MSIs. Just let the guest config space
accesses go straight through. Its drivers knows better what the HW needs and
if it crashes the card, too bad for that guest.
That being said, we don't have fine grained per-device PERST control on
all systems so there may not be recovery from that but on the other hand,
our constant attempts at "filtering" what the guest does to the HW is
imho, doomed.
Cheers,
Ben.
next prev parent reply other threads:[~2016-08-10 0:00 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-13 11:25 [PATCHv2 0/4] PCI VPD access fixes Hannes Reinecke
2016-01-13 11:25 ` [PATCHv2 1/4] pci: Update VPD definitions Hannes Reinecke
2016-01-13 11:25 ` [PATCHv2 2/4] pci: allow access to VPD attributes with size '0' Hannes Reinecke
2016-02-09 20:53 ` Bjorn Helgaas
2016-02-10 7:17 ` Hannes Reinecke
2016-01-13 11:25 ` [PATCHv2 3/4] pci: Determine actual VPD size on first access Hannes Reinecke
2016-02-09 21:04 ` Bjorn Helgaas
2016-02-10 7:24 ` Hannes Reinecke
2016-08-09 12:54 ` Alexey Kardashevskiy
2016-08-09 18:12 ` Alexander Duyck
2016-08-10 0:03 ` Benjamin Herrenschmidt
2016-08-10 15:47 ` Alexander Duyck
2016-08-10 23:54 ` Benjamin Herrenschmidt
2016-08-11 18:52 ` Alexander Duyck
2016-08-11 20:17 ` Alex Williamson
2016-08-12 5:11 ` Benjamin Herrenschmidt
2016-08-15 17:59 ` Rustad, Mark D
2016-08-15 22:23 ` Benjamin Herrenschmidt
2016-08-15 22:33 ` Benjamin Herrenschmidt
2016-08-15 23:16 ` Rustad, Mark D
2016-08-16 0:13 ` Benjamin Herrenschmidt
2016-08-16 1:40 ` Alexey Kardashevskiy
2016-08-10 6:23 ` Hannes Reinecke
2016-08-11 10:03 ` [RFC PATCH kernel] PCI: Enable access to custom VPD for Chelsio devices (cxgb3) Alexey Kardashevskiy
2016-09-06 15:48 ` Bjorn Helgaas
2016-09-06 18:30 ` Alexander Duyck
2016-09-21 10:53 ` Alexey Kardashevskiy
2016-08-09 23:59 ` Benjamin Herrenschmidt [this message]
2016-01-13 11:25 ` [PATCHv2 4/4] pci: Blacklist vpd access for buggy devices Hannes Reinecke
2016-01-19 20:57 ` [PATCH v3 " Babu Moger
2016-02-09 21:07 ` [PATCHv2 " Bjorn Helgaas
2016-02-09 21:24 ` Babu Moger
2016-01-15 1:07 ` [PATCHv2 0/4] PCI VPD access fixes Seymour, Shane M
2016-01-15 14:10 ` Babu Moger
2016-01-15 14:18 ` Hannes Reinecke
2016-01-19 20:53 ` Babu Moger
2016-01-21 18:34 ` [PATCH v4 4/4] pci: Blacklist vpd access for buggy devices Babu Moger
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=1470787179.3015.78.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=alexander.duyck@gmail.com \
--cc=babu.moger@oracle.com \
--cc=hare@suse.de \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=paulus@samba.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.