On 07/07/2026 09:42, Philippe Mathieu-Daudé wrote:
On 6/7/26 23:19, Philippe Mathieu-Daudé wrote:
On 6/7/26 23:16, Mark Cave-Ayland wrote:
On 06/07/2026 21:29, Philippe Mathieu-Daudé wrote:
- pci_bus = PCI_HOST_BRIDGE(sabre)->bus;
pci_busA = pci_bridge_get_sec_bus(sabre->bridgeA);
pci_busB = pci_bridge_get_sec_bus(sabre->bridgeB);
- /* Only in-built Simba APBs can exist on the root bus, slot 0 on busA is
- reserved (leaving no slots free after on-board devices) however slots
- 0-3 are free on busB */
- pci_bus_set_slot_reserved_mask(pci_bus, 0xfffffffc);
+ /*
+ * Slot 0 on busA is reserved (leaving no slots free after on- board
+ * devices) however slots 0-3 are free on busB
+ */
pci_bus_set_slot_reserved_mask(pci_busA, 0xfffffff1);
pci_bus_set_slot_reserved_mask(pci_busB, 0xfffffff0);
---
I'm still looking at the 2nd part, the reserved slots.
(Because with this patch, the test passes as we can plug devices from
the command line, but they end plugged on pciA instead of pciB -- thus
the 2nd part missing).
Thanks for taking a look, Phil. IIRC the reason I added slot_reserved_mask was so
that it was possible to populate pciA programatically in sun4uv_init(), and then
enable the mask so that specifying an additional PCI device using -device on the
command line without an explict PCI bus would cause the automatic allocation to
place the device on pciB.
The slot_reserved_mask calls make sense, but AFAICT they don't work as
expected, since CLI devices are added on pciA. If you want to have a
look on top of this snippet, be my guest! Otherwise I'll continue
debugging that tomorrow, long day and late here :\
Generic PCI fix posted here:
https://lore.kernel.org/qemu-devel/[email protected]/
Thanks Phil! I can confirm that this solves the issue for me.
ATB,
Mark.
