Hi

Hi
 

e.g. if we got from HOB info that physical stack x has preallocated PCI buses 0x20..0x2f, io form 0x2000..0x2fff, mem 0xd0000000..0xdfffffff, mem 0x10000000000...0x1ffffffffff and there are 2 root buses 0x20 and 0x28 instead of adding one domain with "physical" stack we added two domains with "virtual" stacks:

stack x1 with virtually preallocated PCI buses 0x20..0x27, ip form 0x2000..0x27ff, mem 0xd0000000..0xd7ffffff, mem 0x10000000000...0x17fffffffff
stack x2 with virtually preallocated PCI buses 0x28..0x2f, ip form 0x2800..0x2fff, mem 0xd7000000..0xdfffffff, mem 0x18000000000...0x1ffffffffff

Each one with only one root bus without this link_list->next "complexity"

This only works if the downstream resources fit in this split virtual allocation, which you can't know before reading all downstream resources.
Especially for mem32 resources the resource allocation is already tight so I think this can get ugly.
 Today most resources are mem64 "ready" and above 4G window is big enough so using "prefer 64bit strategy" practically eliminates this tight on mem32 range

I've seen FSP allocating just enough mem32 space for buildin endpoint PCI 32bit-only resources spread over multiple root busses on the same stack (on DINO stack? No idea what that really means).
Just splitting the mem32 resources in 'half' like you suggest would break allocation, so no. The "prefer 64bit strategy" is certainly needed but not sufficient.

On 22.03.22 09:57, Mariusz Szafrański via coreboot wrote:
> e.g. if we got from HOB info that physical stack x has preallocated PCI
> buses 0x20..0x2f, io form 0x2000..0x2fff, mem 0xd0000000..0xdfffffff,
> mem 0x10000000000...0x1ffffffffff and there are 2 root buses 0x20 and
> 0x28 instead of adding one domain with "physical" stack we added two
> domains with "virtual" stacks:

 I'm still trying to learn what a "stack" comprises. I'm pretty sure most
of the problems solve themselves if we map the Intel terms to standard
and coreboot terms.

Would the following be a correct statement about stacks? A "stack"
always has dedicated I/O port and memory ranges (that don't overlap
with anything else, especially not with the ranges of other stacks)
and has one or more PCI root buses.

If so, are the PCI bus numbers separate from those of other stacks?
Or do all stacks share a single range of 0..255 PCI buses? In standard
terms, do they share a single PCI segment group?

So that is actually configurable in the hardware but currently all stacks consume a set of PCI busses on a single 0..255 PCI segment.
Those PCI busses allocated to a stack are then consumed by endpoint devices directly on the stack or by 'regular' PCI bridges on there.

sidenote: it also looks like the hardware really does not like to have PCI bridges on a IIO stack set a subordinate
value larger than the IIO stack 'MaxBus' (basically a stack-level subordinate bus?). So scanning PCI busses needs some care.
See https://review.coreboot.org/c/coreboot/+/59395

On Tue, Mar 22, 2022 at 12:21 PM Nico Huber <nico.h@gmx.de> wrote:
On 22.03.22 09:57, Mariusz Szafrański via coreboot wrote:
> e.g. if we got from HOB info that physical stack x has preallocated PCI
> buses 0x20..0x2f, io form 0x2000..0x2fff, mem 0xd0000000..0xdfffffff,
> mem 0x10000000000...0x1ffffffffff and there are 2 root buses 0x20 and
> 0x28 instead of adding one domain with "physical" stack we added two
> domains with "virtual" stacks:

I'm still trying to learn what a "stack" comprises. I'm pretty sure most
of the problems solve themselves if we map the Intel terms to standard
and coreboot terms.

Would the following be a correct statement about stacks? A "stack"
always has dedicated I/O port and memory ranges (that don't overlap
with anything else, especially not with the ranges of other stacks)
and has one or more PCI root buses.

If so, are the PCI bus numbers separate from those of other stacks?
Or do all stacks share a single range of 0..255 PCI buses? In standard
terms, do they share a single PCI segment group?

Nico
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org