From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52610) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUg0g-0002Am-KP for qemu-devel@nongnu.org; Sun, 08 Mar 2015 14:33:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YUg0f-0002M9-MF for qemu-devel@nongnu.org; Sun, 08 Mar 2015 14:33:06 -0400 Message-ID: <54FC95C3.3010507@redhat.com> Date: Sun, 08 Mar 2015 20:32:35 +0200 From: Marcel Apfelbaum MIME-Version: 1.0 References: <1425813387-31231-1-git-send-email-marcel@redhat.com> <1425813387-31231-14-git-send-email-marcel@redhat.com> <20150308161340.GA11259@morn.localdomain> <54FC8C2E.9000709@redhat.com> <20150308182610.GA18864@morn.localdomain> In-Reply-To: <20150308182610.GA18864@morn.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: seabios@seabios.org, kraxel@redhat.com, mst@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, agraf@suse.de, alex.williamson@redhat.com, qemu-ppc@nongnu.org, hare@suse.de, imammedo@redhat.com, amit.shah@redhat.com, pbonzini@redhat.com, leon.alrae@imgtec.com, aurelien@aurel32.net, rth@twiddle.net 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 >