On Fr, 2015-06-12 at 09:23 -0400, Kevin O'Connor wrote:
On Fri, Jun 12, 2015 at 03:17:27PM +0300, Marcel Apfelbaum wrote:
On 06/12/2015 09:00 AM, Gerd Hoffmann wrote:
On each boot, coreboot might decide to assign a different bus id to the extra roots (for example, if a device with a PCI bridge is inserted and it's bus allocation causes bus ids to shift). Technically, coreboot could even change the order extra buses are assigned bus ids, but doesn't today.
This was seen on several AMD systems - I'm told at least some Intel systems have multiple root buses, but the bus numbers are just hard wired.
This is how the qemu pxb works: root bus numbers are a config option for the root bridge device, i.e. from the guest point of view they are hard-wired.
Exactly. In our case, the HW assigns the PXB bus bumber, and again, I saw this also on real HW with multiple buses, the bus nr comes from ACPI, meaning the vendor.
I'm confused where ACPI comes into this. In all cases I know of, the firmware generates the ACPI tables to match the hardware. I've never heard of hardware configuring itself from the ACPI tables.
We have basically the same model in qemu, except that it isn't the firmware but qemu generating the tables (and qemu looks at the registers programmed by the firmware to make sure things match).
The pxb has no registers to program, the hardware just shows up on a bus number (qemu cfg, hard-wired for the guest). ACPI must specify it so the guest OS finds it. When passing bus numbers via fw_cfg the must match acpi of course.
I'm wondering whenever things become easier if we add config registers to the pxb, where the firmware can program the bus number range and we can use the config register base as a way to specify which pxb we are referring to ?
cheers, Gerd