We should use a language that is unambiguous. RFC 2119 is well established in the software industry. I am not aware of a better alternative. For sure it makes sense to reference this RFC in out

If that is indeed the case, that we should be using wording according to RFC 2119, then this specification or the policy should be updated to specifically say that.

%s/are/shall be/ Having M-mode does not protect anything. It is something the platform must implement, e.g. via MMU configuration. We should use the wording according to RFC

The platform spec has been changed so the mandate of PMP and how many are not there any longer for targeting binary portability for the purposes of the OS. That said, the original requirement noted in

Actually, you point out one more possible difference: "PMP matching needs a priority decoder by definition of the spec to match the lowest entry. The server extension in the platform spec is

I had exactly the same question: hardwiring anything reduces validation effort, it doesn't increase it. Also "There is no way, in the positive, to declare a region as M-mode only. That would be the

I'm not yet understanding the validation concerns? An implementation is free to hardwire all the unneeded registers and functionality (thus removing most all of the useless area and power), and one

I tried to describe the situation here: https://lists.riscv.org/g/tech-unixplatformspec/message/1393 We have power and performance concerns. Also if one goes down the ePMP (same is true for PMP) path

Hi All, The meeting minutes for this meeting are uploaded to our usual location on platform wiki here https://github.com/riscv/riscv-platform-specs/wiki/2021.11.01:-Working-Group-Meeting

If this new proposal can be entirely subsumed in ePMP, then—while comparing software (firmware) complexity—we must also consider the added cost (for the ecosystem and particularly the software

I disagree that the specification provides standardization of U and VU modes. At best it provides a small and incomplete set of requirements for those modes.

Looks good to me. I notice that a few other sections have interspersed M-mode requirements that could be similarly addressed. A few additional related comments inline. 1. Table 1 - columns with

This version of the platform specification doesn't mandate M-mode requirements. However, it should specify M-mode access protection from lower privilege modes for platforms that do implement

As per the discussion in the mailing list, M-mode requirements should not be included in this version of the platform specification to allow platform vendors more flexibility in implementing

My issue here is that I'm still not seeing what this does that the proposed ePMP definition doesn't already do. What I heard is that it's too expensive or too complex, but that's a bit vague. Could

Hi All, The next platform HSC meeting is scheduled on Mon Nov 1st 2021 at 8AM PST. Here are the details: Agenda and minutes kept on the github

On 15/10/21, 2:34 PM, "tech-unixplatformspec@... on behalf of Andrew Jones" <tech-unixplatformspec@... on behalf of drjones@...> wrote: Will the watchdog timer

Some system designers will feel that way and others won't. The spec doesn't try to get into the business of telling a system designer how to incorporate and use it in their system. These choices are

The output signal from the watchdog can be (but doesn't have to be) treated as an interrupt request signal. That choice (and more generally where the signal goes to) are implementation and/or

Even the first-stage timeout would probably be more useful to the OS if it was a "non-maskable interrupt" or otherwise able to arrive even with sstatus.SIE bit unset. If the system has locked up to