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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]

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<jan.kiszka@web.de>  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. And optimized user space IRQ delivery, particularly under
real-time constraints.

When designing those requirements into a new IRQ/pin management model
right from the beginning, that shouldn't be as ugly as you may think. At
least it will be less ugly and more correct than what we already have in
qemu-kvm today.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]