[PATCH v2 0/3] Decouple INTx-to-LNKx routing from south bridges

[PATCH v2 0/3] Decouple INTx-to-LNKx routing from south bridges

[Bernhard Beschow]

v1:
===

During my PIIX consolidation work [1] I've noticed that both PIIX models have
quite different pci_slot_get_pirq() implementations. These functions seem to
map PCI INTx pins to input pins of a programmable interrupt router which is
AFAIU board-specific. IOW, board-specific assumptions are baked into the device
models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC
machine.

This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which
then allowes for moving the two board-specific PIIX pci_slot_get_pirq()
funtions into their respective boards. With these changes, the PIIX4 south
bridge could eventually become an alternative to the PIIX3-Frankenstein
solution in the PC machine.

v2:
===
* Remove RFC tag from whole series
* New patch to split pci_bus_irqs()
* Remove VT82xx patch which was just a demonstration

Testing done:
* `make check`
* `make check-avocado`
* `qemu-system-mips64el -M malta -kernel vmlinux-3.2.0-4-5kc-malta -hda debian_wheezy_mipsel_standard.qcow2 -append "root=/dev/sda1 console=ttyS0"`
* `qemu-system-x86_64 -M pc -m 2G -cdrom manjaro-kde-21.3.2-220704-linux515.iso`

Thanks,
Bernhard

[1] https://lists.nongnu.org/archive/html/qemu-devel/2022-10/msg03941.html

Bernhard Beschow (3):
  hw/pci/pci: Factor out pci_bus_map_irqs() from pci_bus_irqs()
  hw/isa/piix3: Decouple INTx-to-LNKx routing which is board-specific
  hw/isa/piix4: Decouple INTx-to-LNKx routing which is board-specific

 hw/i386/pc_piix.c       | 16 ++++++++++++++++
 hw/i386/pc_q35.c        |  4 ++--
 hw/isa/piix3.c          | 17 ++---------------
 hw/isa/piix4.c          | 27 +--------------------------
 hw/mips/malta.c         | 28 ++++++++++++++++++++++++++++
 hw/pci-host/raven.c     |  3 ++-
 hw/pci-host/versatile.c |  3 ++-
 hw/pci/pci.c            | 12 +++++++++---
 hw/remote/machine.c     |  3 ++-
 include/hw/pci/pci.h    |  3 ++-
 10 files changed, 66 insertions(+), 50 deletions(-)

-- 
2.38.1

[PATCH v2 1/3] hw/pci/pci: Factor out pci_bus_map_irqs() from pci_bus_irqs()

[Bernhard Beschow]

pci_bus_irqs() coupled together the assignment of pci_set_irq_fn and
pci_map_irq_fn to a PCI bus. This coupling gets in the way when the
pci_map_irq_fn is board-specific while the pci_set_irq_fn is device-
specific.

For example, both of QEMU's PIIX south bridge models have different
pci_map_irq_fn implementations which are board-specific rather than
device-specific. These implementations should therefore reside in board
code. The pci_set_irq_fn's, however, should stay in the device models
because they access memory internal to the model.

Factoring out pci_bus_map_irqs() from pci_bus_irqs() allows the
assignments to be decoupled, resolving the problem described above.

Note also how pci_vpb_realize() which gets touched in this commit
assigns different pci_map_irq_fn's depending on the board.

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
---
 hw/i386/pc_q35.c        |  4 ++--
 hw/isa/piix3.c          |  8 ++++----
 hw/isa/piix4.c          |  3 ++-
 hw/pci-host/raven.c     |  3 ++-
 hw/pci-host/versatile.c |  3 ++-
 hw/pci/pci.c            | 12 +++++++++---
 hw/remote/machine.c     |  3 ++-
 include/hw/pci/pci.h    |  3 ++-
 8 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index a496bd6e74..39f035903c 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -268,8 +268,8 @@ static void pc_q35_init(MachineState *machine)
     for (i = 0; i < GSI_NUM_PINS; i++) {
         qdev_connect_gpio_out_named(lpc_dev, ICH9_GPIO_GSI, i, x86ms->gsi[i]);
     }
