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
