From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0Cyl-0005mC-RA for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:43:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0Cyk-0002v6-1s for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:43:19 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:60232) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0Cyj-0002uy-NM for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:43:18 -0400 Message-ID: <4E638044.5020709@web.de> Date: Sun, 04 Sep 2011 15:42:28 +0200 From: Jan Kiszka MIME-Version: 1.0 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> <4E636C72.4080608@redhat.com> <4E6370FD.2010703@web.de> <4E637F53.6010102@codemonkey.ws> In-Reply-To: <4E637F53.6010102@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB175F56C5E3DFBDBCE429701" Sender: jan.kiszka@web.de 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 , Anthony Liguori , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity , Gerd Hoffmann This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB175F56C5E3DFBDBCE429701 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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/q= om >>>>> 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 ye= t >>>> though. Among other things, it heavily depends on the final QOM desi= gn. >>>> >>> >>> Looks like a similar path to the memory API. A declarative descripti= on >>> 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). >=20 > It's not mandatory. All you need to be able to do is calculate the API= C > IRQ for a given PCI device interrupt. =2E..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. >=20 > 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. >=20 > We're making this all more complicated than it needs to be. We can't discuss the problem away, sorry. Jan --------------enigB175F56C5E3DFBDBCE429701 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5jgEQACgkQitSsb3rl5xSbbACfW7aU3z2ET5MAPC2/oAViCQ/B 1jUAoJhgy5DDRBzKLQ1gOjTcjVsZ4MrD =EPiT -----END PGP SIGNATURE----- --------------enigB175F56C5E3DFBDBCE429701--