On Mon, Mar 09, 2015 at 09:44:24AM +0100, Michael S. Tsirkin wrote:
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.
Sigh. Might make a GSoC project?
Documentation projects are not possible under Google Summer of Code:
If there is a coding project you are interested in mentoring, there is a project idea template to fill out here: