Re: [Qemu-devel] [PATCH V2] pci: fixes to allow booting from extra root pci buses.

[Kevin O'Connor]

On Fri, Jun 12, 2015 at 11:25:50AM +0200, Laszlo Ersek wrote:
> 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?

Coreboot does not provide information on what to boot.  It's task is
low level hardware initialization.  It's the job of SeaBIOS to boot
the OS (and determine which media, etc to boot from).  SeaBIOS gets
boot preference information from a static configuration file
(bootorder) stored in flash (cbfs).

> 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"?

We currently go to great lengths to avoid logical identifiers in
bootorder and I'm confused why we would wish to add them now.  Bus
number is not currently used anywhere in bootorder because (in the
general case) it's an arbitrary identifier that's not stable between
boots and (in the general case) may not be stable even within a boot.

I understand that in this specific case (extra root buses on QEMU) it
is stable within a boot, but it seems strange that we'd want to define
the interface knowing it's a poor choice in the general case.

As for what I would suggest - well, SeaBIOS has already supported
multiple root buses for years and already has a mechanism for
deterministically specifying a device on an extra root bus.  (By
specifying the N'th extra root bus instead of specifying the logical
id given to that bus).  This is by no means a perfect solution and
it's certainly open to change - but the current proposed patches
appear to be regressions to me.

> Could we simply make this patch conditional on runningOnQEMU()?

It's possible.  I'd certainly prefer to avoid adding special cases if
possible.

-Kevin