-    pci_bus_irqs(host_bus, ich9_lpc_set_irq, ich9_lpc_map_irq, ich9_lpc,
-                 ICH9_LPC_NB_PIRQS);
+    pci_bus_irqs(host_bus, ich9_lpc_set_irq, ich9_lpc, ICH9_LPC_NB_PIRQS);
+    pci_bus_map_irqs(host_bus, ich9_lpc_map_irq);
     pci_bus_set_route_irq_fn(host_bus, ich9_route_intx_pin_to_irq);
     isa_bus = ich9_lpc->isa_bus;
 
diff --git a/hw/isa/piix3.c b/hw/isa/piix3.c
index f9b4af5c05..7ad26b82e8 100644
--- a/hw/isa/piix3.c
+++ b/hw/isa/piix3.c
@@ -388,8 +388,8 @@ static void piix3_realize(PCIDevice *dev, Error **errp)
         return;
     }
 
-    pci_bus_irqs(pci_bus, piix3_set_irq, pci_slot_get_pirq,
-                 piix3, PIIX_NUM_PIRQS);
+    pci_bus_irqs(pci_bus, piix3_set_irq, piix3, PIIX_NUM_PIRQS);
+    pci_bus_map_irqs(pci_bus, pci_slot_get_pirq);
     pci_bus_set_route_irq_fn(pci_bus, piix3_route_intx_pin_to_irq);
 }
 
@@ -424,8 +424,8 @@ static void piix3_xen_realize(PCIDevice *dev, Error **errp)
      * connected to the IOAPIC directly.
      * These additional routes can be discovered through ACPI.
      */
-    pci_bus_irqs(pci_bus, xen_piix3_set_irq, xen_pci_slot_get_pirq,
-                 piix3, XEN_PIIX_NUM_PIRQS);
+    pci_bus_irqs(pci_bus, xen_piix3_set_irq, piix3, XEN_PIIX_NUM_PIRQS);
+    pci_bus_map_irqs(pci_bus, xen_pci_slot_get_pirq);
 }
 
 static void piix3_xen_class_init(ObjectClass *klass, void *data)
diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
index 8fc1db6dc9..f9211d085f 100644
--- a/hw/isa/piix4.c
+++ b/hw/isa/piix4.c
@@ -271,7 +271,8 @@ static void piix4_realize(PCIDevice *dev, Error **errp)
     }
     qdev_connect_gpio_out(DEVICE(&s->pm), 0, s->isa[9]);
 
-    pci_bus_irqs(pci_bus, piix4_set_irq, pci_slot_get_pirq, s, PIIX_NUM_PIRQS);
+    pci_bus_irqs(pci_bus, piix4_set_irq, s, PIIX_NUM_PIRQS);
+    pci_bus_map_irqs(pci_bus, pci_slot_get_pirq);
 }
 
 static void piix4_init(Object *obj)
diff --git a/hw/pci-host/raven.c b/hw/pci-host/raven.c
index 7a105e4a63..2db577df4f 100644
--- a/hw/pci-host/raven.c
+++ b/hw/pci-host/raven.c
@@ -258,7 +258,8 @@ static void raven_pcihost_realizefn(DeviceState *d, Error **errp)
 
     qdev_init_gpio_in(d, raven_change_gpio, 1);
 
-    pci_bus_irqs(&s->pci_bus, raven_set_irq, raven_map_irq, s, PCI_NUM_PINS);
+    pci_bus_irqs(&s->pci_bus, raven_set_irq, s, PCI_NUM_PINS);
+    pci_bus_map_irqs(&s->pci_bus, raven_map_irq);
 
     memory_region_init_io(&h->conf_mem, OBJECT(h), &pci_host_conf_le_ops, s,
                           "pci-conf-idx", 4);
diff --git a/hw/pci-host/versatile.c b/hw/pci-host/versatile.c
index f66384fa02..c77a999955 100644
--- a/hw/pci-host/versatile.c
+++ b/hw/pci-host/versatile.c
@@ -422,7 +422,8 @@ static void pci_vpb_realize(DeviceState *dev, Error **errp)
         mapfn = pci_vpb_map_irq;
     }
 
