2015-06-05 14:22:13

by Will Deacon

[permalink] [raw]
Subject: Re: [PATCH 00/22 v2] Introduce default domains for iommu groups

Hi Joerg,

On Thu, May 28, 2015 at 05:41:23PM +0100, Joerg Roedel wrote:
> here is the second version of my patch-set to introduce
> default domains into the iommu core. This time it has a lot
> more patches, mostly because I added a proof of concept
> implementation by converting the AMD IOMMU driver to make
> use of it.

Most of this looks fine to me, modulo by comments about the dm regions
(which I'm not sure how to implement for ARM).

> Converting the first driver to the new concept triggered a
> lot of changes and extensions in the patch-set to fit all
> the needs of a more complex iommu driver. Converting other
> drivers might need further changes, but that is something
> for the future.
>
> A major change is that now the default domain has to be
> allocated by the code that allocates the iommu group. For
> PCI devices this happens in the IOMMU core, but drivers
> allocating the group on their own can now implement a policy
> that fits their needs (e.g. not allocate one domain per
> group but let multiple groups share one domain).

Makes sense. I really think we should be moving group allocation out of
the IOMMU drivers and into the bus code, like we already have for PCI.
Once we've got a way to describe groups of platform devices (e.g. in the
device-tree), then we can have the group creation happen automatically
as part of Laurent's of_iommu work.

Will


2015-06-05 14:35:34

by Jörg Rödel

[permalink] [raw]
Subject: Re: [PATCH 00/22 v2] Introduce default domains for iommu groups

Hi Will,

Thanks for having a look!

On Fri, Jun 05, 2015 at 03:22:06PM +0100, Will Deacon wrote:
>
> Most of this looks fine to me, modulo by comments about the dm regions
> (which I'm not sure how to implement for ARM).

When there are no direct mapping requirements from the firmware on ARM,
you can just return an empty list in these call-backs.

> > A major change is that now the default domain has to be
> > allocated by the code that allocates the iommu group. For
> > PCI devices this happens in the IOMMU core, but drivers
> > allocating the group on their own can now implement a policy
> > that fits their needs (e.g. not allocate one domain per
> > group but let multiple groups share one domain).
>
> Makes sense. I really think we should be moving group allocation out of
> the IOMMU drivers and into the bus code, like we already have for PCI.
> Once we've got a way to describe groups of platform devices (e.g. in the
> device-tree), then we can have the group creation happen automatically
> as part of Laurent's of_iommu work.

Yes, that makes sense. And PCI is pretty hardcoded into the iommu-groups
implementation right now. This needs probably be more generic too.


Joerg