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

[Gerd Hoffmann <kraxel@redhat.com>]

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