[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen virtual IOMMU high level design doc
> From: Stefano Stabellini [mailto:sstabellini@xxxxxxxxxx] > Sent: Thursday, November 24, 2016 3:09 AM > > On Wed, 23 Nov 2016, Edgar E. Iglesias wrote: > > On Wed, Aug 17, 2016 at 08:05:51PM +0800, Lan, Tianyu wrote: > > > Hi All: > > > The following is our Xen vIOMMU high level design for detail > > > discussion. Please have a look. Very appreciate for your comments. > > > This design doesn't cover changes when root port is moved to hypervisor. > > > We may design it later. > > > > Hi, > > > > I have a few questions. > > > > If I understand correctly, you'll be emulating an Intel IOMMU in Xen. > > So guests will essentially create intel iommu style page-tables. > > > > If we were to use this on Xen/ARM, we would likely be modelling an ARM > > SMMU as a vIOMMU. Since Xen on ARM does not use QEMU for emulation, the > > hypervisor OPs for QEMUs xen dummy IOMMU queries would not really be used. > > Do I understand this correctly? > > I think they could be called from the toolstack. This is why I was > saying in the other thread that the hypercalls should be general enough > that QEMU is not the only caller. > > For PVH and ARM guests, the toolstack should be able to setup the vIOMMU > on behalf of the guest without QEMU intervention. > > > > Has a platform agnostic PV-IOMMU been considered to support 2-stage > > translation (i.e VFIO in the guest)? Perhaps that would hurt map/unmap > > performance too much? > > That's an interesting idea. I don't know if that's feasible, but if it > is not, then we need to be able to specify the PV-IOMMU type in the > hypercalls, so that you would get Intel IOMMU on x86 and SMMU on ARM. > > Not considered yet. PV is always possible as we've done for other I/O devices. Ideally it could be designed being more efficient than full emulation of vendor specific IOMMU, but also means requirement of maintaining a new guest IOMMU driver and limitation of supporting only newer version guest OSes. It's a tradeoff... at least not compelling now (may consider when we see a real need in the future). Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |