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

From: Jan Kiszka <jan.kiszka@web.de>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Lucas Meneghel Rodrigues <lmr@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Blue Swirl <blauwirbel@gmail.com>, Avi Kivity <avi@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path
Date: Sun, 04 Sep 2011 15:42:28 +0200	[thread overview]
Message-ID: <4E638044.5020709@web.de> (raw)
In-Reply-To: <4E637F53.6010102@codemonkey.ws>

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

On 2011-09-04 15:38, Anthony Liguori wrote:
> On 09/04/2011 07:37 AM, Jan Kiszka wrote:
>> On 2011-09-04 14:17, Avi Kivity wrote:
>>> On 08/31/2011 01:53 PM, 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.
>>>>
>>>> We haven't thought about how this could be implemented in details yet
>>>> though. Among other things, it heavily depends on the final QOM design.
>>>>
>>>
>>> Looks like a similar path to the memory API.  A declarative description
>>> of the interrupt hierarchy allows routes to be precalculated and
>>> flattened.
>>>
>>> (here it's strictly an optimization; with the memory API it's a
>>> requirement since kvm requires a flattened representation, and tcg is
>>> greatly simplified by it).
>>
>> With current kvm device assignment it's mandatory as it only support
>> kernel/kernel IRQ delivery. Only vfio's eventfds will make it optional
>> (but still highly desirable).
> 
> It's not mandatory.  All you need to be able to do is calculate the APIC
> IRQ for a given PCI device interrupt.

...and establish notifies for changes along this line. And allow to
update intermediate states on access.

>  That doesn't mean we need to be
> able to do arbitrary interrupt resolution in generic code.

We will likely have to solve the same problem on none x86 as well.

> 
> There is potentially tremendous complexity here because you'll have to
> bake all interrupt rerouting logic into a declarative API and/or call
> into generic code to update routing tables.  Given the fact that we
> can't even generically refer to a device reliably today, this is would
> be a daunting task.
> 
> We're making this all more complicated than it needs to be.

We can't discuss the problem away, sorry.

Jan

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