From: Christoph Hellwig <hch@lst.de>
To: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Christoph Hellwig <hch@lst.de>,
Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: ehci-pci breakage with dma-mapping changes in 5.4-rc2
Date: Wed, 9 Oct 2019 08:50:43 +0200 [thread overview]
Message-ID: <20191009065043.GA30157@lst.de> (raw)
In-Reply-To: <20191008154731.GA616259@rani.riverdale.lan>
On Tue, Oct 08, 2019 at 11:47:31AM -0400, Arvind Sankar wrote:
> Ok, I see that almost nothing actually uses dma_get_required_mask. So if
> something did need >4Gb space, the IOMMU would allocate it anyway
> regardless of dma_get_required_mask.
Yes. And with the direct mapping it also isn't an issue.
> I'm thinking this means that we actually only needed to change
> dma_get_required_mask to dma_direct_get_required_mask in
> iommu_need_mapping, and the rest of the change is unnecessary?
>
> Below is list of stuff calling dma_get_required_mask currently:
I guess that would actually work ok, but I prefer the more verbose
version as it explain what is going on, and will lead people to do
the right thing if we split the iommu vs passthrough case into
different ops (we already had a patch for that out on the list).
> For the drivers that do currently use dma_get_required_mask, I believe
> we will need to replace most of them with dma_direct_get_required_mask
> as well to maintain passthrough functionality -- the fusion, scsi, and
> infinband drivers all seem to be using this call to determine whether to
> expose the device's 64-bit DMA capability or not. With the change they
> will think they only need 32-bit DMA, which in turn will disable
> passthrough on them.
At least for some of the legacy SCSI drivers that is intentional, and
the reason why dma_get_required_mask was originally added. On actual
PCI (and PCI-X, but not PCIe which everyone uses now) the 64-bit
addressing even if supported is not very efficient as it needs two
bus cycles. So we prefer to just use the iommu.
> The etnaviv driver is doing something funky that I'm not sure about, but
> I *think* that one might want the real physical range as well. The mmc
> driver I think might be ok with the 32-bit range.
etnaviv is never used on systems with the intel iommu anyway.
> The vmd controller one not sure about.
That just passes through the dma ops to work around really stupid
intel chipsets.
> In dma-mapping.h, the function is used in dma_addressing_limited, which
> in turn is used in a couple of amd drm drivers, again not sure about
> these.
---end quoted text---
next prev parent reply other threads:[~2019-10-09 6:50 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-07 2:24 ehci-pci breakage with dma-mapping changes in 5.4-rc2 Arvind Sankar
2019-10-07 7:34 ` Christoph Hellwig
2019-10-07 17:54 ` Arvind Sankar
2019-10-07 17:55 ` Christoph Hellwig
2019-10-07 17:56 ` Christoph Hellwig
2019-10-07 17:58 ` Arvind Sankar
2019-10-07 18:32 ` Arvind Sankar
2019-10-07 18:47 ` Christoph Hellwig
2019-10-07 22:10 ` Arvind Sankar
2019-10-07 23:54 ` Arvind Sankar
2019-10-08 7:32 ` Christoph Hellwig
2019-10-08 11:51 ` Arvind Sankar
2019-10-08 12:50 ` Christoph Hellwig
2019-10-08 15:47 ` Arvind Sankar
2019-10-09 6:50 ` Christoph Hellwig [this message]
2019-10-09 13:48 ` Arvind Sankar
2019-10-08 7:29 ` Christoph Hellwig
2019-10-08 14:33 ` [PATCH] iommu/vt-d: Return the correct dma mask when we are bypassing the IOMMU Arvind Sankar
2019-10-09 2:45 ` Lu Baolu
2019-10-09 6:51 ` Christoph Hellwig
2019-10-10 1:24 ` Lu Baolu
2019-10-10 1:26 ` Lu Baolu
2019-10-16 19:15 ` Arvind Sankar
2019-10-17 7:08 ` Christoph Hellwig
2019-10-17 15:55 ` Arvind Sankar
2019-10-17 15:55 ` Arvind Sankar
2019-10-18 9:50 ` Joerg Roedel
2019-10-18 15:14 ` Christoph Hellwig
2019-10-18 15:21 ` Joerg Roedel
2019-10-18 15:22 ` Christoph Hellwig
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=20191009065043.GA30157@lst.de \
--to=hch@lst.de \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nivedita@alum.mit.edu \
/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.