Re: [Qemu-devel] [PATCH 0/3] Migrate with destination version

[Dr. David Alan Gilbert]

* Paolo Bonzini (address@hidden) wrote:
> Il 28/05/2014 13:20, Dr. David Alan Gilbert (git) ha scritto:
> >From: "Dr. David Alan Gilbert" <address@hidden>
> >
> >This patch set provides an optional parameter to 'migrate' giving
> >the destination QEMU version, it's intended for those having to maintain
> >compatibility between minor versions (including downstream versions) and
> >also for those who need to think about backwards migration.
> >
> >There aren't any uses of the migration version in this patch set, however
> >uses I can think of include:
> >    a) Generating an old format for a particular device when sent to a
> >       particular version
> >    b) Fudging a register value for a particular version
> >    c) Fudging around more general problems (e.g. the 1.6.x short PCI naming)
> 
> http://lists.gnu.org/archive/html/qemu-stable/2013-10/msg00019.html

Yep, I'm aware of that one, it only solves some of the directions.

> >If we had a way for the 'save' side of migrate to fail cleanly with an error
> >then we could also do some pre-migrate checks and flag things that just 
> >aren't
> >going to work (e.g. noticing that a new feature is enabled on a device that
> >the old one doesn't have).
> 
> I don't think this is necessary; not yet at least.
> 
> In quite a few years of experience with backwards migration between RHEL6
> releases, we never found a deal breaker.  We only found one for 1.5->0.12
> migration, and what broke the deal was not QEMU changes but firmware
> incompatibility (RHEL7 SeaBIOS not working on RHEL6).

Yep, most things seem to be fudgable; however I'd point out the 
'not yet at least' in your response; the intention of this patch is to
already have the information/infrastructure in place so that if we do
find a nasty case then it's easier to fix.    I wouldn't want to find myself
with one of those hard to fix problems and then have to retrofit this type of
thing.

It's also more likely in the case where people want to backward migrate
across larger version gaps.

> Of the above three cases, (a) and (b) can be handled by machine types.

I don't see how this is generally the case without having to boot the source
QEMU with a machine type dependent on which destination you're going to go to,
that you don't yet know.

> (c) should have been caught by testing, and is not entirely solved by this
> approach.  It would fix 2.0->1.6 migration, but not 1.6->2.0 migration with
> -M pc-1.5.  In other words, it would not fix the case that we care about in
> upstream.

I think 1.6->2.0 -M pc-1.5 is fixable by the appropriate flag being passed to
the 2.0 at startup to tell it to use/not-use the short-bus; not pretty though.

Defining what case 'we care about in upstream' is just looking at history;
Note this patch series doesn't include a pile of workarounds to fixup
some particular downstream cross-version migration - it's just providing the
infrastructure which anyone might want to use, and it seems right to have
the infrastructure available to all upstream.

> Version numbers open a huge compatibility can of worms (what is a version
> number?)

No, a version number here is very well defined; it's the output of 
'query-version'
(or 'info version' for the HMP world).
How you do comparisons on that, and in particular how you parse the 'package'
text is a different matter, however I suggest that parsing the 'package'
text is downstream's problem and they provide that text.

> and don't solve the fundamental problem of migration receiving
> insufficient testing with upstream QEMU versions.

Indeed; and it's not meant to - in no way is this an excuse for inadequate
testing - however, we're all human, and bugs happen, this is just providing
a way to get out of some of the mess afterwards.

Dave
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK