On 14/08/17 09:27, Tian, Kevin wrote: >> * First, since the IOMMU is paravirtualized, the device can expose some >> properties of the physical topology to the guest, and let it allocate >> resources more efficiently. For example, when the virtio-iommu manages >> both physical and emulated endpoints, with different underlying IOMMUs, >> we now have a way to describe multiple page and block granularities, >> instead of forcing the guest to use the most restricted one for all >> endpoints. This will most likely be in v0.5. > > emulated IOMMU has similar requirement, e.g. available PASID bits, > address widths, etc. which may break guest usage if not aligned to > physical limitation. Suppose we can introduce a general interface > through VFIO for all vIOMMU incarnations. A nice location for this kind of info would be sysfs, as discussed in the SVM virtualization thread [1]. Properties of an IOMMU could be described in /sys/class/iommu/<dev>. Properties of a PCI device are available in its PASID/PRI capabilities. For platform devices we'll have to look at DT and ACPI properties in /sys/firmware. >> * Then on top of that, a major improvement will describe hardware >> acceleration features available to the guest. There is what I call "Page >> Table Handover" (or simply, from the host POV, "Nested"), the ability >> for the guest to manipulate its own page tables instead of sending >> MAP/UNMAP requests to the host. This, along with IO Page Fault >> reporting, will also permit SVM virtualization on different platforms. > > what's your planned cadence for future versions? :-) Hard to say, it depends on a number of things. I have various other tasks eating up my bandwidth at the moment and I may have to considerably rework this version depending on the feedback it gets. Ideally, I would like to get the base driver merged and a proposal for hardware acceleration out by the end of the year, but I obviously can't make any guarantee. Thanks, Jean [1] https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg05731.html
