qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Bernhard Beschow <shentey@gmail.com>
To: qemu-devel@nongnu.org,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	mst@redhat.com, marcel.apfelbaum@gmail.com, philmd@linaro.org,
	alex.bennee@linaro.org
Subject: Re: [RFC PATCH 03/18] hw/pci: use PCIDevice gpio for device IRQ
Date: Thu, 11 May 2023 21:44:51 +0000	[thread overview]
Message-ID: <C77CADEE-2FB5-4928-A9F2-8ECD2643CFF2@gmail.com> (raw)
In-Reply-To: <20230511085731.171565-4-mark.cave-ayland@ilande.co.uk>



Am 11. Mai 2023 08:57:16 UTC schrieb Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>:
>Change pci_set_irq() to call qemu_set_irq() on the PCI device IRQ rather than
>calling PCI bus IRQ handler function directly. In order to preserve the
>existing behaviour update pci_qdev_realize() so that it automatically connects
>the PCI device IRQ to the PCI bus IRQ handler.
>
>Finally add a "QEMU interface" description documenting the new PCI device IRQ
>gpio next to the declaration of TYPE_PCI_DEVICE.
>
>Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
>---
> hw/pci/pci.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
>diff --git a/hw/pci/pci.c b/hw/pci/pci.c
>index 9471f996a7..3da1481eb5 100644
>--- a/hw/pci/pci.c
>+++ b/hw/pci/pci.c
>@@ -1680,8 +1680,7 @@ qemu_irq pci_allocate_irq(PCIDevice *pci_dev)
> 
> void pci_set_irq(PCIDevice *pci_dev, int level)
> {
>-    int intx = pci_intx(pci_dev);
>-    pci_irq_handler(pci_dev, intx, level);
>+    qemu_set_irq(pci_dev->irq, level);
> }
> 
> /* Special hooks used by device assignment */
>@@ -2193,6 +2192,10 @@ static void pci_qdev_realize(DeviceState *qdev, Error **errp)
>     pci_set_power(pci_dev, true);
> 
>     pci_dev->msi_trigger = pci_msi_trigger;
>+
>+    /* Connect device IRQ to bus */
>+    qdev_connect_gpio_out(DEVICE(pci_dev), 0,
>+                          pci_get_bus(pci_dev)->irq_in[pci_dev->devfn]);

I think this is confusing a few things. In my understanding -- unlike ISA -- PCI considers interrupt lanes only for PCI slots but not for buses. So for example each PCI slot could have its own direct connections (up to four, intA..intD) to the interrupt controller. IOW interrupt lanes and PCI buses are unrelated, thus PCIBus shouldn't really have IRQs.

Moreover, in case the interrupt lines are shared between multiple PCI slots, a usual pattern is to swizzle these lines such that the intAs from the slots don't all occupy just one IRQ line. That means that depending on the slot the device is plugged into a different lane is triggered. Above code, however, would always trigger the same line and wouldn't even allow for modeling the swizzeling.

Also, above code would cause out of bounds array accesses if a PCI device had more functions than there are on "the bus":
For example, consider PIIX which has four PIRQs, so ARRAY_SIZE(irq_fn) == 4, right? devfn can be up to 8 according to the PCI spec which would cause an out if bounds array access above.

I think that this commit does actually re-define how PCI buses work in QEMU although the cover letter claims to save this for another day. We should probably not apply the series in its current form.

Best regards,
Bernhard

> }
> 
> static void pci_device_init(Object *obj)
>@@ -2850,6 +2853,11 @@ void pci_set_power(PCIDevice *d, bool state)
>     }
> }
> 
>+/*
>+ * QEMU interface:
>+ * + Unnamed GPIO output: set to 1 if the PCI Device has asserted its irq
>+ */
>+
> static const TypeInfo pci_device_type_info = {
>     .name = TYPE_PCI_DEVICE,
>     .parent = TYPE_DEVICE,


  reply	other threads:[~2023-05-11 21:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-11  8:57 [RFC PATCH 00/18] PCI: convert IRQs to use qdev gpios Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 01/18] hw/pci: add device IRQ to PCIDevice Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 02/18] hw/pci: introduce PCI bus input IRQs Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 03/18] hw/pci: use PCIDevice gpio for device IRQ Mark Cave-Ayland
2023-05-11 21:44   ` Bernhard Beschow [this message]
2023-05-12  5:51     ` Michael S. Tsirkin
2023-05-12  8:58       ` Mark Cave-Ayland
2023-05-12  8:15     ` Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 04/18] hw/pci: introduce PCI device input gpio Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 05/18] hw/char/serial-pci.c: switch SerialState to use " Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 06/18] hw/ide/ich.c: switch AHCIState " Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 07/18] hw/net/can/can_mioe3680_pci.c: switch Mioe3680PCIState " Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 08/18] hw/net/can/can_pcm3680_pci.c: switch SerialState " Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 09/18] hw/net/can/ctucan_pci.c: switch CtuCanPCIState " Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 10/18] hw/net/ne2000-pci.c: switch NE2000State " Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 11/18] hw/net/pcnet-pci.c: switch PCIPCNetState " Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 12/18] hw/net/tulip.c: switch TULIPState " Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 13/18] hw/scsi/esp-pci.c: switch ESPState " Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 14/18] hw/sd/sdhci-pci.c: switch SDHCIState " Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 15/18] hw/usb/hcd-ehci-pci.c: switch EHCIState " Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 16/18] hw/usb/hcd-ohci-pci.c: switch OHCIState " Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 17/18] hw/usb/hcd-uhci.c: switch UHCIState " Mark Cave-Ayland
2023-05-11  8:57 ` [RFC PATCH 18/18] hw/pci/pci.c: remove pci_allocate_irq() Mark Cave-Ayland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C77CADEE-2FB5-4928-A9F2-8ECD2643CFF2@gmail.com \
    --to=shentey@gmail.com \
    --cc=alex.bennee@linaro.org \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=mst@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).