Re: [Qemu-devel] [PATCH v5 00/16] uq/master: Introduce basic irqchip support

[Anthony Liguori <anthony@codemonkey.ws>]

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
>