Re: Stacks, was Segments

On Sat, 15 Feb 2025 15:31:44 +0000, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

-----------

PCI supports two forms of configuration space addresses in TLPs:
   Type 0 contains only a function number and the register address.
   Type 1 contains the bus number, function number and register address.

>
PCIe segments go where ? Are they "picked off" prior to being routed
down the tree ??

>
Logically, they can be considered a prefix to the RID for routing
purposes (inbound to the IOMMU, for example, the PCIE controller
will prepend its segment number to the RID and use that as an
ID to the IOMMU).   ARM calls it a streamid.
>
For PCI configuration transactions initiated by the CPU,
"PCIe segments go where?" is an interesting question.

Indeed. Snipping Intel brain damage
-----------------------

PCI Express has been designed as a point-to-point protocol
using serial connections rather than the wide PCI local
bus, which changes the topology of the system.   With PCIe
the device number in the RID -must be zero- (unless the
BUS is an ARI bus,

What is an ARI bus, and do non x86 systems have them ??

                   in which case bits <7:0> of the RID
are a function number provided by the PCIe device (up
to 256 functions per each - more with SRIOV as it can
consume additional space in the bus <15:8> field of the
RID to support up to 65535 virtual functions on a single
device).  A non-SRIOV and non-ARI device can only provide
from one to eight functions.

snipping

The specification allows the implementation to provide a single ECAM
segment per PCIe controller, or and implementation may provide a single
ECAM region and used bits <63:28> as a segment number.

Wikipedia states ECAM contains 42 bits::
16-bit segment, 8-bit bus, 5-bit device, 3-bit function, 4-bit
xReg, and 6-bit reg. Is this wrong, misleading, of out of date ?

                                                      This is how
most non-intel systems handle this today; an processors that supports
six PCIe controllers would have perhaps 7 segments (one or more for the
root bus 0 for the on-chip devices such as memory controllers, and
one for each PCIe controller.
>
Software simply constructs the target ECAM address and issues normal
loads and stores to access it - no need to use the clumsy, slow and
non-standard PCI peek-and-poke configuration space accesses.

We still have to translate 'target ECAM' into a bit pattern matching
that device's BAR. And thinks to your help I have a means to do so
that has overhead only when Booting a new Guest OS.

For outbound memory space (non-config space) transactions from the CPU
to
the device, the RID is not used - once the CPU I/O fabric has routed
the request by PA to the proper PCIe controller (address based routing
through a heirarchy of host bridges), it is simply sent to the device
which CAMs the address against the programmed bars and reacts
appropriately
(e.g. by responding with a UR (Unsupported Request) on a non-posted
request or dropping a posted request if it doesn't match a BAR).

Agreed.