On 12/19/2011 07:19 PM, Jan Kiszka wrote:
On 2011-12-20 02:08, Anthony Liguori wrote:
There's lot of inconsistency in qdev already today so adding a little
more isn't the end of the world. We're going to need to eventually have
this debate soon so it's up to you whether you want to just get this
merged now and worry about this another day or resolve this before merge.
I don't see any compatibility issues here so I'm not really concerned
about introducing a regression by breaking it into two devices.
I don't want to see yet another attempt merged that requires foreseeable
refactoring later on. The point of this one is to do it in a way that is
providing a sound foundation for all those other features that still
wait in qemu-kvm for refactoring.
Excellent, that was what I was hoping for :-)
The point is that migration support between in-kernel on/off is a
worthwhile feature we should design for.
I'm not convinced of that but for the sake of this discussion, let's assume it is.
I would hope that you would agree that when designing the device model, we
should aim to do what makes sense independent of migration. If we cannot
achieve a certain feature with migration given the logical modeling of devices,
it probably suggests that we need to improve our migration infrastructure.
I assume that given the above, we all agree that separate devices is what makes
the most sense ignoring migration. If so, let's just focus on how to make
migration work.
That either means skipping the
backend property on device tree migration (maybe a feature we want in
other use cases as well) or provide an alias naming scheme where you can
address APICs, IOAPICs, i8259, i8254 and all the chips that non-x86 will
bring us without knowing where they are implemented and without worrying
to migrate between those variants. If you have a good model for that in
mind, rolling back to v1, rebasing improvements from v5 over it would
not be a big deal. But everyone in this round should agree on this
first. I don't wanna port back and forth nor refactor all this again
when once it's in.
Here's how we solve this problem:
1) In the short term, advertise both devices as having the same VMstate name.
Since we don't register until the device is instantiated, this will Just Work
and is easy.
2) In the not so short term, we'll have Mike Roth's Visitor series land in the
tree (Juan promised me it will be in his next pull request).
3) Once we have the Visitor infrastructure in place, we can introduce a self
describing migration format (that will also use QOM path names). With a self
describing format, we can read all of the data from the wire into memory without
consulting devices.
4) We now have the ability to arbitrarily manipulate this tree in memory. It's
just a matter or writing a small tree transformer that converts the KVM-APIC
state to the APIC device state (by just renaming a level of the tree). Heck, we
could even map fields if we needed to (although we should probably avoid
divergence if at all possible).
5) We can now hand this manipulated tree to an input Visitor and the devices
will read it in as if it came from the same device.
This is the level of flexibility we need to support migration compatibility
moving forward. We're actually not that far from it either. We'll definitely
have it in place before we have a new migration protocol.
Regards,
Anthony Liguori
Jan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
