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

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

On Wed, Oct 05, 2011 at 07:54:21AM -0500, Anthony Liguori wrote:
> 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.

FWIW we introduce it for tpm as first step.

> Migration capabilities would be used to negotation
> ASN.1 over the wire.

I'm not yet really convinced we need capabilities at all.
Would be sad to make asn depend on that.

> That means that 1.1 would use the existing
> protocol to talk to 1.0.

We basically never had qemu that can talk
across versions 100%. The compability we carry around
is so much dead code. And no wonder: there's no way
to parse the protocol without being bug for bug compatible.

IMO let's just switch to a sane protocol first.
Being compatible with that will be much easier.

> >>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