Creating a new thread, for a new topic, although I'm excerpting some old
email as inspiration.

Anyway: Andrew Waterman tells me that 1 of the big purposes of M-mode is
to emulate instructions.

For example, a hardware implementation may not implement misaligned memory
accesses. But these can trap to M mode, which can emulate.

Q: doesn't MML, M-mode lockdown, preventing M-mode from reading or
writing, interfere with such emulation? At least in the cases where the
M-mode code needs to actually perform memory accesses on behalf of the
code that it is emulating.

My apologies if this is already been discussed. I mentioned this to Andrew
a week or so ago, meant to post to this list, but I want to read all the
history before I embarrass myself. That hasn't happened, so I just want to
send this email and risk embarrassing myself and wasting your time if you
have already discussed this.

I can't resist a meta-observation: M-mode is going the way of Intel SMM.
There are too many different uses, which should be indifferent privileged
domains, that are being crammed into the single M-mode privileged level.

-----Original Message-----
From: tech-privileged@... <tech-privileged@...> On
Behalf Of John Hauser
Sent: Wednesday, February 19, 2020 14:29
To: tech-tee@...; tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] comments on PMP enhancements

... 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.