[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v5 00/16] uq/master: Introduce basic irqchip support
Date: Mon, 19 Dec 2011 20:46:32 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

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 

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.


Anthony Liguori


reply via email to

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