[RFC PATCH 0/7] Introduce automatic DMA configuration for IOMMU masters

Will Deacon will.deacon at arm.com
Tue Sep 2 03:57:30 PDT 2014


On Tue, Sep 02, 2014 at 11:42:13AM +0100, Marek Szyprowski wrote:
> On 2014-09-02 10:56, Arnd Bergmann wrote:
> > On Tuesday 02 September 2014 10:48:02 Marek Szyprowski wrote:
> >>>    -- I have concerns that allocating one domain per master might be
> >>> too much, but it's hard to tell without an IOMMU driver ported over.
> >> One domain per master is IMHO a sane default configuration. The only default
> >> alternative I see is to have only one domain (related with dma-mapping
> >> subsystem) and bind all devices to it. However I really don't see any
> >> disadvantage of having separate domain per each master and such
> >> configuration
> >> gives devices better separation.
> > I was expecting that the dma-mapping implementation would by default use
> > one domain for all devices, since that is what the simpler IOMMUs without
> > domain support have to do anyway.
> >
> > For isolation purposes, it can only help to have more domains, but
> > I would guess that there is some space overhead in maintaining lots
> > of page tables.
> 
> I'm okay with both approaches (separate domain for each device vs. single
> common domain for all devices). Maybe this can be some kind of Kconfig
> option added to DMA debugging? Separation might be really helpful when
> debugging strange device behavior.

One potential problem with a single domain is when you have multiple
instances of a given IOMMU, each with different hardware restrictions.
Then you can end up with multiple sets of page tables for the domain
which, although not impossible to work with, is a bit of a mess.

I think having one domain per IOMMU instance would make the most sense,
but then you have to teach more of the stack about the IOMMU topology. I
think we'll get there in the end, but that's a little way off right now.

Will



More information about the linux-arm-kernel mailing list