Now PCI bridges get a bus range number on a system init, basing on currently plugged devices. That's why when one wants to hotplug another bridge, it needs his child bus, which the parent is unable to provide (speaking about virtual device). The suggested workaround is to have vendor-specific capability in Red Hat PCI bridges that contains number of additional bus to reserve on BIOS PCI init. So this capability is intented only for pure QEMU->SeaBIOS usage.
Considering all aforesaid, this series is directly connected with QEMU RFC series (v2) "Generic PCIE-PCI Bridge".
Although the new PCI capability is supposed to contain various limits along with bus number to reserve, now only its full layout is proposed, but only bus_reserve field is used in QEMU and BIOS. Limits usage is still a subject for implementation as now the main goal of this series to provide necessary support from the firmware side to PCIE-PCI bridge hotplug.
Changes v1->v2: 1. New #define for Red Hat vendor added (addresses Konrad's comment). 2. Refactored pci_find_capability function (addresses Marcel's comment). 3. Capability reworked: - data type added; - reserve space in a structure for IO, memory and prefetchable memory limits.
Aleksandr Bezzubikov (4): pci: refactor pci_find_capapibilty to get bdf as the first argument instead of the whole pci_device pci: add RedHat vendor ID pci: add QEMU-specific PCI capability structure pci: enable RedHat PCI bridges to reserve additional buses on PCI init
src/fw/pciinit.c | 18 ++++++++++++++---- src/hw/pci_cap.h | 23 +++++++++++++++++++++++ src/hw/pci_ids.h | 2 ++ src/hw/pcidevice.c | 12 ++++++------ src/hw/pcidevice.h | 2 +- src/hw/virtio-pci.c | 4 ++-- 6 files changed, 48 insertions(+), 13 deletions(-) create mode 100644 src/hw/pci_cap.h