[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: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path
Date: Sun, 4 Sep 2011 15:27:46 +0000

On Sun, Sep 4, 2011 at 2:43 PM, Anthony Liguori <address@hidden> wrote:
> On 09/04/2011 09:12 AM, Avi Kivity wrote:
>> On 09/04/2011 04:41 PM, Anthony Liguori wrote:
>>>> See it as you like, but we need the support, not only for device
>>>> assigment. And I do not see any gain it hacking this instead of
>>>> designing it.
>>> You can design a hack but it's still a hack.
>>> Device state belongs in devices. Trying to extract device state
>>> (interrupt routing paths) and externalizing it is by definition a hack.
>> Pet peeve - saying something is "by definition" a hack is just rhetoric
>> unless the definition of device state is "something that cannot be
>> extracted and externalized". Let's avoid this.
> Likewise, I would prefer to avoid stating that something is a hard
> requirement in the absence of concrete use-cases.
> I do think the definition of device state is more or less something that is
> opaque and owned by the device.  The more we externalize the device state,
> the more we have to deal with compatibility (even if it's just internal
> compatibility).  This makes modularity hard because there's too many things
> with complex dependencies.
>> In fact it's exactly what we do with the memory API. Memory routing is
>> part of device state, yet we expose it to the memory API and let it do
>> its thing instead of going through the hierarchy on every single memory
>> access.
> Yes, and the memory API is complicated and invasive :-)  But it's worth it
> at the end of the day (although I think it could be simplified at the
> expensive of not allowing as much flattening).
>> Whether it's worthwhile to do this for interrupts as well depends on how
>> common the situation is and what we gain from it. We can only do this if
>> the routing is semi-static (depends only on other state but not the
>> actual interrupt) - probably the only exception to this is the "least
>> priority" mode which means the last leg cannot be computed statically.
>> I agree the gain is low if we limit ourselves to 440fx, but if we add
>> interrupt remapping it becomes considerably more complicated to do this
>> backward path computation.
> If we start with a simple interface that works for the i440fx and then
> expand it as we support more layers, I think we'll be okay.
> What I'm concerned about is an attempt to globally track IRQ routing.  I can
> imagine constructing a board where you have two simple devices that have
> level triggered interrupts and wanting to tie them to a single input pin.  A
> simple OR gate would be sufficient to do this.  Having to make an OR gate an
> IRQ router seems like far too much complexity to me.

For the simple OR gate this is a downside of course, but I don't see a
way to avoid it, same with the memory API or other APIs that need to
cater for wide variety of needs.

> I think we need to strive to keep simple things simple.

If the APIs need only minor changes, the changes to the devices would
not be so big. At this point I think your router API would only need
the change callback to support the matrix and Pin should be

> Regards,
> Anthony Liguori

reply via email to

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