Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface

[Anthony Liguori]

On 10/04/2011 09:05 PM, Stefan Berger wrote:
> On 10/03/2011 09:43 AM, Anthony Liguori wrote:
> > On 10/03/2011 08:24 AM, Michael S. Tsirkin wrote:
> > > On Mon, Oct 03, 2011 at 07:51:00AM -0500, Anthony Liguori wrote:
> > > > > Here are some suggestions:
> > > > >
> > > > > - Let's make the protocol be BER directly.
> > > > > As a first step, use a single octet string for
> > > > > the whole of data. Next, start splitting this up.
> > > >
> > > > This can't be done without breaking the old style migration
> > > > protocol. I don't have a problem with that but I do have a problem
> > > > with repeatedly breaking migration protocol.
> > >
> > > As long as this is within a release cycle, is this a real problem?
> >
> > I think if we try to fit it within a release we'll either end up with a 2 year
> > long release or a half-broken conversion.
> >
> > I'd rather buy ourselves time by supporting both formats. That way we can
> > remove the old format when we're satisfied with the ASN.1 encoding.
> Hm, if backwards compatibility is what we want to achieve (migrating from Qemu
> 1.1 to Qemu 1.0) then at least the ASN.1 decoder / encoder should be all done in
> 1.0, no? Otherwise what would it mean to if 1.0 just skipped types 1.1 sends and
> doesn't understand?

Before we introduce ASN1, we ought to introduce migration capabilities. 
Migration capabilities would be used to negotation ASN.1 over the wire.  That 
means that 1.1 would use the existing protocol to talk to 1.0.

> > There are multiple things to consider with compatibility:
> >
> > 1) Creating compatible device models. This is a qdev problem and can't be
> > solved in the protocol.
> >
> > 2) Ensuring we are sending all the data we need to. I think we solve this
> > problem by autogenerating Visitors from the C definitions of the device
> > structures.
> I would have thought that we would write a function that takes the
> VMStateDescription as an argument and write ASN.1 BER or CER comprising:
> - a header containing the version of the device data
> - the minimum version required to read the device data
> - walk the array of VMStateFields and encode the the device data

Sort of.  You modify VMStateInfo to accept a visitor and name parameter in load 
and put.  Then you write an ASN.1 BER Visitor and pass that visitor to 
VMStateInfo->load/put.

Regards,

Anthony Liguori

> and similarly a function for walking the fields for decoding of each device 
> state.
>
> So at least I am surprised to hear 'autogeneration' for this particular case...
>
> Stefan