Re: [Qemu-devel] [PATCH 6/6] spec/vhost-user spec: Add IOMMU support

[Maxime Coquelin]

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/