Re: [RFC 2/2] spec/vhost-user spec: Add IOMMU support

[Jason Wang <jasowang@redhat.com>]

On 2017年04月12日 17:26, Peter Xu wrote:
> On Wed, Apr 12, 2017 at 04:54:25PM +0800, Jason Wang wrote:
> > On 2017年04月12日 15:17, Peter Xu wrote:
> > > On Tue, Apr 11, 2017 at 05:16:19PM +0200, Maxime Coquelin wrote:
> > > > On 04/11/2017 03:20 PM, Peter Xu wrote:
> > > > > On Tue, Apr 11, 2017 at 12:10:02PM +0200, Maxime Coquelin wrote:
> > > [...]
> > >
> > > > > > +slave is expected to reply with a zero payload, non-zero otherwise.
> > > > > Is this ack mechanism really necessary? If not, not sure it'll be nice
> > > > > to keep vhost-user/vhost-kernel aligned on this behavior. At least
> > > > > that'll simplify vhost-user implementation on QEMU side (iiuc even
> > > > > without introducing new functions for update/invalidate operations).
> > > > I think this is necessary, and it won't complexify the vhost-user
> > > > implementation on QEMU side, since already widely used (see reply-ack
> > > > feature).
> > > Could you provide file/function/link pointer to the "reply-ack"
> > > feature? I failed to find it myself.
> > >
> > > > This reply-ack mechanism is used to obtain a behaviour closer to kernel
> > > > backend. Indeed, when QEMU sends a vhost_msg to the kernel backend, it
> > > > is blocked in the write() while the message is being processed in the
> > > > Kernel. With user backend, QEMU is unblocked from the write() when the
> > > > backend has read the message, before it is being processed.
> > > I see. Then I agree with you that we may need a synchronized way to do
> > > it. One thing I think of is IOMMU page invalidation - it should be a
> > > sync operation to make sure that all the related caches were destroyed
> > > when the invalidation command returns in QEMU vIOMMU emulation path.
> > Looks not, if I understand correctly, e.g for Intel IOMMU, when QI is
> > enabled, this could be done asynchronously by not waiting for the completion
> > through wait descriptor. Vhost-kernel always implement the invalidation as a
> > synchronous one for simplicity, but looks like this is not needed.
> IMHO, the point is guest cannot reuse that IOVA only if it sends a
> invalidation wait descriptor. If without wait descriptor, the guest
> should never release any IOVA range, if so, that'll be dangerous,
> because the cache may still be dirty on that range on specific device.
>
> And since guest will for sure use wait descriptor (as long as it wants
> to reuse iova addresses), then we should possibly finally need a way
> to synchronously invalidate IOTLB, including to vhost-user backends.

Yes, what I mean is technically we can implement this only for wait 
descriptor.

Thanks