-----Original Message----- From: Nico Huber nico.h@gmx.de Sent: Tuesday, March 22, 2022 7:21 AM To: coreboot@akumat.pl; coreboot@coreboot.org Subject: [coreboot] Re: Multi domain PCI resource allocation: How to deal with multiple root busses on one domain
Caution: This is an external email. Please take care when clicking links or opening attachments.
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
Think of a stack as a virtual root port which has the same decoding ability as a PCIe root port. It has a start bus number and an end bus number and it has an IO start and end address as well as a MMIO start and end address. The stacks in a system are peer root ports so if your stack bus (PCI bus) numbering is 0, 32, 64, 128, 255 then MMCFG cycles to bus 0-31 go to stack 0, while cycles to bus 32-63 go to stack 1 and so on. The last stack only sees MMCFG cycles for bus 255. So basically all the stacks can be thought of as separate host bridges each with a distinct range of decoding resources.
The stacks themselves are made up of a PCIe (and/or DMI) root ports in the device range 0-7. For stack 0 as an example which should start at bus 0, devices 0-7 will be 'internal' devices only decoded by the stack itself, and devices 8-31 (for bus 0) will be forwarded down the internal DMI link to the PCH cluster. Devices 0-3 (for SKL) on each stack (if implemented) are PCIe root ports (or the DMI to PCH cluster on stack 0) and work like you would expect. Cycles directed their b/d/f are decoded properly, type 1 cycles are checked to see if their secondary/subordinate bus ranges match in parallel with each other. Any config cycles to a stacks base bus number with device numbers 8-31 go to internally decoded 'uncore' devices like memory controllers, power control, address decoding, etc. Devices 4-7 on each stack are not (at this time) PCIe root ports and implement things like an IOAPIC for devices on that stack, memory mapping and virtualization for that stack, RAS, etc.
There are not any PCI-PCI bridges on stacks that are not implemented by devices other than 0-3, nor are there any IO/MMIO resources decoded by any devices on the stacks' first bus number beyond device 7.