qemu-devel
[Top][All Lists]
Advanced

[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 09:37:33 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

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.

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);

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

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.

I think this has the property of letting you write reasonably generic code to discover routing while only having to add complexity to the bare minimum set of devices to enable device passthrough.

It's basically what I suggested for PCI INTx mapping but a little more generic as an interface so that it can extend to other types of devices.

Regards,

Anthony Liguori

I'm happy with that because all of the route detection logic can live
outside of the devices which at least contains the complexity.

Regards,

Anthony Liguori




reply via email to

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