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 handling beneath M-mode (which can already handle interrupts and exceptions by itself), and nothing else. I also understood that S-mode had restricted access to the machine's hardware mainly to support virtualization---the idea is that it uses an interface that's designed to be easily intercepted (per the Popek-Goldberg rules on virtualization). I also assume (which may be wrong) that MMU-less systems are MMU-less because they can't afford the transistors and power, so I would not expect them to run hypervisors.

So if the problem is "PMP doesn't distinguish between S-mode and U-mode" my reflexive solution would be "Run your supervisor in M-mode, which has the added benefit of giving it direct access to the PMP registers."

Apparently there is enough demand for supervisor-mode PMPs that there's an SMPU task group and an Ssmpu spec in the works at https://github.com/riscv/riscv-tee/blob/main/Ssmpu/Ssmpu.pdf . But all the spec provides for motivation is that "it is desirable to enable S-mode OS to limit the physical addresseses accessible by U-mode software." Figure 1 in that document says that the M-mode monitor sits below the S-mode "MPU virtualization," but... why? Is the purpose to allow hypervisors to manage MPU entries? Is there more than that? And if so, why are people running hypervisors on systems that can't afford paged memory? I'm sorry if this is derailing the purpose of this discussion thread, but I'm genuinely curious.

Regards,
Anthony