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

[Marek Szyprowski]

Hi Will,

On 2014-09-02 12:57, Will Deacon wrote:
> 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.

Maybe the default dma-mapping domain should be one per a given IOMMU 
instance?
This will simplify a lot of things in such case.

> 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.

Right, those seems to be a details.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland