From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SceLy-00050b-63 for qemu-devel@nongnu.org; Thu, 07 Jun 2012 11:10:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SceLw-0008CY-2j for qemu-devel@nongnu.org; Thu, 07 Jun 2012 11:10:25 -0400 Received: from mout.web.de ([212.227.17.12]:59106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SceLv-0008CJ-PW for qemu-devel@nongnu.org; Thu, 07 Jun 2012 11:10:24 -0400 Message-ID: <4FD0C459.7070104@web.de> Date: Thu, 07 Jun 2012 17:10:17 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20120607143216.GA12638@redhat.com> In-Reply-To: <20120607143216.GA12638@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1B6E51A8F9D6180805E35C44" Subject: Re: [Qemu-devel] [PATCH 05/13] pci: Add pci_device_route_intx_to_irq List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Alex Williamson , qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1B6E51A8F9D6180805E35C44 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-06-07 16:32, Michael S. Tsirkin wrote: > On Mon, Jun 04, 2012 at 10:52:13AM +0200, Jan Kiszka wrote: >> @@ -1089,6 +1093,14 @@ static void pci_set_irq(void *opaque, int irq_n= um, int level) >> pci_change_irq_level(pci_dev, irq_num, change); >> } >> =20 >> +PCIINTxRoute pci_device_route_intx_to_irq(PCIDevice *dev, int pin) >> +{ >> + PCIBus *bus =3D dev->host_bus; >> + >> + assert(bus->route_intx_to_irq); >> + return bus->route_intx_to_irq(bus->irq_opaque, dev->host_intx_pin= [pin]); >> +} >> + >> /***********************************************************/ >> /* monitor info on PCI */ >> =20 >=20 > Just an idea: can devices cache this result, bypassing the > intx to irq lookup on data path? That lookup is part of set_irq which we don't bypass so far and where this is generally trivial. If we want to cache the effects of set_irq as well, I guess things would become pretty complex (e.g. due to vmstate compatibility), and I'm unsure if it would buy us much. >=20 >> diff --git a/hw/pci.h b/hw/pci.h >> index 5b54e2d..bbba01e 100644 >> --- a/hw/pci.h >> +++ b/hw/pci.h >> @@ -141,6 +141,15 @@ enum { >> #define PCI_DEVICE_GET_CLASS(obj) \ >> OBJECT_GET_CLASS(PCIDeviceClass, (obj), TYPE_PCI_DEVICE) >> =20 >> +typedef struct PCIINTxRoute { >> + enum { >> + PCI_INTX_ENABLED, >> + PCI_INTX_INVERTED, >> + PCI_INTX_DISABLED, >> + } mode; >> + int irq; >> +} PCIINTxRoute; >=20 > Is this INTX route or IRQ route? > Is the INTX enabled/disabled/inverted or the IRQ? >=20 > I have the impression it's the IRQ, in the apic. > PCI INTX are never inverted they are always active low. This should be considered as "the route *of* an INTx", not "to some IRQ". I could call it PCIINTxToIRQRoute if you prefer, but it's a bit lengthy. Jan --------------enig1B6E51A8F9D6180805E35C44 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/ iEYEARECAAYFAk/QxFkACgkQitSsb3rl5xQdowCcC2mbj4zn0hApw8U/5be3eDGu uz8An19d7GnMnZrwZFbGDgidl9vg6ox6 =faDm -----END PGP SIGNATURE----- --------------enig1B6E51A8F9D6180805E35C44--