From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0EsJ-0004wa-QY for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:44:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0EsI-00061o-8F for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:44:47 -0400 Received: from mail-qy0-f180.google.com ([209.85.216.180]:55189) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0EsI-00061f-5H for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:44:46 -0400 Received: by qyk31 with SMTP id 31so2605934qyk.4 for ; Sun, 04 Sep 2011 08:44:45 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E6399BB.9040608@codemonkey.ws> References: <4E58FC3F.6080809@web.de> <4E5BE7C5.60705@us.ibm.com> <4E5BFF51.9010503@web.de> <4E5C00F0.9070103@redhat.com> <4E5D39C8.5020205@web.de> <4E5E1297.3050904@siemens.com> <4E628607.20309@codemonkey.ws> <4E636B56.9070808@web.de> <4E637E06.9020206@codemonkey.ws> <4E637EEA.1030502@web.de> <4E638010.9010503@codemonkey.ws> <4E6381D9.5060709@web.de> <4E6383CB.3070102@codemonkey.ws> <4E638D2D.6060503@codemonkey.ws> <4E6399BB.9040608@codemonkey.ws> From: Blue Swirl Date: Sun, 4 Sep 2011 15:44:24 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Anthony Liguori Cc: Lucas Meneghel Rodrigues , Peter Maydell , Marcelo Tosatti , qemu-devel , Jan Kiszka , Avi Kivity , Gerd Hoffmann On Sun, Sep 4, 2011 at 3:31 PM, Anthony Liguori wro= te: > On 09/04/2011 10:20 AM, Blue Swirl wrote: >> >> On Sun, Sep 4, 2011 at 2:37 PM, Anthony Liguori >> =C2=A0wrote: >>> >>> On 09/04/2011 08:57 AM, Anthony Liguori wrote: >>>> >>>> On 09/04/2011 08:49 AM, Jan Kiszka wrote: >>>>> >>>>> On 2011-09-04 15:41, Anthony Liguori wrote: >>>>>> >>>>>> On 09/04/2011 08:36 AM, Jan Kiszka wrote: >>>>>> Having some sort of global interrupt routing table is just going to >>>>>> add >>>>>> a layer of complexity for very little obvious gain. >>>>> >>>>> It's not yet decided how the problem is solved. A global interrupt >>>>> matrix is just one proposal, another option is to extend the pin mode= l >>>>> in a way that supports routing change notifiers and backward polling. >>>> >>>> If that's all you need, then you really just want notification on sock= et >>>> changes. Backwards polling can be achieved by just adding state to the >>>> Pin (which I full heartedly support). >>>> >>>> If that's all you're proposing, than I'm entirely happy with it :-) >>> >>> It's not that simple. >>> >>> Routing paths can change because of device changes, not just socket >>> changes. >> >> Yes, that's why callbacks are needed to let the device inform global >> matrix. >> >>> I think you would need an interface for irq routing. =C2=A0Something li= ke: >>> >>> struct IrqRouter { >>> =C2=A0 =C2=A0Interface parent; >>> >>> =C2=A0 =C2=A0void (*foreach_output)(IrqRouter *obj, >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 void (*fn)(const char *out, void *opaque), >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 void *opaque); >>> >>> =C2=A0 =C2=A0void (*foreach_input)(IrqRouter *obj, >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0void (*fn)(const char *in, void *opaque), >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0void *opaque); >> >> Are the above a way for a parent to tell this device that its inputs >> are changed? > > No... there really isn't a notion of parent/children. > > If something is interested in the routing path, it needs to listen for > mapping changes at every IrqRouter point. =C2=A0I neglected to add an int= erface > for registering for mapping changes so there would also need to be a > notification registration interface here. With that change I think we're 100% in agreement. >> >>> =C2=A0 =C2=A0const char *(*get_mapping)(IrqRouter *obj, const char *in)= ; >> >> This would be useful for the matrix too, the matrix would use this to >> query for initial routing, maybe also for later changes if the change >> callback didn't tell the mapping directly. > > I think the main difference is, do you try to solve the problem everywher= e, > or do you just allow for certain paths to be introspected. And then who i= s > reasonable for maintaining the full path. The matrix should take full responsibility for the devices (and the connections of those devices) that are under its control. Other devices can continue to do as before, they can be converted to matrix if needed. The benefit from the matrix would be performance and that would come from lazy update of the devices in addition to the fast direct path from source to final destination. If all the intermediate devices are probed by the OS (if there are no vectored interrupts etc. to determine the IRQ from PC), the lazy updates will not help and benefit will be lower. >> >>> }; >>> >>> You could then implement this interface in I440FX or any other controll= er >>> where we want to be able to support device passthrough. >>> >>> Representing endpoints as strings means that you can correlate inputs t= o >>> outputs throughout the chain provided that you understand how >>> inputs/outputs >>> relate to plugs/sockets. >> >> The string format assumes that there is a reliable way to convert Pin >> to string and vice versa. Why can't they be array of pointers to Pins? > > Yes, all Pins are devices and all devices have unique names. =C2=A0You co= uld just > as easily use Pin *s. > > It's not clear to me whether you want to make the strings device names or > just property names though. I think either would work if the string->Pin conversion works. >> >> String representation (e.g. "/i440fx/pci-bridge@2,0/serial@3fc:2") >> could be useful for debugging and 'info qtree' ('info irqtree'?) >> though. > > IIUC, then this would be (in QOM) > > i440fx::piix3::serial[0]::irq > > This is the unique name the device would get. =C2=A0That's because the PI= IX3 and > Serial devices are created via composition. =C2=A0You could indirectly re= ference > it multiple ways: > > /i440fx/slot[2]/serial[0]/irq > /i440fx/piix3/serial[0]/irq > > Regards, > > Anthony Liguori >