Re: [Qemu-devel] [QEMU PATCH v5 4/6] migration: migrate QTAILQ

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Paolo Bonzini (pbonzini@redhat.com) wrote:
> 
> 
> On 06/10/2016 13:56, Dr. David Alan Gilbert wrote:
> >> > Yes, it's sickening but that's what you do to honor backwards compatibility.
> > Actually, that's not *that* bad an idea.
> > 
> > Lets go with Jianjun's structure for the moment; we can always expand on it.
> > 
> > It seems we have ~3 concepts that feel partially independent:
> > 
> >     a) The format of the loop on the wire (eg one byte per iteration, 0 terminates)
> >     b) The way the list is represented (QTAILQ, simple array, device specific linked-list)
> >     c) The data gathered in each iteration
> >     d) The allocation of (c)
> > 
> > This patch has a,b,d all wrapped up together in the get/put functions -
> > where I was hoping to find a way to separate them a bit so that we
> > could say; I want a loop, with this format, into this data structure, using this allocator.
> 
> Yes, the sickening part is when the format of the loop intersects with
> the format of the datastructure.

Yes.

> I agree with moving the allocator out of VMStateInfo and back into
> VMStateField, but only as long as VMStateAllocator could replace other
> VMS_* flags.
> 
> I'm not sure about the value in separating (a) and (b), but we can do
> things one step at a time.

The other observation is that in many of the cases the loop body uses
some state present in the outer state or in a value read prior to the
start of the loop.
For example virtio_blk_load_device uses the vdev pointer inside
the loop during the initialisation of each loaded request (I can see
some hacky ways of avoiding it but it's messy).

> By the way, regarding this:
> 
> > The other possibility is just to bump the version and make the SCSI
> > request flag a separate byte after the "is there another entry" byte.
> 
> There is another way to do it that is much more backwards-compatible.
> Choose a "default" value of retry corresponding to what QEMU encodes as
> a "1".  If it's different, use a subsection to encode that.  Migration
> from old to new will fail if the wrong value of retry is used, because
> it will see a 2 where the QTAILQ loop expects a zero or one.  Migration
> from new to old will fail if the wrong value of retry is used, because
> it will see a subsection header where the QTAILQ loop expects a zero or one.
> 
> I think this is acceptable, and it would only affect migration of USB
> storage devices.

Yes, it might be worth it in some of these cases; although I do try
and avoid breaking format at almost all costs.

Dave

> Paolo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK