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? > 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. Cheers, -Kevin
