[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path
Date: Sun, 04 Sep 2011 10:31:07 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

On 09/04/2011 10:20 AM, Blue Swirl wrote:
On Sun, Sep 4, 2011 at 2:37 PM, Anthony Liguori<address@hidden>  wrote:
On 09/04/2011 08:57 AM, Anthony Liguori wrote:

On 09/04/2011 08:49 AM, Jan Kiszka wrote:

On 2011-09-04 15:41, Anthony Liguori wrote:

On 09/04/2011 08:36 AM, Jan Kiszka wrote:
Having some sort of global interrupt routing table is just going to add
a layer of complexity for very little obvious gain.

It's not yet decided how the problem is solved. A global interrupt
matrix is just one proposal, another option is to extend the pin model
in a way that supports routing change notifiers and backward polling.

If that's all you need, then you really just want notification on socket
changes. Backwards polling can be achieved by just adding state to the
Pin (which I full heartedly support).

If that's all you're proposing, than I'm entirely happy with it :-)

It's not that simple.

Routing paths can change because of device changes, not just socket changes.

Yes, that's why callbacks are needed to let the device inform global matrix.

I think you would need an interface for irq routing.  Something like:

struct IrqRouter {
    Interface parent;

    void (*foreach_output)(IrqRouter *obj,
                           void (*fn)(const char *out, void *opaque),
                           void *opaque);

    void (*foreach_input)(IrqRouter *obj,
                          void (*fn)(const char *in, void *opaque),
                          void *opaque);

Are the above a way for a parent to tell this device that its inputs
are changed?

No... there really isn't a notion of parent/children.

If something is interested in the routing path, it needs to listen for mapping changes at every IrqRouter point. I neglected to add an interface for registering for mapping changes so there would also need to be a notification registration interface here.

    const char *(*get_mapping)(IrqRouter *obj, const char *in);

This would be useful for the matrix too, the matrix would use this to
query for initial routing, maybe also for later changes if the change
callback didn't tell the mapping directly.

I think the main difference is, do you try to solve the problem everywhere, or do you just allow for certain paths to be introspected. And then who is reasonable for maintaining the full path.


You could then implement this interface in I440FX or any other controller
where we want to be able to support device passthrough.

Representing endpoints as strings means that you can correlate inputs to
outputs throughout the chain provided that you understand how inputs/outputs
relate to plugs/sockets.

The string format assumes that there is a reliable way to convert Pin
to string and vice versa. Why can't they be array of pointers to Pins?

Yes, all Pins are devices and all devices have unique names. You could just as easily use Pin *s.

It's not clear to me whether you want to make the strings device names or just property names though.

String representation (e.g. "/i440fx/address@hidden,0/address@hidden:2")
could be useful for debugging and 'info qtree' ('info irqtree'?)

IIUC, then this would be (in QOM)


This is the unique name the device would get. That's because the PIIX3 and Serial devices are created via composition. You could indirectly reference it multiple ways:



Anthony Liguori

reply via email to

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