-    pci_bus_irqs(&s->pci_bus, pci_vpb_set_irq, mapfn, s->irq, 4);
+    pci_bus_irqs(&s->pci_bus, pci_vpb_set_irq, s->irq, 4);
+    pci_bus_map_irqs(&s->pci_bus, mapfn);
 
     /* Our memory regions are:
      * 0 : our control registers
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 2f450f6a72..6396cde004 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -283,6 +283,7 @@ static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int change)
     PCIBus *bus;
     for (;;) {
         bus = pci_get_bus(pci_dev);
+        assert(bus->map_irq);
         irq_num = bus->map_irq(pci_dev, irq_num);
         if (bus->set_irq)
             break;
@@ -521,16 +522,20 @@ void pci_root_bus_cleanup(PCIBus *bus)
     qbus_unrealize(BUS(bus));
 }
 
-void pci_bus_irqs(PCIBus *bus, pci_set_irq_fn set_irq, pci_map_irq_fn map_irq,
+void pci_bus_irqs(PCIBus *bus, pci_set_irq_fn set_irq,
                   void *irq_opaque, int nirq)
 {
     bus->set_irq = set_irq;
-    bus->map_irq = map_irq;
     bus->irq_opaque = irq_opaque;
     bus->nirq = nirq;
     bus->irq_count = g_malloc0(nirq * sizeof(bus->irq_count[0]));
 }
 
+void pci_bus_map_irqs(PCIBus *bus, pci_map_irq_fn map_irq)
+{
+    bus->map_irq = map_irq;
+}
+
 void pci_bus_irqs_cleanup(PCIBus *bus)
 {
     bus->set_irq = NULL;
@@ -552,7 +557,8 @@ PCIBus *pci_register_root_bus(DeviceState *parent, const char *name,
 
     bus = pci_root_bus_new(parent, name, address_space_mem,
                            address_space_io, devfn_min, typename);
-    pci_bus_irqs(bus, set_irq, map_irq, irq_opaque, nirq);
+    pci_bus_irqs(bus, set_irq, irq_opaque, nirq);
+    pci_bus_map_irqs(bus, map_irq);
     return bus;
 }
 
diff --git a/hw/remote/machine.c b/hw/remote/machine.c
index 75d550daae..519f855ec1 100644
--- a/hw/remote/machine.c
+++ b/hw/remote/machine.c
@@ -63,8 +63,9 @@ static void remote_machine_init(MachineState *machine)
     } else {
         remote_iohub_init(&s->iohub);
 
-        pci_bus_irqs(pci_host->bus, remote_iohub_set_irq, remote_iohub_map_irq,
+        pci_bus_irqs(pci_host->bus, remote_iohub_set_irq,
                      &s->iohub, REMOTE_IOHUB_NB_PIRQS);
+        pci_bus_map_irqs(pci_host->bus, remote_iohub_map_irq);
     }
 
     qbus_set_hotplug_handler(BUS(pci_host->bus), OBJECT(s));
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 6ccaaf5154..01ea267253 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -446,8 +446,9 @@ PCIBus *pci_root_bus_new(DeviceState *parent, const char *name,
                          MemoryRegion *address_space_io,
                          uint8_t devfn_min, const char *typename);
 void pci_root_bus_cleanup(PCIBus *bus);
-void pci_bus_irqs(PCIBus *bus, pci_set_irq_fn set_irq, pci_map_irq_fn map_irq,
+void pci_bus_irqs(PCIBus *bus, pci_set_irq_fn set_irq,
                   void *irq_opaque, int nirq);
+void pci_bus_map_irqs(PCIBus *bus, pci_map_irq_fn map_irq);
 void pci_bus_irqs_cleanup(PCIBus *bus);
 int pci_bus_get_irq_level(PCIBus *bus, int irq_num);
 /* 0 <= pin <= 3 0 = INTA, 1 = INTB, 2 = INTC, 3 = INTD */
-- 
2.38.1

[PATCH v2 2/3] hw/isa/piix3: Decouple INTx-to-LNKx routing which is board-specific

[Bernhard Beschow]

pci_map_irq_fn's in general seem to be board-specific. So move PIIX3's
pci_slot_get_pirq() to board code to not have PIIX3 make assuptions
about its board.

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
---
 hw/i386/pc_piix.c | 16 ++++++++++++++++
 hw/isa/piix3.c    | 13 -------------
 2 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 0ad0ed1603..ecae85a31e 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -47,6 +47,7 @@
 #include "hw/sysbus.h"
 #include "hw/i2c/smbus_eeprom.h"
 #include "hw/xen/xen-x86.h"
+#include "hw/xen/xen.h"
 #include "exec/memory.h"
 #include "hw/acpi/acpi.h"
 #include "hw/acpi/piix4.h"
