All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: Christoph Hellwig <hch@lst.de>,
	"Koenig, Christian" <Christian.Koenig@amd.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH] PCI/P2PDMA: Root complex whitelist should not apply when an IOMMU is present
Date: Thu, 23 May 2019 17:59:22 +0200	[thread overview]
Message-ID: <20190523155922.GA21552@lst.de> (raw)
In-Reply-To: <252313a9-9af4-14bd-1bfa-1c2327baf2b2@deltatee.com>

On Thu, May 23, 2019 at 09:53:53AM -0600, Logan Gunthorpe wrote:
> > The problem shows up if pci_bus_address() returns a different address
> > than pci_resource_start(), should be easy to check if that happens.
> > IIRC it is something mostly seen on embedded SOCs.
> > 
> 
> I think it's a bit more complicated then that: If you're calling
> dma_map_resource() to program the IOMMU then I'm pretty sure you'd want
> to use the pci_resource_start() address as the phys_addr_t. If you're
> bypassing the root complex (like the current p2pdma code enforces), then
> you'd simply use a pci_bus_address() directly as the dma_addr and would
> not program the IOMMU at all seeing it's not involved (which is what is
> currently done).

True.  What we need is:

 if (both device are behind the same root port (using a switch)) {
 	use the current direct map + offset code
 } else {
 	call ->map_resource()
 }

  reply	other threads:[~2019-05-23 15:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <a98bff67-a76e-4ddc-a317-96f2bdc9af72@email.android.com>
2019-05-22 20:41 ` [PATCH] PCI/P2PDMA: Root complex whitelist should not apply when an IOMMU is present Logan Gunthorpe
2019-05-23  8:12   ` Koenig, Christian
2019-05-23  9:43     ` Christoph Hellwig
2019-05-23  9:48       ` Koenig, Christian
2019-05-23  9:50         ` Christoph Hellwig
2019-05-23 10:06           ` Koenig, Christian
2019-05-23 10:26             ` Christoph Hellwig
2019-05-23 15:59               ` Logan Gunthorpe
2019-05-23 15:53           ` Logan Gunthorpe
2019-05-23 15:59             ` Christoph Hellwig [this message]
2019-05-24 12:40               ` Koenig, Christian
2019-05-24 14:12                 ` Christoph Hellwig
2019-05-24 16:18                   ` Logan Gunthorpe
2019-05-24 16:06                 ` Logan Gunthorpe
2019-05-23 16:14         ` Logan Gunthorpe
2019-05-23 15:47     ` Logan Gunthorpe
2019-05-22 20:12 Logan Gunthorpe
2019-06-18 20:40 ` Bjorn Helgaas
2019-06-18 20:51   ` Logan Gunthorpe
2019-06-18 23:50     ` Logan Gunthorpe
2019-06-19  9:26       ` Koenig, Christian
2019-06-19  9:29         ` Christoph Hellwig
2019-06-19  9:39           ` Koenig, Christian

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=20190523155922.GA21552@lst.de \
    --to=hch@lst.de \
    --cc=Christian.Koenig@amd.com \
    --cc=bhelgaas@google.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=logang@deltatee.com \
    /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.