|
From: | Maxime Coquelin |
Subject: | Re: [Qemu-devel] [PATCH 6/6] spec/vhost-user spec: Add IOMMU support |
Date: | Wed, 17 May 2017 17:27:53 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 |
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/
[Prev in Thread] | Current Thread | [Next in Thread] |