Re: [PATCH 7/9] documentation: iommu: add description of ARM System MMU binding

[Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>]

Hi Joerg,

On Thu, Jun 20, 2013 at 09:08:45PM +0100, Joerg Roedel wrote:
> On Mon, Jun 10, 2013 at 07:34:43PM +0100, Will Deacon wrote:
> > This patch adds a description of the device tree binding for the ARM
> > System MMU architecture.
> 
> Interesting, will this be a common driver to replace existing ARM IOMMU
> drivers or is it a common driver for ARM IOMMUs found in future chips?

This is a common driver that will support any IOMMUs compatible with v1 or
v2 of the ARM SMMU architecture. Currently, that includes SMMUs known
informatively as MMU-400, MMU-401 and MMU-500. I had a look at the other
IOMMU drivers in the kernel and they seem to be driving incompatible IOMMUs,
so I don't see how this driver can replace those.

However, we'll hopefully see ARM SMMU-compatible devices turning up soon (I
know of many SoCs in development that are looking at them).

> > +- smmu-parent   : When multiple SMMUs are chained together, this
> > +                  property can be used to provide a phandle to the
> > +                  parent SMMU (that is the next SMMU on the path going
> > +                  from the mmu-masters towards memory) node for this
> > +                  SMMU.
> 
> What happens when SMMUs are chained? Will the second SMMU seeing the DMA
> just pass it through or is it translated again?

Chaining is really horrible and exists as a hack to support virtualisation
using two separate SMMUs, where neither of them can support nested
translation.

The current driver just programs the translation in the SMMU nearest the
device, then sets the other SMMU into `bypass' mode (it was simple enough to
generalise the chain to contain an arbitrary number of SMMUs, so the driver
can actually deal with any number of the things). In theory (and if we
extended the IOMMU API to distinguish between guest and host mappings --
something which I plan to look at in the future), KVM could install mappings
in the second SMMU, but I think we should draw a line in the sand and mandate
support for nested translation for KVM.

The only thing to take care of is that the SMMUs in the chain don't silently
truncate addresses.

Will