Re: [Qemu-devel] [RFC 0/6] vSMMU initialization

[Varun Sethi]

Hi Baptiste,

> -----Original Message-----
> From: Baptiste Reynal [mailto:address@hidden
> Sent: Wednesday, July 15, 2015 7:08 PM
> To: Will Deacon
> Cc: Sethi Varun-B16395; address@hidden;
> address@hidden; address@hidden
> Subject: Re: [RFC 0/6] vSMMU initialization
> 
> On Tue, Jul 14, 2015 at 1:04 PM, Will Deacon <address@hidden> wrote:
> > On Tue, Jul 14, 2015 at 03:21:03AM +0100, Varun Sethi wrote:
> >> Hi Will,
> >
> > Hi Varun,
> >
> >> > On Fri, Jun 12, 2015 at 03:20:04PM +0100, Baptiste Reynal wrote:
> >> > > The ARM SMMU has support for 2-stages address translations,
> >> > > allowing a virtual address to be translated at two levels:
> >> > > - Stage 1 translates a virtual address (VA) into an intermediate
> >> > > physical address (IPA)
> >> > > - Stage 2 translates an IPA into a physical address (PA)
> >> > >
> >> > > Will Deacon introduced a virtual SMMU interface for KVM, which
> >> > > gives a virtual machine the possibility to use an IOMMU with native
> drivers.
> >> > > While the VM will program the first stage of translation (stage
> >> > > 1), the interface will program the second (stage 2) on the physical
> SMMU.
> >> >
> >> > Please note that I have no plans to merge the kernel-side of this
> >> > at the moment. It was merely an exploratory tool to see what a
> >> > non-PV vSMMU implementation might look like and certainly not
> >> > intended to be used in anger.
> >> How do you see the context fault reporting work for the PV interface?
> >
> > We could have an interrupt, for the PV IOMMU and have the hypervisor
> > inject that, no?
> >
> >> Currently the vSMMU interface does seem quiet restrictive and it may
> >> simplify things by having PV iommu interface. But, do you see this
> >> even true in case of SMMUv3?
> 
> Varun, may I know what do you mean by "more restrictive" ? Do you have in
> mind any use case which should apply to the PV interface and not the
> vSMMU ?
> 
[varun] What I meant was that vSMMU allows for setting up of the stage 1 
translation, but doesn't specifically allow access to other SMMU hardware 
functionality. We can certainly extend the vSMMU interface for providing 
additional functionality to the guest VM. I do agree with Will, that for 
extending the vSMMU interface prototyping is necessary. We need to come up with 
specific use cases for that.
For controlling stage 1 translation PV interface may be a bit simpler, but then 
we would need a generic interface to bind to most IOMMUs in the host.

-Varun