Re: SMMU 2-stage support

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

On Thu, Apr 16, 2015 at 04:46:59PM +0100, Stuart Yoder wrote:
> > > > So, whilst it's great that you're looking at the code, I'm not very keen on
> > > > merging anything until we have people committed to using it. Right now, the
> > > > only feedback I've had has been going in the para-virt direction and I don't
> > > > think we should do this "for fun".
> > > Freescale would be interested in using the vSMMU implementation. We have
> > > use cases for assigning devices to guest user space. Are you suggesting
> > > that you are more inclined to using the para virtualized approach?
> > 
> > I can see arguments either way; the vSMMU means that the guest can use the
> > same SMMU driver as the host but a para-virtualised approach could
> > theoretically be used across multiple SMMU implementations as well as
> > potentially being kinder on the TLB.
> 
> In the paravirt approach is the guest managing its own stage 1 
> page tables (read directly by the hardware SMMU)?

No; ideally the paravirtualised interface would abstract any details of
the hardware, including page table format. So you might have a "map" hvc
call that takes iova, (guest) phys, size, for example. Then the hypervisor
would manually collapse that into the current page tables using iommu_map.

> Is there anything written up anywhere sketching out how the paravirt
> approach would work?   Are there any limitations vs the vSMMU?

Not yet, and that's exactly the kind of research/investigation I'd like to
see happening before we commit ourselves one way or the other.

Will