100 MHz is way more than sufficient for carrying out a Spectre attack. Web browsers limit clock resolutions to 1 kHz or even 500 Hz to disrupt those sorts of attacks (and apply other mitigations as

The intent of the wording is that the resolution is 10ns (as implied by the max update frequency of 100 MHz). But I agree that the current wording should change to just directly state a 10ns

The resolution of the mtime register is defined as 10 ns. The 100 MHz value is irrelevant and should be deleted from the spec. (You could check if an mtime increment is needed at a 10 GHz rate.

I have a question about this requirement: "The ACLINT MTIME update frequency (i.e. hardware clock) must be between 10 MHz and 100 MHz, and updates must be strictly monotonic." I do understand

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

Sure. I will update the patch. I was talking about the CMO (cache management operations) CSRs. Here are the

Agree that adding a clarification that these are "required" only if supporting SW interrupts or other interrupts to M-mode is supported. Else the specification reads as if these are always

Table 1 merely states the information rather than requirement. For example: If category 3 (MSIs and Wired IRQs) is used, MSIs at M-mode can be provided using IMSIC while wired interrupts at M-mode

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