On 06/11/15 21:24, Kevin O'Connor wrote:
On Thu, Jun 11, 2015 at 08:34:56PM +0200, Laszlo Ersek wrote:
On 06/11/15 19:46, Marcel Apfelbaum wrote:
On 06/11/2015 07:54 PM, Kevin O'Connor wrote:
On real machines, the firmware assigns the 4 - it's not a physical address; it's a logical address (like all bus numbers in PCI). The firmware might assign a totally different number on the next boot.
Now I am confused. Don't get me wrong, I am not an expert on fw, I hardly try to understand it.
I looked up a real hardware machine and it seemed to me that the extra pci root numbers are provided in the ACPI tables, meaning by the vendor, not the fw. In this case QEMU is the vendor, i440fx is the machine, right?
I am not aware that Seabios/OVMF are deciding the bus numbers for the *PCI roots*. They are doing it for the pci-2-pci bridges of course. I saw that Seabios is trying to "guess" the root-buses by going over all the 0-0xff range and probing all the slots, looking for devices. So it expects the hw to be hardwired regarding PCI root buses.
This is exactly how I understood it.
We're not interested in placing such bus numbers in device paths that are assigned during PCI enumeration. (Like subordinate bus numbers.) We're talking about the root bus numbers.
OVMF implements the same kind of probing that SeaBIOS does (based on natural language description from Michael and Marcel, not on the actual code). Devices on the root buses respond without any prior bus number assignments.
Alas, that is not correct. Coreboot supports several AMD boards that have multiple southbridge chips which provide independent PCI root buses. These chips have to be configured and assigned a bus number prior to use (which coreboot does).
Thanks.
Assuming such a physical hardware configuration, and that Coreboot configures the root buses before the SeaBIOS payload is launched: how does Coreboot identify a device, on a nonzero root bus, for SeaBIOS to boot from? Is that possible at all, or is the user expected to configure / select that in SeaBIOS exclusively?
Our use case does not include Coreboot (as far as I can tell), but I'm trying to find some parallels here.
* In the "QEMU without Coreboot" case, QEMU is the component that sets up the root buses for the firmware. Therefore it has all knowledge about the root buses. OVMF is meant solely for QEMU "hardware", therefore it has a full understanding with QEMU. QEMU can refer to root buses in the "bootorder" fw_cfg file because it owns both the root buses and the "bootorder" fw_cfg file, and OVMF can trust them to match.
* In the "physical hardware with Coreboot" case, Coreboot is the component that sets up the root buses for the firmware (SeaBIOS). Coreboot *could* refer to the root buses in some boot order file (a cbfs file I guess?) -- if such a feature existed between Coreboot and SeaBIOS -- because Coreboot would own both the root buses and the (theoretical) cbfs boot order file. Hence SeaBIOS could trust them to match.
Assuming there is no such feature between Coreboot and SeaBIOS (ie. one that would parallel our QEMU use case on physical hardware), what solution would you find acceptable for the case when QEMU basically promises "I know where you'll find those root buses, and the bootorder fw_cfg file will match them"?
Could we simply make this patch conditional on runningOnQEMU()?
Thanks Laszlo