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

From: Gleb Natapov <gleb@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
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, 4 Sep 2011 15:25:18 +0300	[thread overview]
Message-ID: <20110904122518.GB15275@redhat.com> (raw)
In-Reply-To: <CAAu8pHtUhpvvP4OC-Tegp1oVD06gQy5xigFOdOuZFdyS1N84ww@mail.gmail.com>

> On Wed, Aug 31, 2011 at 6:17 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> On 2011-08-31 19:41, Blue Swirl wrote:
>>> On Wed, Aug 31, 2011 at 10:53 AM, Jan Kiszka <jan.kiszka@siemens.com> 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)
>>>
>>> Why, only for b)? This is not possible with real hardware.
>>>
>>>> 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.
>>>
>>> I think this would need pretty heavy changes everywhere. At board
>>> level the full path needs to be identified and special versions of
>>> IRQs installed along the way. The routers would need to use callbacks
>>> to inform other parties about routing changes.
>>
>> It already works in practice (based on a hack and minus IRQ router state
>> updates) for x86 PCI device pass-through. At least I don't want this
>> upstream but instead a generic solution. The ability to skip IRQ routers
>> also in pure user space device model scenarios is a useful by-product.
>>
>>>
>>>> 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.
>>>
>>> Perhaps a global IRQ manager could help. It would keep track of the
>>> whole IRQ matrix, what are input (x axis) and output (y axis) states
>>> and what each matrix node (router state) looks like (or able to
>>> compute) if asked. I don't think backward links would be needed with
>>> this approach.
>>
>> Well, the backward links would then be moved to that global IRQ manager.
>> It's just moving the data management, but if it turns out to allow a
>> cleaner device design, I would surely not vote against it. But that
>> manager must support lazy updates as well because we cannot call it from
>> kernel space for each and every event.
>
> The global IRQ switch matrix would take over all routing for the
> devices in question. As an example, let's consider a PCI card
> (source), PCI host bridge, IO-APIC, LAPIC and CPU (final destination).
--------------------------------------^ LAPICs and CPUs

--
			Gleb.