From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: "Bjorn Helgaas" <helgaas@kernel.org>,
"Vidya Sagar" <vidyas@nvidia.com>,
treding@nvidia.com, bhelgaas@google.com,
linux-tegra@vger.kernel.org, linux-pci@vger.kernel.org,
kthota@nvidia.com, swarren@nvidia.com, mmaddireddy@nvidia.com,
"Michal Simek" <michal.simek@xilinx.com>,
"Sören Brinkmann" <soren.brinkmann@xilinx.com>,
"Simon Horman" <horms@verge.net.au>
Subject: Re: [PATCH] PCI: tegra: limit MSI target address to 32-bit
Date: Mon, 13 Nov 2017 11:06:14 +0000 [thread overview]
Message-ID: <20171113110614.GB27700@red-moon> (raw)
In-Reply-To: <3887d62c-98bb-04d5-5b40-96d5b7b43e63@arm.com>
On Fri, Nov 10, 2017 at 12:04:21PM +0000, Robin Murphy wrote:
[...]
> >>>>Do rcar_pcie_enable_msi() and xilinx_pcie_enable_msi() have a
> >>>>similar problem? They both use GFP_KERNEL, then virt_to_phys(),
> >>>>then write the result of virt_to_phys() using a 32-bit register
> >>>>write.
> >>>
> >>>Well, if those systems deal with 64-bit addresses and when an end
> >>>point is connected which supports only 32-bit MSI addresses, this
> >>>problem will surface when __get_free_pages() returns an address that
> >>>translates to a >32-bit address after virt_to_phys() call on it.
> >>
> >>I'd like to hear from the R-Car and Xilinx folks about (1) whether
> >>there's a potential issue with truncating a 64-bit address, and
> >>(2) whether that hardware works like Tegra, where the MSI write never
> >>reaches memory so we don't actually need to allocate a page.
> >>
> >>If all we need is to allocate a little bus address space for the MSI
> >>target, I'd like to figure out a better way to do that than
> >>__get_free_pages(). The current code seems a little buggy, and
> >>it's getting propagated through several drivers.
>
> The really neat version is to take a known non-memory physical
> address like the host controller's own MMIO region, which has no
> legitimate reason to ever be used as a DMA address.
True - that could be safe enough.
What about IOVAs though ? I suspect we should reserve the MSI address
range - it looks like there is something missing here.
> pcie-mediatek almost gets this right, but by using virt_to_phys() on
> an ioremapped address they end up with nonsense rather than the
> correct address
That definitely needs fixing given that it works by chance.
> (although realistically you would have to be extremely unlucky for
> said nonsense to collide with a real DMA address given to a PCI
> endpoint later). Following on from above, dma_map_resource() would
> be the foolproof way to get that right.
That's how it should be done then lest it trickles into other drivers
requiring a similar set-up.
Thanks,
Lorenzo
prev parent reply other threads:[~2017-11-13 11:06 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-06 18:03 [PATCH] PCI: tegra: limit MSI target address to 32-bit Vidya Sagar
2017-11-06 18:03 ` Vidya Sagar
2017-11-08 21:25 ` Bjorn Helgaas
2017-11-08 21:25 ` Bjorn Helgaas
2017-11-09 7:18 ` Vidya Sagar
2017-11-09 7:18 ` Vidya Sagar
2017-11-09 18:14 ` Bjorn Helgaas
2017-11-09 18:14 ` Bjorn Helgaas
2017-11-09 18:41 ` Vidya Sagar
2017-11-09 18:41 ` Vidya Sagar
2017-11-10 9:37 ` Thierry Reding
2017-11-10 9:37 ` Thierry Reding
2017-11-10 11:57 ` Arnd Bergmann
2017-11-10 11:57 ` Arnd Bergmann
2017-11-10 9:47 ` David Laight
2017-11-10 9:47 ` David Laight
2018-03-16 17:23 ` Lorenzo Pieralisi
2017-11-10 0:47 ` subrahmanya_lingappa
2017-11-10 0:47 ` subrahmanya_lingappa
2017-11-10 9:44 ` Thierry Reding
2017-11-10 9:44 ` Thierry Reding
2017-11-10 11:22 ` Lorenzo Pieralisi
2017-11-10 11:22 ` Lorenzo Pieralisi
2017-11-10 12:04 ` Robin Murphy
2017-11-10 12:04 ` Robin Murphy
2017-11-10 13:07 ` Thierry Reding
2017-11-10 13:07 ` Thierry Reding
2017-11-20 17:07 ` Lorenzo Pieralisi
2017-11-20 17:07 ` Lorenzo Pieralisi
2017-11-13 11:06 ` Lorenzo Pieralisi [this message]
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=20171113110614.GB27700@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=horms@verge.net.au \
--cc=kthota@nvidia.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=michal.simek@xilinx.com \
--cc=mmaddireddy@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=soren.brinkmann@xilinx.com \
--cc=swarren@nvidia.com \
--cc=treding@nvidia.com \
--cc=vidyas@nvidia.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.