PMP as an option for supervisor domain isolation

[NicholasWoodIMG]

Add PMP as an option for supervisor domain isolation:

• Add PMP as a mode in table 3.1
• When PMP mode is used, then MTT is not required and PMP is used instead for physical memory isolation between domains
• When PMP mode is used, the SDID CSR can still be used to identify the currently active supervisor domain

This allows systems based on PMP or MTT as the underlying physical memory isolation mechanism to implement and support supervisor domains in a consistent way across the RVI architecture.

[jackwdandrew]

Additionally, when only PMP and Bare modes are supported, mttp.MTTPN is redundant. Therefore an implementation that can tie it to 0. Probably calling mttp.MTTPN out as WARL is sufficient.

[rsahita]

Makes sense. Sub-fields of that CSR are already specified as WARL.

from 9-19 discussion - Krste's comment - will need to use SFENCE to flush TLBs with any PMP settings changes

[kasanovic]

To clarify, if we did add SDID we may be able to provide more targeted SFENCE versions to reduce the microarchitectural translation/protection cache flushing when PMP entries are swapped.

[NicholasWoodIMG]

Thanks. That looks like it would be useful. Could we address that here in this document?

Another useful extension to PMP for supervisor domains would be to allow “switchable” PMP configurations indexed by SDID to avoid PMP reconfiguration on context switch.

Edit: Essentially a mechanism supporting different PMP configurations per SDID, similar to how MTT supports different MTT configurations per SDID. This could probably be done as an extension for supervisor domains without changing the PMP spec?

From: Krste Asanovic @.> Sent: Tuesday, September 19, 2023 3:28 PM To: riscv/riscv-smmtt @.> Cc: Nicholas Wood @.>; Author @.> Subject: [EXTERNAL] Re: [riscv/riscv-smmtt] PMP as an option for supervisor domain isolation (Issue #3)

CAUTION: This email originates from a source not known to Imagination Technologies. Think before you click a link or open an attachment

To clarify, if we did add SDID we may be able to provide more targeted SFENCE versions to reduce the microarchitectural translation/protection cache flushing when PMP entries are swapped.

— Reply to this email directly, view it on GitHub [github.com]https://urldefense.com/v3/__https:/github.com/riscv/riscv-smmtt/issues/3*issuecomment-1725752431__;Iw!!KCwjcDI!28fKTSaUYBS90BRBH7v8KfmKhKE4dpiBDAyhN-dBiKjmWhcFh7b0O_e2_y9I7ivLPV5AXT7bg5FyLryWSnfMi1viungv$, or unsubscribe [github.com]https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/BB6NFPZNPFXQKDNF4MXZYQDX3GTYNANCNFSM6AAAAAA3SJE724__;!!KCwjcDI!28fKTSaUYBS90BRBH7v8KfmKhKE4dpiBDAyhN-dBiKjmWhcFh7b0O_e2_y9I7ivLPV5AXT7bg5FyLryWSnfMixXpCUHC$. You are receiving this because you authored the thread.Message ID: @.***>

[rsahita]

For the Supervisor Domains spec - adding an "option" to the SDID configuration with no MTT is the only requirement here (normative). We need to add the basic theory of operation (informative) for this mode of operation that (e)PMPs may be used here instead.

The design for any changes to (e)PMP for SDID is to be done separately from this spec. That design should cover - partitioning/switching, design tradeoffs, optimal flushing etc., access-control masks on (e)PMPs etc.

[rsahita]

Eckhard: Do we also need an informative section for the "no-MTT" Scenario where IOPMP is used for Access Control (instead of IOMMU-MTT)?

[NicholasWoodIMG]

Table 2. Encoding of mttMODE field:

5|"No MTT"|Supervisor domain isolation not using MTT for physical memory isolation, for example (e)PMP.

---

Rationale (in the intro section of the doc?):

"The Smmtt extension defines an SDID CSR, and a physical memory isolation mechanism for access control rules across domain boundaries.

The SDID can be used by the Risc-V architecture to provide domain isolation guarantees beyond memory isolation. For example interrupt management, performance counters and debug controls.

For memory access control, the Smmtt specification introduces MTT. MTT enables fine grained (page level) dynamic memory allocation.

Other memory access control mechanisms can also be used to enforce supervisor domain boundaries for use cases that do not require the full flexibility of MTT. For example, (e)PMP configurations controlled by M-mode during domain context switching. In this case the "No MTT" mode is used. The same security guarantees are provided to supervisor domains, and the SDID CSR is still valid. Only MTT is not used."

[gagachang]

Hi If Smmtt also supports M-mode only or M/U mode systems, where S-mode is absent, adding some description or diagrams for those use cases is helpful to people.

[rsahita]

Moved @gagachang's comment to separate issue.

Opened PR to address this issue.

[rsahita]

addressed by #19