Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format

[Juan Quintela]

Anthony Liguori <address@hidden> wrote:
> On 07/26/2011 07:07 AM, Juan Quintela wrote:

>> I will change this to:
>> - We need to be able to "enable/disable" features of a device.
>>    A.K.A. make -M pc-0.14 work with devices with the same features
>>    than 0.14.  Notice that this is _independent_ of migration.
>
> In theory, we already have this with qdev flags.

theory.  we are not there at all :-(  but anyways, that is not
_migration_, it is qdev.


>> - Be able to describe that different features/versions.  This is not the
>>    difficult part, it can be subsections, optional fields, whatever.
>>    What is the difficult part is _knowing_ what fields needs to be on
>>    each version.  That again depends of the device, not migration.
>>
>> - Be able to to do forward/bacward compatibility (and without
>>    comunication both sides is basically impossible).
>
> Hrm, I'm not sure I agree with these conclusions.
>
> Management tools should do their best job to create two compatible
> device models.

How?  only part that can have enough information is the "new" part
(either source of destination).  And we are being very careful about not
allowing any comunication/setting of what is in the other side.

> Given two compatible device models, there *may* be differences in the
> structure of the device models since we evolve things over time.  We
> may rename a field, change the type, etc.  To support this, we can use
> filters both on the destination and receive end to do our best to
> massage the device model into something compatible.
>
> But creating two creating compatible device models is not the job of
> the migration protocol.  It's the job of management tools.

Agreed here.

>> - Send things on the wire (really this is the easy part, we can play
>>    with it touching only migration functions.).
>>
>>> We also need a way to future proof ourselves.
>>
>> We have been very bad at this.  Automatic checking is the only way that
>> I can think of.
>
> I don't know what you mean by automatic checking.

We should have unit test to see that (at least) the obvious migration work.

>> We have two things here.  Device level&  protocol level.
>>
>> Device level: very late to set anything.
>> Protocol level: we can set things here, but notice that only a few
>> things cane be set here.
>
> Once we have a protocol level feature bit, we can add device level
> feature bits as a new feature.

This don't help  migration time is very late to configure a device.  We
need to configure it at creation time.  It makes no sense to try to
migrate device foo with 4 bar's and at migration time try to "push" it
into only 2 bars.  Having it created with 2 bars in the 1st place is the
only sane solution.

>>> It's 100% mechanical and makes absolutely no logic change.  It works
>>> equally well with legacy and VMstate migration handlers.
>>>
>>> 3) Add a Visitor class that operates on QEMUFile.
>>>
>>> At this state, we can migrate to data structures.  That means we can
>>> migrate to QEMUFile, QObjects, or JSON.  We could change the protocol
>>> at this stage to something that was still binary but had section sizes
>>> and things of that nature.
>>
>> That was the whole point of vmstate.
>
> The problem with vmstate is that it's an all or nothing thing and the
> conversion isn't programmatic.

This is the whole point.  We are being declarative, and we create a
mecanism about how to visit all nodes.  What we do in each node is not
VMState business.  VMState only defines the nodes, and which ones belong
to each version.

> Since visiting and qemu_put match 1-1,
> we can do the conversion all-at-once with some sed magic.
>
>>> So if we did this in 1.0, we could have a single function that
>>> converted the 1.0 device model to 1.1 and vice versa, and we'd be
>>> fine.  We wouldn't have to touch 200 devices to do this.
>>
>> I still think this is wrong.  We are launching a device with feature
>> "foo", and at migration time, we want to migration without feature
>> "foo".  This is not going to work on the general case.  But launching
>> the device _without_ feature "foo" will always work.
>
> Don't confuse migration with creating compatible device models.  We're
> never going to support migrating from a system with an e1000 to a
> system with virtio :-)

I am not confusing it.

from virtio_serial_bus.c, you can see that what we sent on version 2 vs
version 3 is much, much more information.  Migrating from v3 to v2 is
imposible, we need to start the device with the features that it had on
v2.  Notice that this is not related to vmstate, is related to _how_ the
device works/features are implemented.


>> Notice the things that "can" be optional:
>> - features that are not used.  We update the device to have more
>>    features, but OS driver only uses the features of the old version.
>>    With subsections test, we can fix this one.
>>
>> - values that are only needed sometimes.  PIO subsection cames to mind,
>>    it is only needed when we are on the middle of a PIO operation.
>>
>> - values that rarely change for defaults.  This the mmio addresess
>>    problems with rtl8139.  If we plug/unplug the card, we will get a
>>    different address, so we need to change it.
>>
>> - values that depend of other features (change default size of memory,
>>    add new variables, etc).  This is for its very nature not compatible,
>>    and we can't migrate.
>>
>> What I am complaining here?  This "compatibility" support supposes that
>> migration works as:
>>
>> device with some features ->  migration ->  device with other features
>>
>> and it works.  This means that "migration" does magic, and this is never
>> going to work.
>>
>> Until now, this kind of worked because we only supported migration from
>> old ->  new, or the same version.  Migration from old ->  new can never
>> have new features.  But from new ->  old to work, we need a way to
>> disable the new features.   That is completely independent of migration.
>
> At startup time, not dynamically.  And we have this, that's what -M
> pc-X 
> is about.

It don't work.  Almost nothing have enough state to describe it.  See my
example, how to start virtio-serial-bus with something that is
compatible with v2 of the protocol?  Device don't know how to do that.

>>> 5) Once we're here, we can implement the next 5-year format.  That
>>> could be ASN.1 and be bidirectional or whatever makes the most sense.
>>> We could support 50 formats if we wanted to.  As long as the transport
>>> is distinct from the serialization and compat routines, it really
>>> doesn't matter.
>>
>> This means finishing the VMState support, once there, only thing needs
>> to change is "copy" the savevm, and change the "visitors" to whatever
>> else that we need/want.
>
> There's no need to "finish" VMState to convert to visitors.  It's just
> sed -e 's:qemu_put_be32:visit_type_int32:g'

I don't agree.  That is just cosmetic and we are not fixing any problem.

Later, Juan.