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

[Will Deacon]

Hi Joerg,

On Fri, May 29, 2015 at 03:40:43PM +0100, Joerg Roedel wrote:
> On Fri, May 29, 2015 at 12:35:56PM +0100, Robin Murphy wrote:
> > The trouble with this is, what about the CPU page size? Say you have
> > some multimedia subsystem with its own integrated SMMU and for that
> > they've only implemented the 16K granule scheme because it works
> > best for the video hardware (and the GPU driver is making direct
> > IOMMU API calls to remap carved-out RAM rather than using
> > DMA-mapping). Now, the SMMU on the compute side of the SoC serving
> > the general peripherals will be rendered useless by bumping the
> > system-wide minimum page size up to 16K, because it then can't map
> > that scatterlist of discontiguous 4K pages that the USB controller
> > needs...
> > 
> > I think this really represents another push to get away from (or at
> > least around) the page-at-a-time paradigm - if the IOMMU API itself
> > wasn't too fussed about page sizes and could let drivers handle the
> > full map/unmap requests however they see fit, I think we could
> > bypass a lot of these issues. We've already got the Intel IOMMU
> > driver doing horrible hacks with the pgsize_bitmap to cheat the
> > system, I'm sure we don't want to add any more of that. How about
> > something like the below diff as a first step?
> 
> Moving functionality out of the iommu core code into the drivers is the
> wrong direction imo. It is better to solve it with something like
> 
> 	struct iommu_domain *iommu_domain_alloc_for_group(struct iommu_group *group);
> 
> Which gets us a domain that can only be assigned to that particular
> group. Since there is a clear one-to-many relationship between a
> hardware iommu and the groups of devices behind it, we could propagate
> the pgsize_bitmap from the iommu to the group and then to the domain.
> 
> Domains allocated via iommu_domain_alloc() would get the merged
> pgsize_bitmap like I described in my previous mail.
> 
> But to make this happen we need a representation of single hardware
> iommu instances in the iommu core first.

I like this proposal. The only remaining part is that the pgsize bitmap
inherited by the domain can only truly be finalised once the page table
is allocated, which in turn can only happen once we've identified the
IOMMU instance.

In the case of iommu_domain_alloc_for_group, that's nice and
straightforward (i.e. as part of the call) but for the default
iommu_domain_alloc() case, we'd have to continue postponing things to
->attach time before we could provide a reliable pgsize_bitmap. This is
to handle the case where an SMMU may be able to support only a subset of
the pgsize_bitmap on a per-domain basis.

In which situation do you think the merged pgsize_bitmap would get used?
The only place I can think of is if we're trying to call iommu_map on a
domain with no devices attached. However, if that domain was created
using iommu_domain_alloc() then the pgsize_bitmap is the least of our
worries -- we don't even know the page table format!

Will