> 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 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. Thanks, Kevin
