I wrote:

First, as we all know, the existing PMP standard allows PMP entries to
be locked, with the clear intention of denying access to M mode.

Allen Baum:

You need to be careful with terminology. I am assuming that
"denying access to Mmode" means
"denying the ability of M-mode to change an entry" , and not
"denying access to the region defined by an entry".

Sorry, I meant that, under the existing standard, locked PMP entries
are intended to deny some or all accesses from M mode to a memory
region. The RISC-V standard says, "In addition to locking the PMP
entry, the L bit indicates whether the R/W/X permissions are enforced
on M-mode accesses." The only reason the entry is locked is so that
M mode can't then undo this restriction imposed on it.

But: if an entry is created (necessarily by M-mode) that is locked and such
that M-mode can no longer touch that region but S/U mode can - that is
either intentional or that M-mode code is buggy, in my opinion.

Such an entry is impossible under the existing standard. There's no
way to encode it.

And, even
if that happens, M-mode code code always define an unlocked region of
higher priority (unless it has allocated all the higher priority regions).

As I said to Jonathan Behrens, locked regions always have to be at the
head of the table to be effective. Ordinarily, there won't be any
unlocked regions of higher priority.

It feels like you've misunderstood the role of locked PMP entries under
the existing standard, and that's why you didn't understand my point.
Or you missed the significance I intended with my words "the existing
PMP standard allows ...."

Regards,

- John Hauser