From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39539) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0D4X-0006s9-8p for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:49:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0D4V-0003fy-Rn for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:49:17 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:35849) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0D4V-0003fu-Fs for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:49:15 -0400 Message-ID: <4E6381D9.5060709@web.de> Date: Sun, 04 Sep 2011 15:49:13 +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> <4E636B56.9070808@web.de> <4E637E06.9020206@codemonkey.ws> <4E637EEA.1030502@web.de> <4E638010.9010503@codemonkey.ws> In-Reply-To: <4E638010.9010503@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig12AB101D90332BC38DAC4EB1" 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 , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity , Gerd Hoffmann This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig12AB101D90332BC38DAC4EB1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-09-04 15:41, Anthony Liguori wrote: > On 09/04/2011 08:36 AM, Jan Kiszka wrote: >> On 2011-09-04 15:32, Anthony Liguori wrote: >>> I prefer to not think of IRQs as special things. They're just single= >>> bits of information that flow through the device model. Having a hig= her >>> level representation that understands something like paths seems wron= g >>> to me. >>> >>> I'd prefer to treat things like device assignment as a hack. You jus= t >>> need code that can walk the device tree to figure out the path (which= is >>> not generic code, it's very machine specific). Then you tell the ker= nel >>> the resolution of the path and are otherwise completely oblivious in >>> userspace. >> >> See it as you like, but we need the support, not only for device >> assigment. And I do not see any gain it hacking this instead of >> designing it. >=20 > You can design a hack but it's still a hack. >=20 > Device state belongs in devices. Trying to extract device state > (interrupt routing paths) and externalizing it is by definition a hack.= >=20 > 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 model in a way that supports routing change notifiers and backward polling. >=20 > The PCI bus *is* the I/O APIC for all intents and purposes. Being able= > to ask the i440fx for the interrupt corresponding to a device is a very= > simple task that involves no generic code. That's more than enough to > support device assignment. >=20 > Why overcomplicate things when the problem can be solved robustly with > most likely a 10 line function? Fine, then INTx is solved. And we will hate us for hacking things for this single purpose when we later on want to support, say, MSI routing though an emulated interrupt remapper. Or routing of the Q35 chipset. It is not only INTx for device assignment, and it is not only x86. Jan --------------enig12AB101D90332BC38DAC4EB1 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/ iEYEARECAAYFAk5jgdkACgkQitSsb3rl5xRDagCfWBIJj4HU/ayt0PsFfZUwE9EJ sfUAn2eSjknu3ZdG2U67ePLKf1NkavXf =/4T8 -----END PGP SIGNATURE----- --------------enig12AB101D90332BC38DAC4EB1--