All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Koenig, Christian" <Christian.Koenig@amd.com>
Cc: Logan Gunthorpe <logang@deltatee.com>,
	"rdunlap@infradead.org" <rdunlap@infradead.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH] PCI/P2PDMA: start with a whitelist for root complexes
Date: Fri, 19 Apr 2019 13:47:48 -0500	[thread overview]
Message-ID: <20190419184748.GF173520@google.com> (raw)
In-Reply-To: <ef5839af-4ddb-2e68-ebf3-f11fa01b0403@amd.com>

On Fri, Apr 19, 2019 at 02:24:18PM +0000, Koenig, Christian wrote:
> Am 18.04.19 um 19:24 schrieb Bjorn Helgaas:
> > On Thu, Apr 18, 2019 at 10:58:55AM -0600, Logan Gunthorpe wrote:
> >> On 2019-04-18 10:33 a.m., Bjorn Helgaas wrote:
> >>> On Thu, Apr 18, 2019 at 01:58:59PM +0200, Christian König wrote:
> >>>> A lot of root complexes can still do P2P even when PCI devices
> >>>> don't share a common upstream bridge.
> >>>>
> >>>> Start adding a whitelist and allow P2P if both participants are
> >>>> attached to known good root complex.
> >>> Is there a plan for addressing this in a generic way that doesn't
> >>> require an OS modification for every new "known good root complex",
> >>> e.g., some PCIe or ACPI spec update that allows the OS to discover
> >>> this?
> >> I'm aware of work going on in the PCI SIG to address this [1].
> >>
> >> But I expect it's going to be a long time before actual hardware advertises
> >> this capability to indicate support. So in the interim we either need to not
> >> use p2pdma on root complexes or create a white list. I'm in favour of the
> >> white list approach.
> > I agree we need a whitelist; I just want to make sure we also make
> > progress on some way to limit the amount of time we need to update it.
> 
> Well as far as I know at least for AMD there is also a vendor specific 
> way to figure out if a chipset does P2P routing or not. So you don't 
> need every possible combination listed.
> 
> It's perfectly possible that Intel, ARM and PowerPC have something 
> similar and with all those on board you have pretty much every 
> interesting case covered.
> 
> I will try to dig something up into that direction.
> 
> Another problem is also that some root complexes have very very strange 
> limitations on the routing which are hard to handle. For example some 
> old chipsets can do P2P, but only for writes and not reads!
> 
> Anyway at least for my current use case a simple whitelist with 
> vendor/device should be sufficient, so I'm fine with maintaining that 
> for now. But on the other hand I also understand that in 10+ years we 
> don't want a list with 200 entries here....

Right.  And it's not just *you*; maintaining a list like that is also
a burden for me and every distro maintainer who has to backport
updates.

And the fact that it's not covered by any spec also means we're open
to all kinds of quirks about how it interacts with things that *are*
in the spec: ACS, ATS, the read/write thing you mentioned, ...

> >> [1] https://lore.kernel.org/linux-pci/20181210115653.0000615a@huawei.com/

  reply	other threads:[~2019-04-19 18:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-18 11:58 [PATCH] PCI/P2PDMA: start with a whitelist for root complexes Christian König
2019-04-18 16:33 ` Bjorn Helgaas
2019-04-18 16:58   ` Logan Gunthorpe
2019-04-18 17:24     ` Bjorn Helgaas
2019-04-19 14:24       ` Koenig, Christian
2019-04-19 18:47         ` Bjorn Helgaas [this message]
2019-04-18 16:45 ` Logan Gunthorpe
2019-04-19 19:19 ` Bjorn Helgaas
2019-04-24  8:51   ` Christian König
2019-05-01 21:58 ` Bjorn Helgaas

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=20190419184748.GF173520@google.com \
    --to=helgaas@kernel.org \
    --cc=Christian.Koenig@amd.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=rdunlap@infradead.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.