[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 for-2.3 13/25] hw/acpi: remove from root bus

From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH v4 for-2.3 13/25] hw/acpi: remove from root bus 0 the crs resources used by other busses.
Date: Sun, 08 Mar 2015 20:32:35 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

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).

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

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

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 
  - 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 
    the tables are computed.

I think we use that implicitly for other features, anyway, it looks like an 
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,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]