On Mon, Apr 19, 2021 at 5:05 PM Nick Kossifidis <mick@...> wrote:

Στις 2021-04-19 23:17, Bill Huffman έγραψε:
> Nick,
>
> For security reasons, PMP exceptions will almost always be handled in
> M-mode.  sPMP exceptions typically want to be handled in S-mode.  I
> don't think it ever makes sense to have the two types routed to the
> same exception code.  So that seems out to me.
>
> I don't think it ever makes sense to handle PMP access faults in
> S-mode.  It's the wrong privilege level (and S-mode can't write the
> PMP either).
>

We currently get access-fault exceptions in case anyone tries to access
a region protected with PMA or PMP, regardless of privilege mode. All
PMA and PMP faults from any mode are already routed to the same
exception codes anyway. Those exceptions are typically handled by
M-mode, and based on mstatus.MPP, firmware may forward them accordingly.
That's what OpenSBI currently does ->
https://github.com/riscv/opensbi/blob/master/lib/sbi/sbi_trap.c#L260,
and here is Linux triggering a segfault in sw upon receiving an
access-fault exception ->
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/tree/arch/riscv/kernel/traps.c?h=fixes#n102
without going though do_page_fault. I don't see why sPMP faults should
be treated any differently, we can always get an access fault with
mstatus.MPP = S/U from sPMP on M-mode and forward it to S-mode to handle
it, like we forward PMA or PMP faults originating from S/U-mode.

The requirement set by the proposal's authors was to use medeleg to
delegate sPMP faults to S-mode directly as page-faults, without going
through M-mode's trap handler as PMA/PMP access-faults do. Without MMU
support on the S-mode OS this won't work, on Linux for example
do_page_fault is only available when MMU support is enabled ->
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/tree/arch/riscv/mm/Makefile?h=fixes#n13,
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/tree/arch/riscv/kernel/entry.S?h=fixes#n449.
So to be clear, treating sPMP faults as page-faults requires the OS to
support MMU and expect page-faults, it's only possible when both sPMP
and MMU are used at the same time, and the scenario I mentioned
previously is also not covered by this approach (since the hypervisor
won't use the MMU).

That sounds like an arbitrary constraint based upon how our arch-specific Linux code is currently written.  There's nothing wrong with changing our arch-specific Linux code to be sPMP-aware in the no-MMU case.  That doesn't mean we need to compile in the do_page_fault routine and all of the MMU code that it depends on; we'd instead map the page-fault exceptions to a different subroutine for the no-MMU case.

That's why we talked about using another cause value
for sPMP. If we drop the requirement to delegate sPMP faults through
medeleg, we can just treat them as access faults and be done with it, we
won't need to change any code as well, access-faults are expected by the
OS in any case.

Regards,
Nick