Re: KVM call minutes 2013-01-29

[Anthony Liguori <aliguori@us.ibm.com>]

Alexander Graf <agraf@suse.de> writes:

> On 01/29/2013 04:41 PM, Juan Quintela wrote:
>>    Alex will fill this
>
> When using -device, we can not specify an IRQ line to attach to the 
> device. This works for some special buses like PCI, but not in the 
> generic case. We need it generically for virtio-mmio and for potential 
> platform assigned vfio devices though.
>
> The conclusion we came up with was that in order to model IRQ lines 
> between arbitrary devices, we should use QOM and the QOM name space. 
> Details are up for Anthony to fill in :).

Oh good :-)  This is how far I got since I last touched this problem.

https://github.com/aliguori/qemu/commits/qom-pin.4

qemu_irq is basically foreign to QOM/qdev.  There are two things I did
to solve this.  The first is to have a stateful Pin object.  Stateful is
important because qemu_irq is totally broken wrt reset and live
migration as it stands today.

It's pretty easy to have a Pin object that can "connect" to a qemu_irq
source or sink which means we can incrementally refactor by first
converting each device under a bus to using Pins (using the qemu_irq
connect interface to maintain compat) until the bus controller can be
converted to export Pins allowing a full switch to using Pins only for
that bus.

The problems I ran into were (1) this is a lot of work (2) it basically
requires that all bus children have been qdev/QOM-ified.  Even with
something like the ISA bus which is where I started, quite a few devices
were not qdevified still.

I'm not going to be able to work on this in the foreseeable future, but
if someone wants to take it over, I'd be happy to provide advice.

I'm also open to other approaches that require less refactoring but I
honestly don't know that there is a way to avoid the heavy lifting.

Regards,

Anthony Liguori

>
>
> Alex
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html