Hi Andrew, Just one thought, this change introduces a bank of context saving registers that could also be re-used/applied for additional purposes such as a lightweight TEE-OS (where we are looking

Hi, We're submitting for your consideration an extension for resumable non-maskable interrupt (RNMI) support. You might recall that the current non-maskable interrupt support defined in the M-mode

Not all OSes require or desire VM address mapping, especially in the embedded space (or so I've been led to believe) - yet they still need some level of privilege protection layering. That's where

Out of curiosity, what's the point of supporting S-mode if not to use paged virtual memory? My understanding of things was that S-mode provides virtual memory, a secondary level of interrupt/exception

Note: I'm not sure if the TG's email list is up yet. If not, check with the Security HC.

Jeff; FYI. SPMP TG is awaiting final approval from Technical Steering Commitee. Regards, Manuel Offenberg Seagate Research From: tech-privileged@... <tech-privileged@...> on behalf of Jeff Scott

Hi Greg, In our world we don’t have MMU, just PMP. The inability to supply separate permissions to S and U limits the usefulness of PMP in our environment. I subscribed to SPMP now. I’ll

PMP was architected to be a mechanism to protect M-mode software and resources from non-M-mode software and devices. This complements the MMU which serves to protect and isolate between S-mode and

Hello, I am curious why the PMP treats S and U mode accesses identically? Is anyone aware of a standard extension that allows for different permissions for S and U? Thanks, Jeff

It seems like you have dropped a bunch of text from the prior versions - which is probably part of what leads to some of my questions below. Maybe better to say "The Svpbmt32 extension allows the

Hi all, Here is the third version of the proposal. V2: https://lists.riscv.org/g/tech-privileged/message/1079 V1: https://lists.riscv.org/g/tech-privileged/message/1051 This posting to this

Thank you all for the valuable input! In summary, it is possible to have virtual memory pages that straddle multiple PMA and PMP regions. There are simplifications or implementation decisions that can

>For TLBs, the important simplification is PMP/PMA aren't <4KiB in >granularity, as then existing TLB entires can be used to cache >permissions. Yes - this makes a lot of sense. What about the case

>For TLBs, the important simplification is PMP/PMA aren't <4KiB in >granularity, as then existing TLB entires can be used to cache >permissions. Yes - this makes a lot of sense. What about the case

|| In particular, a portion of a misaligned store that passes the PMP check may become visible, even if another portion fails the PMP check | I had no idea this was in the spec - so I'm glad you added

>In particular, a portion of a misaligned store that passes the PMP check may become visible, even if another portion fails the PMP check I had no idea this was in the spec - so I'm glad you added

There are at least 3 potential boundaries: MMU pages, PMP regions, and PMA regions. All bytes of an access must be contained within a single PMP region. The operative word there is "access", because a

The ACTs will test that bits above b38 match b38 if SV39 is enabled Likewise for SV48 and SV 57. There is no SV64 yet, so any VA bits above b56 that don't match b56 are expected to always trap. If a

That could be ok for accesses to idempotent memory, but would likely be problematic for a non-idempotent location (e.g. a memory-mapped I/O register), and byte accesses to a word MMIO register might

It would be nice if it was architecturally defined/permitted for such straddling accesses to be performed a byte at a time. That makes the trap and emulate handler easier to code. If not a byte at a