On 05/13/2017 02:02 AM, Michael S. Tsirkin wrote:
@@ -253,6 +271,31 @@ Once the source has finished migration, rings will be
stopped by
the source. No further update must be done before rings are
restarted.
+IOMMU support
+-------------
+
+When the VIRTIO_F_IOMMU_PLATFORM feature has been negotiated, the master has
+to send IOTLB entries update & invalidation by sending VHOST_USER_IOTLB_MSG
+requests to the slave with a struct vhost_iotlb_msg payload.
Always? This seems a bit strange since iommu can be enabled/disabled
dynamically.
Ok, what about:
When the VIRTIO_F_IOMMU_PLATFORM feature has been negotiated and iommu
is enbaled, the master sends IOTLB entries update & invalidation via
VHOST_USER_IOTLB_MSG requests to the slave with a struct vhost_iotlb_msg
payload.
Closing channel seems like a wrong thing to do for this.
Sorry, I'm not sure to get your comment.
What happens when guest disables the IOMMU?
I think you mean for example when rebooting the guest with IOMMU
disabled. In this case, I think that the user backend should clean its
IOTLB cache on the next SET_FEATURE call, as the kernel backend does.
Note that I was wrong when stating:
"When the VIRTIO_F_IOMMU_PLATFORM feature has been negotiated and iommu
is enabled..."
Actually, VIRTIO_F_IOMMU_PLATFORM is negotiated if both supported by the
backend and the guest, and if an iommu device is attached. If the guest
kernel doesn't enable the IOMMU (e.g. intel_iommu=off in kernel
cmdline), the master replies to IOTLB misses with identity IOTLB
entries updates (Passthrough) (it requires recent fixes from Peter to
work[0]).
Maxime
[0]: http://patchwork.ozlabs.org/patch/763379/
