From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Thierry Reding <treding@nvidia.com>
Cc: "Robin Murphy" <robin.murphy@arm.com>,
"Bjorn Helgaas" <helgaas@kernel.org>,
"Vidya Sagar" <vidyas@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>,
ryder.lee@mediatek.com
Subject: Re: [PATCH] PCI: tegra: limit MSI target address to 32-bit
Date: Mon, 20 Nov 2017 17:07:08 +0000 [thread overview]
Message-ID: <20171120170708.GA1941@red-moon> (raw)
In-Reply-To: <20171110130704.GA31316@ulmo>
[+ryder]
On Fri, Nov 10, 2017 at 02:07:05PM +0100, Thierry Reding wrote:
[...]
> > 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. 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 (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.
>
> Yes, that was our intention as well. Our initial plan was to use an
> address from the PCI aperture within Tegra that wasn't being used for
> any other purpose.
Hi Thierry,
to wrap up this thread, why an address from the PCI aperture and
not a host bridge register ?
I CC'ed Ryder so that he can explain to me please what:
PCIE_MSI_VECTOR and PCIE_IMSI_ADDR offsets in:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/host/pcie-mediatek.c?h=v4.14
register space represent (IIUC the driver uses:
virt_to_phys(port->base + PCIE_MSI_VECTOR);
as MSI doorbell address, which is wrong anyway as Robin explained, just
want to understand how that register was chosen - it is never written or
read in the driver so it is hard to figure that out) to understand
whether the approach can be replicated instead of relying on GFP_DMA
for pages allocation.
Thanks,
Lorenzo
> However, we ran into some odd corner cases where this wasn't working
> as expected. As a temporary solution we wanted to move to GFP_DMA32
> (or GFP_DMA) in order to support 32-bit only MSI endpoints.
>
> Eventually we'll want to get rid of the allocation altogether, we just
> need to find a set of values that work reliably. In the meantime, it
> looks as though GFP_DMA would be the right solution as long as we have
> to stick with __get_free_pages().
>
> Alternatively, since we've already verified that the MSI writes are
> never committed to memory, we could choose some random address pointing
> to system memory as well, but I'm reluctant to do that because it could
> end up being confusing for users (and developers) to see some random
> address showing up somewhere. A physical address such as the beginning
> of system memory should always work and might be unique enough to
> indicate that it is special.
>
> Thierry
WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
To: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: "Robin Murphy" <robin.murphy-5wv7dgnIgG8@public.gmane.org>,
"Bjorn Helgaas" <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
"Vidya Sagar" <vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kthota-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
"Michal Simek"
<michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>,
"Sören Brinkmann"
<soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>,
"Simon Horman" <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>,
ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org
Subject: Re: [PATCH] PCI: tegra: limit MSI target address to 32-bit
Date: Mon, 20 Nov 2017 17:07:08 +0000 [thread overview]
Message-ID: <20171120170708.GA1941@red-moon> (raw)
In-Reply-To: <20171110130704.GA31316@ulmo>
[+ryder]
On Fri, Nov 10, 2017 at 02:07:05PM +0100, Thierry Reding wrote:
[...]
> > 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. 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 (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.
>
> Yes, that was our intention as well. Our initial plan was to use an
> address from the PCI aperture within Tegra that wasn't being used for
> any other purpose.
Hi Thierry,
to wrap up this thread, why an address from the PCI aperture and
not a host bridge register ?
I CC'ed Ryder so that he can explain to me please what:
PCIE_MSI_VECTOR and PCIE_IMSI_ADDR offsets in:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/host/pcie-mediatek.c?h=v4.14
register space represent (IIUC the driver uses:
virt_to_phys(port->base + PCIE_MSI_VECTOR);
as MSI doorbell address, which is wrong anyway as Robin explained, just
want to understand how that register was chosen - it is never written or
read in the driver so it is hard to figure that out) to understand
whether the approach can be replicated instead of relying on GFP_DMA
for pages allocation.
Thanks,
Lorenzo
> However, we ran into some odd corner cases where this wasn't working
> as expected. As a temporary solution we wanted to move to GFP_DMA32
> (or GFP_DMA) in order to support 32-bit only MSI endpoints.
>
> Eventually we'll want to get rid of the allocation altogether, we just
> need to find a set of values that work reliably. In the meantime, it
> looks as though GFP_DMA would be the right solution as long as we have
> to stick with __get_free_pages().
>
> Alternatively, since we've already verified that the MSI writes are
> never committed to memory, we could choose some random address pointing
> to system memory as well, but I'm reluctant to do that because it could
> end up being confusing for users (and developers) to see some random
> address showing up somewhere. A physical address such as the beginning
> of system memory should always work and might be unique enough to
> indicate that it is special.
>
> Thierry
next prev parent reply other threads:[~2017-11-20 17:07 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 [this message]
2017-11-20 17:07 ` Lorenzo Pieralisi
2017-11-13 11:06 ` Lorenzo Pieralisi
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=20171120170708.GA1941@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=ryder.lee@mediatek.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.