From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUtIz-0008PO-6H for qemu-devel@nongnu.org; Mon, 09 Mar 2015 04:44:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YUtIv-0005Kn-Ul for qemu-devel@nongnu.org; Mon, 09 Mar 2015 04:44:53 -0400 Date: Mon, 9 Mar 2015 09:44:24 +0100 From: "Michael S. Tsirkin" Message-ID: <20150309084424.GA22591@redhat.com> References: <1425813387-31231-1-git-send-email-marcel@redhat.com> <1425813387-31231-14-git-send-email-marcel@redhat.com> <20150308161340.GA11259@morn.localdomain> <20150308183434.GA13128@redhat.com> <20150308184628.GA20711@morn.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150308184628.GA20711@morn.localdomain> 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: kraxel@redhat.com, quintela@redhat.com, seabios@seabios.org, qemu-devel@nongnu.org, agraf@suse.de, amit.shah@redhat.com, alex.williamson@redhat.com, qemu-ppc@nongnu.org, hare@suse.de, stefanha@redhat.com, imammedo@redhat.com, Marcel Apfelbaum , pbonzini@redhat.com, leon.alrae@imgtec.com, aurelien@aurel32.net, rth@twiddle.net On Sun, Mar 08, 2015 at 02:46:28PM -0400, Kevin O'Connor wrote: > On Sun, Mar 08, 2015 at 07:34:34PM +0100, Michael S. Tsirkin wrote: > > On Sun, Mar 08, 2015 at 12:13:40PM -0400, 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). > > > > I think that's only if you stick multiple devices directly behind the > > bridge. Looks like with a single pci bridge behind root, there will > > only be 2 ranges. > > Yeah, that makes sense, so doesn't seem to be a problem. > > > Maybe try to enforce this sane topology? > > > > > 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. > > > > That seems unavoidable unless we want to assign ranges from > > hardware/management. > > Which I think would be a mistake: management doesn't really know, > > or care. > > I understand. I think what would help me is if we could document > somewhere that the firmware has to assign PCI resources before > querying the bios tables and that it is the *only* pre-requisite for > querying them. Looking now, though, I don't see any fw_cfg > documentation in the repo, so I'm not sure where that could be added. > > Thanks, > -Kevin Sigh. Might make a GSoC project? -- MST