* Re: About improving devices and renaming migration stream...
2020-06-04 7:33 About improving devices and renaming migration stream Philippe Mathieu-Daudé
@ 2020-06-04 9:27 ` Dr. David Alan Gilbert
0 siblings, 0 replies; 2+ messages in thread
From: Dr. David Alan Gilbert @ 2020-06-04 9:27 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Peter Maydell, Paolo Bonzini, qemu-devel, Markus Armbruster
* Philippe Mathieu-Daudé (philmd@redhat.com) wrote:
> Hello Dave,
>
> ==[background]==
>
> I've been doing this pflash rework:
>
> * Add abstract TYPE_NOR_FLASH
>
> - qdev type
> - blockdev backend
> - manage bank/sector,
> - manage timer for erase/write delays
> - can be used by I2C/SPI NOR flash too
>
> * Add abstract TYPE_PARALLEL_NOR_FLASH
>
> - mostly SysBusDevice bindings
>
> * Add TYPE_COMMON_FLASH_MEMORY_INTERFACE
>
> - common CFI code
> - abstracts CFI methods
>
> * Refactor TYPE_PFLASH_CFI02
> -> TYPE_PARALLEL_NOR_CFI02_FLASH
>
> - Inherit TYPE_NOR_FLASH -> TYPE_PARALLEL_NOR_FLASH
> - Implements TYPE_COMMON_FLASH_MEMORY_INTERFACE
>
>
> I kept the harder for the end... (maybe bad idea):
> - migration
> - CFI01
>
>
> ==[problems]==
>
>
> 1/ Can I change the name of a migration stream?
>
> I want to add migration from old TYPE_PFLASH_CFI02 to
> TYPE_PARALLEL_NOR_CFI02_FLASH, and deprecate TYPE_PFLASH_CFI02.
>
> From docs/devel/migration.rst:
>
> "The ``ID string`` is normally unique, having been
> formed from a bus name and device address, PCI devices
> and storage devices hung off PCI controllers fit this
> pattern well. Some devices are fixed single instances
> (e.g. "pc-ram").
> Others (especially either older devices or system devices
> which for some reason don't have a bus concept) make use
> of the ``instance id`` for otherwise identically named
> devices."
>
> I started TYPE_PARALLEL_NOR_CFI02_FLASH from a clean design,
> I'm not sure I can redo everything keeping the same type name.
>
> Is it possible to use massaging functions to migrate from
> TYPE_A (version y) to TYPE_B (version x)?
There's normally a way to fudge it.
Most devices use a path rather than the class; so the type is irrelevant.
When they use the type then you can register a device with the old name
to read the old migration stream. There's no check during migration
loading that every device receives a stream, so if your old device hook
receives it and the new one doesn't that may work.
Having said all that, I'm struggling to find any migration entries in
pflash_cfi02 - I tried a ppc405 'taihu' device and that doesn't seem to
have anything for the pflash_cfi02 other than the RAM section.
A q35 pflash though does land in the stream as pflash_cfi01 I think with
instance id's to separate 2 devices (which is pretty horrid!).
> 2/ Do I need to care about backward compatibility?
>
> I understand we want to migrate from old -> new QEMU version.
>
> From docs/devel/migration.rst:
>
> "In general QEMU tries to maintain forward migration
> compatibility (i.e. migrating from QEMU n->n+1) and
> there are users who benefit from backward
> compatibility as well."
>
> When is it important to migrate from new -> old?
Downgrade does get used in clusters of hosts; imagine you've got 'n'
machines, most of which are running VMs, managed by something that
migrates VMs between them; maybe for load balancing or maybe for dealing
with failures etc. Now, it's time to upgrade - so you take one machine,
migrate everything off it, upgrade that machine, and add it back into
the cluster; VMs get started on it or migrated to it (forward
migration). If you need to take this host down for any reason, or
load balance, you require backward migration to move those VMs
to an older host.
In a small installation with a few hosts you might get away with it
by having enough spare hosts to upgrade - but if it's say a 3 host setup
then you've not got much room.
In a big installation it can be tricky for the opposite reason; you end
up with effectively 2 separate clusters until everything is upgraded.
People tend to care less about backwards migration for emulation
uses rather than cluster uses.
> Can this be a blocker?
For some machines yes; downstream we (RH) support some combination of
backwards migration - so someone would have to make it work.
> Am I doomed to keep the old device forever?
The back compatibility can get deprecated at some point; determining
'when' comes down to when no one cares about it any longer, and that's
based on when people have supported installations of clusters using
the old version, which is tricky to tell.
> Is this what are versioned machines for?
> I.e. adding machine-v6 that start with the newer devices,
> breaking backward compat.
Yes, that's one use for it; machine types do double-duty; they provide
a way to switch the guest view of a device/machine, but they also
provide the way to switch a migration stream incompatibility.
Dave
> Thanks,
>
> Phil.
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 2+ messages in thread