qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Varun Sethi
Subject: Re: [Qemu-devel] [RFC 0/6] vSMMU initialization
Date: Tue, 14 Jul 2015 02:21:03 +0000

Hi Will,

> -----Original Message-----
> From: address@hidden [mailto:iommu-
> address@hidden On Behalf Of Will Deacon
> Sent: Friday, June 12, 2015 7:53 PM
> To: Baptiste Reynal
> Cc: address@hidden; address@hidden;
> address@hidden
> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]