Re: [RFC PATCH 1/1] server extension: PCIe requirements

Greg Favor

On Mon, Jun 14, 2021 at 2:28 PM Josh Scheid <jscheid@...> wrote:
+For security reasons, platforms are required to provide a mechanism to
+restrict the inbound accesses over PCIe to certain specific regions in
+the address space such as the DRAM.

While a standard IOMMU is further off, is the current opinion that the IOPMP is not in a position to be required or suggested as an implementation of the above requirement?  If not, then it's hard to check for compliance.

I'm not sure if an IOPMP could be used for this particular purpose, but more generally IOPMP is being driven by embedded people and isn't consciously thinking about functionality requirements implied by H-style virtualization, or PCIe MSIs, or other PCIe features.  In this regard IOPMP is analogous to PLIC and CLIC - and not generally suitable for OS/A platforms (and presumably is well-suited for M platforms).
Is this mechanism expected to be M-mode SW controlled, or is it also expected to be controlled by S-mode (either directly or via SBI)?

IOPMP has continued to evolve significantly, so I only casually/loosely watch what's going on.  But they don't appear to be thinking much yet about this aspect (unless they started in the past couple of weeks).  Although at a hardware level the flexibility is probably there for control by either since IOPMP registers will presumably be memory-mapped.


Join to automatically receive all group messages.