Hi Baptiste, > -----Original Message----- > From: Baptiste Reynal [mailto:b.rey...@virtualopensystems.com] > Sent: Wednesday, July 15, 2015 7:08 PM > To: Will Deacon > Cc: Sethi Varun-B16395; io...@lists.linux-foundation.org; > t...@virtualopensystems.com; qemu-devel@nongnu.org > Subject: Re: [RFC 0/6] vSMMU initialization > > On Tue, Jul 14, 2015 at 1:04 PM, Will Deacon <will.dea...@arm.com> 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