@@ -73,6 +74,17 @@ static const int ide_iobase2[MAX_IDE_BUS] = { 0x3f6, 0x376 };
 static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
 #endif
 
+/*
+ * Return the global irq number corresponding to a given device irq
+ * pin. We could also use the bus number to have a more precise mapping.
+ */
+static int pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
+{
+    int slot_addend;
+    slot_addend = PCI_SLOT(pci_dev->devfn) - 1;
+    return (pci_intx + slot_addend) & 3;
+}
+
 /* PC hardware initialisation */
 static void pc_init1(MachineState *machine,
                      const char *host_type, const char *pci_type)
@@ -223,6 +235,10 @@ static void pc_init1(MachineState *machine,
         piix3->pic = x86ms->gsi;
         piix3_devfn = piix3->dev.devfn;
         isa_bus = ISA_BUS(qdev_get_child_bus(DEVICE(piix3), "isa.0"));
+
+        pci_bus_map_irqs(pci_bus,
+                         xen_enabled() ? xen_pci_slot_get_pirq
+                                       : pci_slot_get_pirq);
     } else {
         pci_bus = NULL;
         isa_bus = isa_bus_new(NULL, get_system_memory(), system_io,
diff --git a/hw/isa/piix3.c b/hw/isa/piix3.c
index 7ad26b82e8..30509f39e5 100644
--- a/hw/isa/piix3.c
+++ b/hw/isa/piix3.c
@@ -79,17 +79,6 @@ static void piix3_set_irq(void *opaque, int pirq, int level)
     piix3_set_irq_level(piix3, pirq, level);
 }
 
-/*
- * Return the global irq number corresponding to a given device irq
- * pin. We could also use the bus number to have a more precise mapping.
- */
-static int pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
-{
-    int slot_addend;
-    slot_addend = PCI_SLOT(pci_dev->devfn) - 1;
-    return (pci_intx + slot_addend) & 3;
-}
-
 static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pin)
 {
     PIIX3State *piix3 = opaque;
@@ -389,7 +378,6 @@ static void piix3_realize(PCIDevice *dev, Error **errp)
     }
 
     pci_bus_irqs(pci_bus, piix3_set_irq, piix3, PIIX_NUM_PIRQS);
-    pci_bus_map_irqs(pci_bus, pci_slot_get_pirq);
     pci_bus_set_route_irq_fn(pci_bus, piix3_route_intx_pin_to_irq);
 }
 
@@ -425,7 +413,6 @@ static void piix3_xen_realize(PCIDevice *dev, Error **errp)
      * These additional routes can be discovered through ACPI.
      */
     pci_bus_irqs(pci_bus, xen_piix3_set_irq, piix3, XEN_PIIX_NUM_PIRQS);
-    pci_bus_map_irqs(pci_bus, xen_pci_slot_get_pirq);
 }
 
 static void piix3_xen_class_init(ObjectClass *klass, void *data)
-- 
2.38.1

[PATCH v2 3/3] hw/isa/piix4: Decouple INTx-to-LNKx routing which is board-specific

[Bernhard Beschow]

pci_map_irq_fn's in general seem to be board-specific, and PIIX4's
pci_slot_get_pirq() in particular seems very Malta-specific. So move the
latter to malta.c to 1/ keep the board logic in one place and 2/ avoid
PIIX4 to make assumptions about its board.

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
---
 hw/isa/piix4.c  | 26 --------------------------
 hw/mips/malta.c | 28 ++++++++++++++++++++++++++++
 2 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
index f9211d085f..eca96fb8f0 100644
--- a/hw/isa/piix4.c
+++ b/hw/isa/piix4.c
@@ -79,31 +79,6 @@ static void piix4_set_irq(void *opaque, int irq_num, int level)
     }
 }
 
-static int pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
-{
-    int slot;
-
-    slot = PCI_SLOT(pci_dev->devfn);
-
-    switch (slot) {
-    /* PIIX4 USB */
-    case 10:
-        return 3;
-    /* AMD 79C973 Ethernet */
-    case 11:
-        return 1;
-    /* Crystal 4281 Sound */
-    case 12:
-        return 2;
-    /* PCI slot 1 to 4 */
-    case 18 ... 21:
-        return ((slot - 18) + irq_num) & 0x03;
-    /* Unknown device, don't do any translation */
-    default:
-        return irq_num;
-    }
-}
-
 static void piix4_isa_reset(DeviceState *dev)
 {
     PIIX4State *d = PIIX4_PCI_DEVICE(dev);
@@ -272,7 +247,6 @@ static void piix4_realize(PCIDevice *dev, Error **errp)
     qdev_connect_gpio_out(DEVICE(&s->pm), 0, s->isa[9]);
 
     pci_bus_irqs(pci_bus, piix4_set_irq, s, PIIX_NUM_PIRQS);
-    pci_bus_map_irqs(pci_bus, pci_slot_get_pirq);
 }
 
 static void piix4_init(Object *obj)
diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index c0a2e0ab04..e435f80973 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -39,6 +39,7 @@
 #include "hw/mips/bootloader.h"
 #include "hw/mips/cpudevs.h"
 #include "hw/pci/pci.h"
+#include "hw/pci/pci_bus.h"
 #include "qemu/log.h"
 #include "hw/mips/bios.h"
 #include "hw/ide/pci.h"
@@ -1140,6 +1141,31 @@ static void malta_mips_config(MIPSCPU *cpu)
     }
 }
 
+static int pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
+{
+    int slot;
+
+    slot = PCI_SLOT(pci_dev->devfn);
+
+    switch (slot) {
+    /* PIIX4 USB */
+    case 10:
+        return 3;
+    /* AMD 79C973 Ethernet */
+    case 11:
+        return 1;
+    /* Crystal 4281 Sound */
+    case 12:
+        return 2;
+    /* PCI slot 1 to 4 */
+    case 18 ... 21:
+        return ((slot - 18) + irq_num) & 0x03;
+    /* Unknown device, don't do any translation */
+    default:
+        return irq_num;
+    }
+}
+
 static void main_cpu_reset(void *opaque)
 {
     MIPSCPU *cpu = opaque;
@@ -1411,6 +1437,8 @@ void mips_malta_init(MachineState *machine)
     /* Interrupt controller */
     qdev_connect_gpio_out_named(DEVICE(piix4), "intr", 0, i8259_irq);
 
+    pci_bus_map_irqs(pci_bus, pci_slot_get_pirq);
+
     /* generate SPD EEPROM data */
     dev = DEVICE(object_resolve_path_component(OBJECT(piix4), "pm"));
     smbus = I2C_BUS(qdev_get_child_bus(dev, "i2c"));
-- 
2.38.1

Re: [PATCH v2 0/3] Decouple INTx-to-LNKx routing from south bridges

[Philippe Mathieu-Daudé]

On 20/11/22 16:05, Bernhard Beschow wrote:
> v1:
> ===
> 
> During my PIIX consolidation work [1] I've noticed that both PIIX models have
> quite different pci_slot_get_pirq() implementations. These functions seem to
> map PCI INTx pins to input pins of a programmable interrupt router which is
> AFAIU board-specific. IOW, board-specific assumptions are baked into the device
> models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC
> machine.
> 
> This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which
> then allowes for moving the two board-specific PIIX pci_slot_get_pirq()
> funtions into their respective boards. With these changes, the PIIX4 south
> bridge could eventually become an alternative to the PIIX3-Frankenstein
> solution in the PC machine.

Series:
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [PATCH v2 0/3] Decouple INTx-to-LNKx routing from south bridges

[Bernhard Beschow]

Am 9. Dezember 2022 15:23:59 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>:
>On 20/11/22 16:05, Bernhard Beschow wrote:
>> v1:
>> ===
>> 
>> During my PIIX consolidation work [1] I've noticed that both PIIX models have
>> quite different pci_slot_get_pirq() implementations. These functions seem to
>> map PCI INTx pins to input pins of a programmable interrupt router which is
>> AFAIU board-specific. IOW, board-specific assumptions are baked into the device
>> models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC
>> machine.
>> 
>> This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which
>> then allowes for moving the two board-specific PIIX pci_slot_get_pirq()
>> funtions into their respective boards. With these changes, the PIIX4 south
>> bridge could eventually become an alternative to the PIIX3-Frankenstein
>> solution in the PC machine.
>
>Series:
>Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Ping

Who will pull this?

Re: [PATCH v2 0/3] Decouple INTx-to-LNKx routing from south bridges

[Michael S. Tsirkin]

On Sun, Dec 18, 2022 at 10:21:49AM +0000, Bernhard Beschow wrote:
> 
> 
> Am 9. Dezember 2022 15:23:59 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>:
> >On 20/11/22 16:05, Bernhard Beschow wrote:
> >> v1:
> >> ===
> >> 
> >> During my PIIX consolidation work [1] I've noticed that both PIIX models have
> >> quite different pci_slot_get_pirq() implementations. These functions seem to
> >> map PCI INTx pins to input pins of a programmable interrupt router which is
> >> AFAIU board-specific. IOW, board-specific assumptions are baked into the device
> >> models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC
> >> machine.
> >> 
> >> This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which
> >> then allowes for moving the two board-specific PIIX pci_slot_get_pirq()
> >> funtions into their respective boards. With these changes, the PIIX4 south
> >> bridge could eventually become an alternative to the PIIX3-Frankenstein
> >> solution in the PC machine.
> >
> >Series:
> >Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> 
> Ping
> 
> Who will pull this?

I'll merge this, thanks!

Re: [PATCH v2 0/3] Decouple INTx-to-LNKx routing from south bridges

[Michael S. Tsirkin]

On Sun, Dec 18, 2022 at 10:21:49AM +0000, Bernhard Beschow wrote:
> 
> 
> Am 9. Dezember 2022 15:23:59 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>:
> >On 20/11/22 16:05, Bernhard Beschow wrote:
> >> v1:
> >> ===
> >> 
> >> During my PIIX consolidation work [1] I've noticed that both PIIX models have
> >> quite different pci_slot_get_pirq() implementations. These functions seem to
> >> map PCI INTx pins to input pins of a programmable interrupt router which is
> >> AFAIU board-specific. IOW, board-specific assumptions are baked into the device
> >> models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC
> >> machine.
> >> 
> >> This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which
> >> then allowes for moving the two board-specific PIIX pci_slot_get_pirq()
> >> funtions into their respective boards. With these changes, the PIIX4 south
> >> bridge could eventually become an alternative to the PIIX3-Frankenstein
> >> solution in the PC machine.
> >
> >Series:
> >Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> 
> Ping
> 
> Who will pull this?

To clarify, you want this dropped for now?

-- 
MST

Re: [PATCH v2 0/3] Decouple INTx-to-LNKx routing from south bridges

[Bernhard Beschow]

Am 20. Dezember 2022 23:10:45 UTC schrieb "Michael S. Tsirkin" <mst@redhat.com>:
>On Sun, Dec 18, 2022 at 10:21:49AM +0000, Bernhard Beschow wrote:
>> 
>> 
>> Am 9. Dezember 2022 15:23:59 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>:
>> >On 20/11/22 16:05, Bernhard Beschow wrote:
>> >> v1:
>> >> ===
>> >> 
>> >> During my PIIX consolidation work [1] I've noticed that both PIIX models have
>> >> quite different pci_slot_get_pirq() implementations. These functions seem to
>> >> map PCI INTx pins to input pins of a programmable interrupt router which is
>> >> AFAIU board-specific. IOW, board-specific assumptions are baked into the device
>> >> models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC
>> >> machine.
>> >> 
>> >> This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which
>> >> then allowes for moving the two board-specific PIIX pci_slot_get_pirq()
>> >> funtions into their respective boards. With these changes, the PIIX4 south
>> >> bridge could eventually become an alternative to the PIIX3-Frankenstein
>> >> solution in the PC machine.
>> >
>> >Series:
>> >Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>> 
>> Ping
>> 
>> Who will pull this?
>
>To clarify, you want this dropped for now?

Yeah, let's merge via mips-next since this series is related to the PIIX consolidation series (see above) and mips-next is planned to be pulled soon.

Thanks,
Bernhard

Re: [PATCH v2 0/3] Decouple INTx-to-LNKx routing from south bridges

[Michael S. Tsirkin]

On Tue, Dec 20, 2022 at 11:26:42PM +0000, Bernhard Beschow wrote:
> 
> 
> Am 20. Dezember 2022 23:10:45 UTC schrieb "Michael S. Tsirkin" <mst@redhat.com>:
> >On Sun, Dec 18, 2022 at 10:21:49AM +0000, Bernhard Beschow wrote:
> >> 
> >> 
> >> Am 9. Dezember 2022 15:23:59 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>:
> >> >On 20/11/22 16:05, Bernhard Beschow wrote:
> >> >> v1:
> >> >> ===
> >> >> 
> >> >> During my PIIX consolidation work [1] I've noticed that both PIIX models have
> >> >> quite different pci_slot_get_pirq() implementations. These functions seem to
> >> >> map PCI INTx pins to input pins of a programmable interrupt router which is
> >> >> AFAIU board-specific. IOW, board-specific assumptions are baked into the device
> >> >> models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC
> >> >> machine.
> >> >> 
> >> >> This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which
> >> >> then allowes for moving the two board-specific PIIX pci_slot_get_pirq()
> >> >> funtions into their respective boards. With these changes, the PIIX4 south
> >> >> bridge could eventually become an alternative to the PIIX3-Frankenstein
> >> >> solution in the PC machine.
> >> >
> >> >Series:
> >> >Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> >> 
> >> Ping
> >> 
> >> Who will pull this?
> >
> >To clarify, you want this dropped for now?
> 
> Yeah, let's merge via mips-next since this series is related to the PIIX consolidation series (see above) and mips-next is planned to be pulled soon.
> 
> Thanks,
> Bernhard


For that

Acked-by: Michael S. Tsirkin <mst@redhat.com>

Re: [PATCH v2 0/3] Decouple INTx-to-LNKx routing from south bridges

[Michael S. Tsirkin]

On Sun, Nov 20, 2022 at 04:05:47PM +0100, Bernhard Beschow wrote:
> v1:
> ===
> 
> During my PIIX consolidation work [1] I've noticed that both PIIX models have
> quite different pci_slot_get_pirq() implementations. These functions seem to
> map PCI INTx pins to input pins of a programmable interrupt router which is
> AFAIU board-specific. IOW, board-specific assumptions are baked into the device
> models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC
> machine.
> 
> This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which
> then allowes for moving the two board-specific PIIX pci_slot_get_pirq()
> funtions into their respective boards. With these changes, the PIIX4 south
> bridge could eventually become an alternative to the PIIX3-Frankenstein
> solution in the PC machine.


Reviewed-by: Michael S. Tsirkin <mst@redhat.com>

> v2:
> ===
> * Remove RFC tag from whole series
> * New patch to split pci_bus_irqs()
> * Remove VT82xx patch which was just a demonstration
> 
> Testing done:
> * `make check`
> * `make check-avocado`
> * `qemu-system-mips64el -M malta -kernel vmlinux-3.2.0-4-5kc-malta -hda debian_wheezy_mipsel_standard.qcow2 -append "root=/dev/sda1 console=ttyS0"`
> * `qemu-system-x86_64 -M pc -m 2G -cdrom manjaro-kde-21.3.2-220704-linux515.iso`
> 
> Thanks,
> Bernhard
> 
> [1] https://lists.nongnu.org/archive/html/qemu-devel/2022-10/msg03941.html
> 
> Bernhard Beschow (3):
>   hw/pci/pci: Factor out pci_bus_map_irqs() from pci_bus_irqs()
>   hw/isa/piix3: Decouple INTx-to-LNKx routing which is board-specific
>   hw/isa/piix4: Decouple INTx-to-LNKx routing which is board-specific
> 
>  hw/i386/pc_piix.c       | 16 ++++++++++++++++
>  hw/i386/pc_q35.c        |  4 ++--
>  hw/isa/piix3.c          | 17 ++---------------
>  hw/isa/piix4.c          | 27 +--------------------------
>  hw/mips/malta.c         | 28 ++++++++++++++++++++++++++++
>  hw/pci-host/raven.c     |  3 ++-
>  hw/pci-host/versatile.c |  3 ++-
>  hw/pci/pci.c            | 12 +++++++++---
>  hw/remote/machine.c     |  3 ++-
>  include/hw/pci/pci.h    |  3 ++-
>  10 files changed, 66 insertions(+), 50 deletions(-)
> 
> -- 
> 2.38.1
> 

Re: [PATCH v2 0/3] Decouple INTx-to-LNKx routing from south bridges

[Philippe Mathieu-Daudé]

On 20/11/22 16:05, Bernhard Beschow wrote:

> Bernhard Beschow (3):
>    hw/pci/pci: Factor out pci_bus_map_irqs() from pci_bus_irqs()
>    hw/isa/piix3: Decouple INTx-to-LNKx routing which is board-specific
>    hw/isa/piix4: Decouple INTx-to-LNKx routing which is board-specific

Thanks, series queued to mips-next.