On Wed, Aug 04, 2021 at 11:48:00AM +0800, Jason Wang wrote: > Hi: > > We currently try to enable device IOTLB when iommu_platform is > set. This may lead unnecessary trasnsactions between qemu and vhost > when vIOMMU is not used (which is the typical case for the encrypted > VM). > > So patch tries to use transport specific method to detect the enalbing > of vIOMMU and enable the device IOTLB only if vIOMMU is enalbed.
Just to mention that there's also the ordering requirement for e.g. vfio-pci and the iommu device so far because vfio_realize() depends on vIOMMU being realized too, so specifying "-device vfio-pci" before "-device intel-iommu" will stop working, I think (see the similar pci_device_iommu_address_space() call in vfio_realize()). Do you think vhost can do the same to assume vIOMMU must be specified before vhost? Then vhost can call pci_device_iommu_address_space() freely. It'll be more gentle for vhost even when it's used wrong: instead of not working at all (vfio-pci), vhost runs slower. Currently libvirt should be able to guarantee that ordering so libvirt users shouldn't need to bother. I think libvirt should also guarantee the vIOMMU device to be created before all the rest devices, including virtio/vhost. But need to check. If that's the case libvirt will naturally work for vhost too. For the long term we may need to think about making device creation to be not ordered by user cmdline input but still has a priority specified in the code itself. Migration has something like that (MigrationPriority). I think we just need something similar for general device realizations. Since vhost raised the same need, I think that priority should bump up too. The other concern is right now vhost has vhost_dev.dma_as but now we're not using it for vhost_dev_has_iommu(). It's just a bit confusing as when to use which. What do you think? Thanks, -- Peter Xu
