Thread (25 messages) flat view 25 messages, 5 authors, 2017-02-03
STALE3476d

Revision v1 of 2 in this series.

Revisions (2)
  1. v1 current
  2. v1 [diff vs current]

[PATCH 0/5] Implement SMMU passthrough using the default domain

From: Rob Clark <hidden>
Date: 2017-02-02 15:02:50
Also in: linux-iommu

On Thu, Jan 26, 2017 at 12:18 PM, Joerg Roedel [off-list ref] wrote:
On Tue, Jan 24, 2017 at 08:42:23PM +0530, Sricharan wrote:
quoted
Thanks for this series. We had a case with the GPU.
The GPU's iommu was setup by kernel and the GPU
also does dynamic updates for on-the-fly switching between
process pagetables.  GPU driver was not using DMA domain and
the GPU's firmware was always expecting to run out  of contextbank
 '0' (although not correct) , which was not the case after the DMA domain
was made default  as '0' was getting allocated for DMA domain and
there were concerns about reusing the DMA domain as well.
Now with this series, looks there is an way out of that that can be tried.

So should the default domain not be per device specific selectable ?
Note that iommu-drivers can request direct-mapping for any given device
on its initializtion. This is used on x86 for devices that need a 1-1
mapping for some reason.

Also device drivers can use the iommu-api and assign their own domain to
a device, which allows them to manage the dma address space on their
own.
Part of the problem is that dev->archdata.dma_ops gets wired up to
iommu_dma_ops.  Which isn't so bad on it's own, except that cache ops
are not exposed to drivers, forcing us to use dma-mapping API
(dma_map_sg, etc) for cache operations.

Possibly we should just expose cache op's to drivers bypass this abuse
of dma-mapping.

btw, Will, we definitely want this to *not* rely on kcmdline for the
gpu with it's own private iommu case..

BR,
-R
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help