Re: [Qemu-devel] [PATCHv2] virtio: verify that all outstanding buffers are flushed

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Dec 12, 2012 at 05:51:51PM +0100, Paolo Bonzini wrote:
> Il 12/12/2012 17:37, Michael S. Tsirkin ha scritto:
> > > You wrote "the only way to know head 1 is outstanding is because backend
> > > has stored this info somewhere".  But the backend _is_ tracking it (by
> > > serializing and then restoring the VirtQueueElement) and no leak happens
> > > because virtqueue_fill/flush will put the head on the used ring sooner
> > > or later.
> > 
> > If you did this before save vm inuse would be 0.
> 
> No, I won't.  I want a simple API that the device can call to keep inuse
> up-to-date.  Perhaps a bit ugly compared to just saving inuse, but it
> works.  Or are there other bits that need resyncing besides inuse?  Bits
> that cannot be recovered from the existing migration data?

Saving inuse counter is useless. We need to know which requests
are outstanding if we want to retry them on remote.

> > You said that at the point where we save state,
> > some entries are outstanding. It is too late to
> > put head at that point.
> 
> I don't want to put head on the source.  I want to put it on the
> destination, when the request is completed.  Same as it is done now,
> with bugfixes of course.  Are there any problems doing so, except that
> inuse will not be up-to-date (easily fixed)?

You have an outstanding request that is behind last avail index.
You do not want to complete it. You migrate. There is no
way for remote to understand that the request is outstanding.

> > > It's not common, but you cannot block migration because you have an I/O
> > > error.  Solving the error may involve migrating the guests away from
> > > that host.
> > 
> > No, you should complete with error.
> 
> Knowing that the request will fail, the admin will not be able to do
> migration, even if that will solve the error transparently.
> 
> Paolo

You are saying there's no way to complete all requests?

-- 
MST