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

[Avi Kivity]

On 12/20/2011 02:42 AM, Anthony Liguori wrote:
>> Look down http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82598
>> for the discussion of that model.
>
>
> I have.  I don't understand the rationale for jumping through hoops here.
>
> There seems to be an assertion that migrating from in-kernel APIC to
> userspace APIC is an important use case.  I don't really see how
> that's true.
>

That's only because no one is using qemu.git for virtualization.  If
they were, then you'd prevent existing users from using it, except
through guest shutdown and relaunch of qemu (and perhaps reconfiguration).

We've discussed removing the ioapic from the kernel.  If we do that,
then we need to support migration from in-kernel ioapic to userspace ioapic.

> But nonetheless, the direction migration is heading is not just to
> migrate the QOM path names to identify devices, but to provide a way
> to introspect the device model, transfer the current device model
> description to the other end, and create the device model on the
> destination.
>
> This is the only way to reliably support things like hot-plug during
> live migration which is something we punt to management tools (which
> really can't implement it properly).
>
> So we'll already be migrating the apic backend property which means
> that you are not going to have migration to and from in-kernel APIC
> and userspace APIC without some sort of in-between translation layer
> (which could just as easily change the device names).

To what?

The backend property should be private and not migrated.

-- 
error compiling committee.c: too many arguments to function