Re: [Qemu-devel] The State of the SaveVM format

[Anthony Liguori <anthony@codemonkey.ws>]

Markus Armbruster wrote:
> Anthony Liguori <anthony@codemonkey.ws> writes:
>   
>>        VMSTATE_PCI_DEVICE(dev, PCII440FXState),
>>        VMSTATE_UINT8(smm_enabled, PCII440FXState),
>>        VMSTATE_FUNC_V(irq_state->piix3->pci_irq_levels,
>> PCII440FXState, marshal_pci_irq_levels, 2)
>>
>> This avoids bit rot of the old load functions and makes the whole
>> thing more robust.  My contention is that there simply isn't a lot of
>> these special cases so it's not a lot more work overall.
>>     
> [...]
>
> Bitrot is only an issue if we keep supporting the old formats for much
> longer.
>
> I'd like to challenge the idea that we need to drag along the old
> formats for an indefinite period of time.  Is the restriction that to
> upgrade from version N to version M, you have to go through version N+1
> really so onerous?
>   

Honestly, this is a really hard one for me.  On the one hand, migration 
compatibility is a very important feature for users.  I think we ought 
to try our best to support it.

But it's certainly not lost on me that this is going to be very 
difficult if not impossible to achieve in practice.  I'd like us to give 
it the best shot we can.  I don't like the idea of admitting defeat from 
the start and not even attempting to provide backwards compatibility.

> A couple of releases down the road, the pre-vmstate formats will be
> ancient history.

It's been shipped for RHEL5.4.  As is true for any enterprise distro, 
that means it will remain important to me for quite some time :-)

>   If we complicate vmstate now to shoehorn pre-vmstate
> formats into vmstate, that ancient history will continue to haunt us.
> Complicating a program is far easier than the other direction.
>   

Let's take it one step at a time.  There is an awful lot of areas where 
we can support older versions without adding complications.  Let's 
approach the complicated ones one at a time.

> Moreover, I'm rather wary of efforts to replace working code (the
> existing load functions) by new code that is supposed to do precisely
> the same.  It means replacing the devil I know by some untested devil I
> don't know.
>   

Understood, but what concerns me is that the old code path goes from 
being partially tested all of the time to being never tested in the 
common case.

The other big concern I have is that I would really like to eliminate 
QEMUFile as it's a rather hideous abstraction.  The advantage of 
converting old load functions to vmstate is that it makes it an awful 
lot easier to get rid of QEMUFile.

Regards,

Anthony Liguori