[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: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path
Date: Sun, 04 Sep 2011 15:36:42 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

On 2011-09-04 15:32, Anthony Liguori wrote:
> On 09/04/2011 07:13 AM, Jan Kiszka wrote:
>> On 2011-09-03 21:54, Anthony Liguori wrote:
>>> On 08/31/2011 05:53 AM, Jan Kiszka wrote:
>>>> On 2011-08-31 10:25, Peter Maydell wrote:
>>>>> On 30 August 2011 20:28, Jan Kiszka<address@hidden>   wrote:
>>>>>> Yes, that's the current state. Once we have bidirectional IRQ
>>>>>> links in
>>>>>> place (pushing downward, querying upward - required to skip IRQ
>>>>>> routers
>>>>>> for fast, lockless deliveries), that should change again.
>>>>> Can you elaborate a bit more on this? I don't think anybody has
>>>>> proposed links with their own internal state before in the qdev/qom
>>>>> discussions...
>>>> That basic idea is to allow
>>>> a) a discovery of the currently active IRQ path from source to sink
>>>>      (that would be possible via QOM just using forward links)
>>>> b) skip updating the states of IRQ routers in the common case, just
>>>>      signaling directly the sink from the source (to allow in-kernel
>>>> IRQ
>>>>      delivery or to skip taking some device locks). Whenever some
>>>> router
>>>>      is queried for its current IRQ line state, it would have to ask
>>>> the
>>>>      preceding IRQ source for its state. So we need a backward link.
>>> Can you provide some concrete use-cases of this?  I'm not convinced this
>>> is really all that important and it seems like tremendous amounts of
>>> ugliness would be needed to support it.
>> INTx support for device assignment, vhost, or any other future in-kernel
>> IRQ sources.
> I prefer to not think of IRQs as special things.  They're just single
> bits of information that flow through the device model.  Having a higher
> level representation that understands something like paths seems wrong
> to me.
> I'd prefer to treat things like device assignment as a hack.  You just
> need code that can walk the device tree to figure out the path (which is
> not generic code, it's very machine specific).  Then you tell the kernel
> the resolution of the path and are otherwise completely oblivious in
> userspace.

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.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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