[PATCH 2/3] iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices

[joro@8bytes.org (Joerg Roedel)]

On Tue, Jun 02, 2015 at 10:47:46AM +0100, Will Deacon wrote:
> On Tue, Jun 02, 2015 at 08:39:56AM +0100, Joerg Roedel wrote:
> > I don't think we need to postpone anything. Domains returned by
> > iommu_domain_alloc() need to work for all groups. If there are multiple
> > IOMMUs in the system with different capabilities/page-table formats the
> > IOMMU core needs to build multiple page-tables for that domain.
> 
> I really don't think that's feasible. We support an awful lot of
> combinations that affect the page table format on ARM: there are 5
> different formats, each supporting different translation regimes (sets
> of page size) and each of those needs configuring for input/output
> address sizes to compute the number of levels. You could easily end up
> with over 20 page tables and their corresponding sets of control
> register values.

We only need to build page-tables for IOMMUs that are actually in the
system. And this also only for domains that are not tied to a particular
group. If some hardware vendor is crazy enough to put 20 IOMMUs in the
system with each having its own page-table format, then be it so. But in
reality I think we will have only a handful of different page-tables.

> Given that we only install one page table in the end, I'm struggling to
> see the issue with postponing its allocation until we've figured out
> the IOMMU instance thanks to a device attach.

It is a question of the use-case for the domain. A device driver (like
for USB or graphics) would allocate the domain with the _for_group
function and end up with only one page-table.

But if VFIO comes around and wants to attach devices to a KVM guest it
would use iommu_domain_alloc() and has then all page-tables it possibly
needs (for devices attached at start and even devices that might later
be hotplugged into the guest).


	Joerg