| Deutsch English Français Italiano |
|
<fcaa9301fe9800a1aab0c4fddd0a7323@www.novabbs.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: Stacks, was Segments Date: Sat, 15 Feb 2025 23:28:28 +0000 Organization: Rocksolid Light Message-ID: <fcaa9301fe9800a1aab0c4fddd0a7323@www.novabbs.org> References: <vdlgl9$3kq50$2@dont-email.me> <H5upP.2$72m1.1@fx11.iad> <4a1eb52bbccf3c20554ac8016bb7f97e@www.novabbs.org> <0atqP.430$EyH6.259@fx45.iad> <fb334c4df427a76f8c12c8f2312a9022@www.novabbs.org> <fOIqP.674411$iNI.193453@fx14.iad> <fc735aa8a75233ef89a789a8ab8d92bc@www.novabbs.org> <oJOqP.674414$iNI.243253@fx14.iad> <968818239db4609805e5375d6aa814bd@www.novabbs.org> <6673961f57b047ec5ade59bf8d03c016@www.novabbs.org> <k9NrP.11363$z8ke.7319@fx15.iad> <73648ac951e13922bb386a8805e88d28@www.novabbs.org> <Ar2sP.919$wlqe.720@fx06.iad> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="228337"; mail-complaints-to="usenet@i2pn2.org"; posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU"; User-Agent: Rocksolid Light X-Rslight-Site: $2y$10$org1QZToFbuc1JbehyNQUuIfTiD8i2SuqI/diRC8kaUsdnaQTtw7a X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71 X-Spam-Checker-Version: SpamAssassin 4.0.0 Bytes: 4630 Lines: 71 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.