On 13/04/17 09:16, Tian, Kevin wrote: >> From: Jason Wang >> Sent: Wednesday, April 12, 2017 5:07 PM >> >> On 2017年04月08日 03:17, Jean-Philippe Brucker wrote: >>> This is the initial proposal for a paravirtualized IOMMU device using >>> virtio transport. It contains a description of the device, a Linux driver, >>> and a toy implementation in kvmtool. With this prototype, you can >>> translate DMA to guest memory from emulated (virtio), or passed-through >>> (VFIO) devices. >>> >>> In its simplest form, implemented here, the device handles map/unmap >>> requests from the guest. Future extensions proposed in "RFC 3/3" should >>> allow to bind page tables to devices. >>> >>> There are a number of advantages in a paravirtualized IOMMU over a full >>> emulation. It is portable and could be reused on different architectures. >>> It is easier to implement than a full emulation, with less state tracking. >>> It might be more efficient in some cases, with less context switches to >>> the host and the possibility of in-kernel emulation. >> >> I like the idea. Consider the complexity of IOMMU hardware. I believe we >> don't want to have and fight for bugs of three or more different IOMMU >> implementations in either userspace or kernel. >> > > Though there are definitely positive things around pvIOMMU approach, > it also has some limitations: > > - Existing IOMMU implementations have been in old distros for quite some > time, while pvIOMMU driver will only land in future distros. Doing pvIOMMU > only means we completely drop support of old distros in VM; > > - Similar situation on supporting other guest OSes e.g. Windows. IOMMU is > a key kernel component which I'm not sure pvIOMMU through virtio can be > recognized in those OSes (not like a virtio device driver); I can't talk about other OSes, but on Linux virtio-iommu is implemented the same way as other IOMMU drivers and doesn't require core modifications. > I would image both full-emulated IOMMUs and pvIOMMU would co-exist > for some time due to above reasons. Someday when pvIOMMU is mature/ > spread enough in the eco-system (and feature-wise comparable to full-emulated > IOMMUs for all vendors), then we may make a call. Agreed. The main inconvenient of any paravirtualized device is that they need additional support in the guest. It is not our intention to disrupt all the work done on IOMMU virtualization for x86 and other architectures. Even for ARM, people might want to provide SMMU emulations to unmodified guests, implemented in userspace. What we intend to avoid, as detailed in my other reply, is in-kernel emulation of all possible ARM-based IOMMU variations for Linux. So we propose a generic alternative from the start, that others can reuse later. Thanks, Jean-Philippe
