riscv-non-isa/server-soc

Question regarding PCI Enhanced Allocation

Closed this issue · 4 comments

I'm wondering why this spec allows Enhanced Allocation, where the ARM SBSA specifically excludes its use in level 4 compliant systems (RS_L4PCI_2). I looked for discussion of this topic in the archives and didn't see any. I see two similarly purposed industry specifications with different requirements on this topic, and I'd like to understand our reasoning.

We had a discussion on this topic in issue #22 . Could you please point to the two industry specification? The only reference should be to the PCIe Gen 6.
Update: I see you are perhaps referring to SBSA as the other specification. The reasoning is that the SBSA made a very broad statement that takes away some of the key value that the PCIe Gen 6 provides with EA. With EA RCiEP design can achieve hardware simplification and added security by not needing relocatable BARs. The SBSA may have made a broad statement likely due to some problematic uses of the EA capability which this specification avoids by the constraints that a) BEI values must be specified as 0-5 or 9-14 b) Primary/secondary property must be one of 00, 01, 03, 04, or FF.

Thanks - I didn't find that issue with my searches.
The industry specifications I was referring to were this one ROSCV server SOC spec, and the ARM SBSA. Both are describing requirements for server SoCs, and I wanted to understand how different conclusions where reached.

I guess as a related topic, since EA seems to be unpopular in practice, is how other silicon vendors deal with on-chip "PCIe" devices. Are these usually assignable to arbitrary addresses as a PCIe device would be? The few x86 systems I have looked at seem to indicate that they do have configurable addresses, as neither EA nor the ACPI "_DSM(5)" method of describing fixed (or set by firmware) addresses are used.

I realized that was what you were referring to and made an update to my post.

I would not say its unpopular. Its use for the unpopular case i.e. associating resources for root ports is disallowed by this specification. So this specification is retaining the aspects of the specification that provide meaningful benefits for the SoC and is supported by open source OSs and as issue 22 notes also by vmware.