On 06/03/2015 05:20 AM, Laszlo Ersek wrote:
> After sleeping on it:), I'd certainly like to find the time to
> collaborate on this myself. Maybe we can experiment some more; for
> example we could start by you explaining to me how exactly to probe for
> a root bus's presence (you mentioned device 0, but I'll need more than
> that).
>
> For the bus range allocation, here's an idea:
> - create a bitmap with 256 bits (32 bytes) with all bits zero
> - probe all root buses; whatever is found, flip its bit to 1
> - assuming N root buses were found, divide the number of remaining zero
> bits with N. The quotient Q means how many subordinate buses each root
> bus would be able to accommodate
> - for each root bus:
> - create an ACPI bus range descriptor that includes only the root
> bus's number
> - pull out Q zero bits from the bitmap, from the left, flipping them
> to one as you proceed
> - for each zero bit pulled, try to append that bus number to the ACPI
> bus range descriptor (simply bumping the end). If there's a
> discontinuity, start a new ACPI bus range descriptor.
>
> This greedy algorithm would grant each root bus the same number of
> possible subordinate buses, could be implemented in linear time, and
> would keep the individual bus ranges "reasonably continuous" (ie. there
> should be a reasonably low number of ACPI bus range descriptors, per
> root bus).
In the interest of keeping things simple, "real hardware"
implementations I'm aware of usually determine root bus range
assignments statically, by platform-specific means (often setup
screens.) But it's certainly platform-specific, so whatever makes sense
for OVMF is fine.
If QEMU supports it, I'd strongly encourage you guys to add support for
multiple PCIe segments (multiple, possibly discontiguous 256-bus ranges)
from the beginning. Segment support doesn't show up in a lot BIOSes, so
a lot of code gets written assuming a single segment. That makes it
hard for those of us with multi-segment hardware to port it to our
platforms. :)
>
> What do you think? This wouldn't be a very hard patch to write, and then
> we could experiment with various -device pxb,bus_nr=xxx parameters.
>
> The MMIO and IO spaces I would just share between all of them; the
> allocations from those are delegated back to the host bridge / root
> bridge driver, and the current implementation seems sufficient -- it
> just assings blocks from the same big MMIO ( / IO) space downwards.
Thanks,
--
Brian J. Johnson
--------------------------------------------------------------------
My statements are my own, are not authorized by SGI, and do not
necessarily represent SGI’s positions.
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
