Re: [Qemu-devel] [PATCH v4 for-2.3 13/25] hw/acpi: remove from root bus 0 the crs resources used by other busses.

[Marcel Apfelbaum]

On 03/08/2015 08:26 PM, Kevin O'Connor wrote:
> On Sun, Mar 08, 2015 at 07:51:42PM +0200, Marcel Apfelbaum wrote:
> > On 03/08/2015 06:13 PM, Kevin O'Connor wrote:
> > > If I read this correctly, it looks like a machine with two root buses
> > > and 20 devices, each with one memory range and one io range, would end
> > > up with 40 CRS ranges (ie, a CRS range for every resource).
> > Correct.
> >
> > As Michael pointed out in another thread, the firmware is considered
> > guest code and QEMU cannot assume anything on how the resources are
> > assigned. This is why this solution was chosen.
> >
> > However we have two things that make the situation a little better.
> > 1. The PXB implementation includes a pci-bridge and all devices are 
> > automatically
> >     attached to the secondary bus, in this way we have one IO/MEM range per 
> > extra root bus.
>
> Out of curiosity, does the PXB implementation add the pci-bridge just
> to simplify the IO/MEM range, or are there other technical reasons for
> it?
We have another elephant there :) -> pci hotplug.
All the "free" memory ranges are assigned to bus 0, this will leave
the pxb buses without the hotplug capability.
Using a PCI bridge will give us some IO/MEM ranges for hotplug: the ones created
because of minimum requirement by PCI spec and not used currently by any 
devices.

> > 2. On top of this series we can add a merge algorithm that will bring together
> >     consecutive ranges. This series does not include this optimization and it
> >     focuses on the correctness.
> >
> >    It also
> > > looks like this furthers the requirement that the guest firmware
> > > assign the PCI resources prior to QEMU being able to generate the ACPI
> > > tables.
> > >
> > > Am I correct?  If so, that doesn't sound ideal.
> > You are correct, however is not that bad because we have the following sequence:
> >   - Early in the boot sequence the bios scans the PCI buses and assigns IO/MEM 
> > ranges
> >   - At this moment all resources needed by QEMU are present in the 
> > configuration space.
> >   - At the end of the boot sequence the BIOS queries the ACPI tables and *only 
> > then*
> >     the tables are computed.
> >
> > I think we use that implicitly for other features, anyway, it looks like an 
> > elegant
> > solution with no real drawbacks. (Our assumptions are safe)
>
> Thank you for the clarification.  I understand that it works, but I've
> never been that comfortable with the QEMU<->firmware dance with PCI
> resources.  I do understand that the alternatives have as many or more
> problems though.  So, I'm not objecting to this implementation.
No problem, thank you and your review is much appreciated as always,
Marcel

> Cheers,
> -Kevin