Hi Will, > -----Original Message----- > From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- > boun...@lists.linux-foundation.org] On Behalf Of Will Deacon > Sent: Friday, June 12, 2015 7:53 PM > To: Baptiste Reynal > Cc: io...@lists.linux-foundation.org; t...@virtualopensystems.com; > qemu-devel@nongnu.org > Subject: Re: [RFC 0/6] vSMMU initialization > > 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? 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? Just wondering if we can give more control with respect memory transaction attributes to the guest. Also, would it make sense to give guest control of the fault handling attributes i.e. fault/terminate model.
-Varun
