vhost: Unbreak SMMU and virtio-iommu on dev-iotlb support
commit958ec334bca3fa9862289e4cfe31bf1019e55816
authorPeter Xu <peterx@redhat.com>
Thu, 4 Feb 2021 19:12:28 +0000 (4 14:12 -0500)
committerMichael S. Tsirkin <mst@redhat.com>
Fri, 5 Feb 2021 13:52:58 +0000 (5 08:52 -0500)
treee6cfa5eaff59f8b43d65d7011591e5eb0e8dc359
parent73b123073d5e74f948eac9a2492e0b367006cd87
vhost: Unbreak SMMU and virtio-iommu on dev-iotlb support

Previous work on dev-iotlb message broke vhost on either SMMU or virtio-iommu
since dev-iotlb (or PCIe ATS) is not yet supported for those archs.

An initial idea is that we can let IOMMU to export this information to vhost so
that vhost would know whether the vIOMMU would support dev-iotlb, then vhost
can conditionally register to dev-iotlb or the old iotlb way.  We can work
based on some previous patch to introduce PCIIOMMUOps as Yi Liu proposed [1].

However it's not as easy as I thought since vhost_iommu_region_add() does not
have a PCIDevice context at all since it's completely a backend.  It seems
non-trivial to pass over a PCI device to the backend during init.  E.g. when
the IOMMU notifier registered hdev->vdev is still NULL.

To make the fix smaller and easier, this patch goes the other way to leverage
the flag_changed() hook of vIOMMUs so that SMMU and virtio-iommu can trap the
dev-iotlb registration and fail it.  Then vhost could try the fallback solution
as using UNMAP invalidation for it's translations.

[1] https://lore.kernel.org/qemu-devel/1599735398-6829-4-git-send-email-yi.l.liu@intel.com/

Reported-by: Eric Auger <eric.auger@redhat.com>
Fixes: b68ba1ca57677acf870d5ab10579e6105c1f5338
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20210204191228.187550-1-peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
hw/arm/smmuv3.c
hw/virtio/vhost.c
hw/virtio/virtio-iommu.c