SID_080: RCiEP MAY support the PCIe enhanced allocation (EA) capability for fixed allocation of memory resources.
andreiw opened this issue · 5 comments
Is there a benefit to allowing this? EA is not really an industry-accepted practice in the server space. I am aware of it only being used by Cavium ThunderX CN88xx processors and subsequent Cavium/Marvell Octeon Si. Handling EA is a corner case with respect to PCIe resource handling, pass-through, etc and not all OSes support EA.
There is benefit in allowing this capability. This is a standard PCIe capability supported in PCIe Gen 6. The EA capability supports providing memory resources for PF and VFs. For integrated devices which are not plug-n-play and don't need their resources resized/moved this provides a simple and convenient integration option.
How is OS support for EA? It's hardly typical. I've implemented EA in ESXi but this was limited to the subset exercised by Cavium silicon - ie. no resources without a BEI, no W (non HWInit) resources and my understanding is that it's seen no adoption in Windows, so if I were a Si vendor aiming for most compatibility, I'd avoid EA unless I had a really good reason.
Can we restrict the subset of EA? E.g. avoid 'W'(ritable) entries, avoid entries without a BEI, avoid bridge resources (IIRC the Cavium implementation had switches without any resources, as if they were subtractive). It's unclear that anyone implementing EA today won't run into massive OS support investment.
So PCIe already disallows writable entries (Table 7-150) for except for types reserved for future use.
I suggest adding the following restrictions:
- BEI values must be specified as 0-5 or 9-14
- Primary/secondary property must be one of 00, 01, 03, 04, or FF.
That sounds reasonable!