From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0BlN-0006AH-Gq for qemu-devel@nongnu.org; Sun, 04 Sep 2011 08:25:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0BlM-0005xI-4p for qemu-devel@nongnu.org; Sun, 04 Sep 2011 08:25:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0BlL-0005wz-U3 for qemu-devel@nongnu.org; Sun, 04 Sep 2011 08:25:24 -0400 Date: Sun, 4 Sep 2011 15:25:18 +0300 From: Gleb Natapov Message-ID: <20110904122518.GB15275@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Lucas Meneghel Rodrigues , Peter Maydell , Anthony Liguori , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity , Gerd Hoffmann > On Wed, Aug 31, 2011 at 6:17 PM, Jan Kiszka wrot= e: >> On 2011-08-31 19:41, Blue Swirl wrote: >>> On Wed, Aug 31, 2011 at 10:53 AM, Jan Kiszka w= rote: >>>> On 2011-08-31 10:25, Peter Maydell wrote: >>>>> On 30 August 2011 20:28, Jan Kiszka wrote: >>>>>> Yes, that's the current state. Once we have bidirectional IRQ links = in >>>>>> place (pushing downward, querying upward - required to skip IRQ rout= ers >>>>>> 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 >>>> =9A (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 >>>> =9A signaling directly the sink from the source (to allow in-kernel IRQ >>>> =9A delivery or to skip taking some device locks). Whenever some router >>>> =9A is queried for its current IRQ line state, it would have to ask the >>>> =9A 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.