RE: SMMU 2-stage support

[Stuart Yoder <stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org>]

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon-5wv7dgnIgG8@public.gmane.org]
> Sent: Wednesday, April 15, 2015 11:18 AM
> To: Sethi Varun-B16395
> Cc: Baptiste Reynal; Linux IOMMU; Yoder Stuart-B08248
> Subject: Re: SMMU 2-stage support
> 
> On Tue, Apr 14, 2015 at 02:32:26PM +0100, Varun Sethi wrote:
> > Hi Will,
> 
> Hey Varun,
> 
> > > -----Original Message-----
> > > From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
> > > bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Will Deacon
> > > Sent: Monday, April 13, 2015 4:11 PM
> > > To: Baptiste Reynal
> > > Cc: Linux IOMMU
> > > Subject: Re: SMMU 2-stage support
> > >
> > > On Fri, Apr 03, 2015 at 10:55:02AM +0100, Baptiste Reynal wrote:
> > > > We are eventually working on the vSMMU implementation. Relying on the
> > > > talk Will Deacon gave at the Linux Plumbers IOMMU Microconference on
> > > > October
> > > > 2014 (http://linuxplumbersconf.org/2014/ocw/proposals/2019), I tried
> > > > the vSMMU initialization.
> > >
> > > My position on the vSMMU still hasn't changed:
> > >
> > > > > Anyway, until somebody actually wants this feature I've put it on
> > > > > ice as it adds a whole bunch of complication to the ARM SMMU driver,
> > > > > as well as new user ABI extensions that I don't really want to maintain for
> > > fun.
> > >
> > > 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)?

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

Thanks,
Stuart