Re: [Qemu-devel] [PATCH 3/4] virtio: modify savevm to have a stable wire format

[Rusty Russell]

Anthony Liguori <address@hidden> writes:
> Rusty Russell <address@hidden> writes:
>
>> Anthony Liguori <address@hidden> writes:
>>> We were memcpy()'ing a structure to the wire :-/  Since savevm really
>>> only works on x86 today, lets just declare that this element is sent
>>> over the wire as a little endian value in order to fix the bitness.
>>>
>>> Unfortunately, we also send raw pointers and size_t which are going
>>> to be different values on a 32-bit vs. 64-bit QEMU so we need to also
>>> deal with that case.
>>>
>>> A lot of values that should have been previously ignored are now sent
>>> as 0 and ignored on the receive side too.
>>
>> Don't we want to transition to vmstate anyway?  Can we just do that, and
>> relegate the existing slightly broken code, to legacy?
>
> What worries me is if someone changes VirtQueueElement, then all the
> sudden migration breaks.  By transitioning to what I've sent, we at
> least have a better documented protocol that isn't prone to subtle
> breakage anymore.  Plus, we resolve the endian issue before it becomes a
> bigger problem when David actually gets live migration working reliably
> on PPC...

My transition was to copy that structure to VirtQueueSavedElement, and
it's only used for loading old versions.

With the new code we only need the head from that structure.

> I'm certainly in favor of cleaning up the savevm format and probably
> leaving the existing load/save functions as-is for legacy purposes.
> I'll leave that as an exercise for someone else though :-)

What is the rule about new versions?  Can we introduce a new save
version at any time, or only at major qemu version changes?

Thanks,
Rusty.