qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] migration: remove subsections in fdc and rtl813


From: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH] migration: remove subsections in fdc and rtl8139 and bump versions
Date: Wed, 03 Aug 2011 11:00:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Anthony Liguori <address@hidden> wrote:
> On 08/02/2011 06:25 PM, Juan Quintela wrote:
>> Anthony Liguori<address@hidden>  wrote:
>>> As Paolo points out, the migration protocol is ambiguous when using 
>>> subsections
>>> today.  That means that even if we preserve subsections and change the 
>>> protocol
>>> accordingly, the old protocol w/subsections is still ambiguous.
>>>
>>> Remove subsection usage and bump any device using subsections.  This 
>>> effectively
>>> eliminates the amiguouity and allows for a clean transition to a new 
>>> protocol
>>> with unambiguous subsections.
>>
>> If you are doing that, you can just remove the old protocol altogether.
>
> The fundamental problem is that newer QEMUs generate migration state
> that is ambiguous to older QEMUs.
>
> No matter what, we have to change the migration protocol in some way
> as to make it impossible to migrate from newer QEMUs to older QEMUs.
>
> Even with subsections in the older protocol, newer QEMUs (provided we
> don't add more subsections), can still read the old protocol.
>
> Paolo's proposed changes make newer QEMUs use a new protocol.  It's
> still possible to read the older protocol.  This means that you can't
> migrate new to old, but can migrate old to new.
>
> I've poured over these patches in great detail and the changes are
> just too much right now.  Just the ram_addr_t change which now
> conflicts has a non-trivial resolution due to a related Xen change.
>
> So my thinking is to be a bit more conservative.  If we bump the
> version number for 0.15.0, we make sure that we don't allow new -> old
> migration.  We will break old -> new migration, but we can fix that
> (including in the stable series) by adding special handling of the
> previous version.
>
> Fixing new->old is the critical bit here.  We can resolve old->new as
> a stable update.

We are making something that is incompatible.  If we don't care about
breaking 0.14 -> 0.15 migration.  Just add Paolo version, and drop
altogether the old protocol.  It will give us exactly the same result,
new versions work, old versions fail.

>> You are missing also ide on your patch.
>
> Thanks for catching that.
>
>>  Only platform that
>> ever cares about forward compatiblity is pc's.  And pc's always use
>> floppies on qemu.
>>
>> I still think that improving the "subsection" match is the way to go for 
>> 0.15.
>
> This series was just too late for 0.15.  I can close to suggesting
> that we delay 0.15 in order to give this time to be tested thoroughly
> but I think my proposal is a reasonable compromise.

I think it is anything except reasonable.  From my point on view (and I
am biased), it is the equivalent of finding a corner case broken on
qcow2 and make all _OLD_ qcow2 images unreadable.  It will work, but it
is anything except reasonable.  As said, everything uses an fdc.
Furthermore, the _two_ things that you change don't matter in the big
scheme of things.  The subsections that fail are the ones that can
appear in the middle of another section.  The ones that appear at the
end of a real section work perfectly well with this protocol (a.k.a. the
ones that are broken are IDE), floppy and rtl8139 are ok with current
protocol.

Later, Juan.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]