From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54469) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0BZl-0003qz-KZ for qemu-devel@nongnu.org; Sun, 04 Sep 2011 08:13:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0BZk-0003uc-FC for qemu-devel@nongnu.org; Sun, 04 Sep 2011 08:13:25 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:51966) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0BZj-0003uM-U0 for qemu-devel@nongnu.org; Sun, 04 Sep 2011 08:13:24 -0400 Message-ID: <4E636B56.9070808@web.de> Date: Sun, 04 Sep 2011 14:13:10 +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> <4E628607.20309@codemonkey.ws> In-Reply-To: <4E628607.20309@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig038746EF2C2E0704CC35A16F" 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) --------------enig038746EF2C2E0704CC35A16F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-09-03 21:54, Anthony Liguori wrote: > On 08/31/2011 05:53 AM, 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 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 >> (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 IR= Q >> delivery or to skip taking some device locks). Whenever some route= r >> is queried for its current IRQ line state, it would have to ask th= e >> preceding IRQ source for its state. So we need a backward link. >=20 > Can you provide some concrete use-cases of this? I'm not convinced thi= s=20 > is really all that important and it seems like tremendous amounts of=20 > ugliness would be needed to support it. INTx support for device assignment, vhost, or any other future in-kernel IRQ sources. And optimized user space IRQ delivery, particularly under real-time constraints. When designing those requirements into a new IRQ/pin management model right from the beginning, that shouldn't be as ugly as you may think. At least it will be less ugly and more correct than what we already have in qemu-kvm today. Jan --------------enig038746EF2C2E0704CC35A16F 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/ iEYEARECAAYFAk5ja1YACgkQitSsb3rl5xQdtQCeIAsAc9WHYDoHCccoAAu9Aqz3 ON4AoOXpZKI2ji3YQp9Q8i4hRH8PiGdJ =Cz7S -----END PGP SIGNATURE----- --------------enig038746EF2C2E0704CC35A16F--