I would like to clarify the intended behavior of PMP regions when R=0, W=1.

The privileged spec (https://github.com/riscv/riscv-isa-manual/blob/4f83798332ad8cf9a7a752f4e9f59ce16d325c73/src/machine.tex#L3254-L3259) says:

"Figure~\ref{pmpcfg} shows the layout of a PMP configuration register. The R, W, and X bits, when set, indicate that the PMP entry permits read, write, and instruction execution, respectively.  When one of these bits is clear, the corresponding access type is denied. The combination R=0 and W=1 is reserved for future use. The remaining two fields, A and L, are described in the following sections."

I would like clarification on what "Reserved for future use" is intended to mean.

What spike does (https://github.com/riscv/riscv-isa-sim/blob/1621807a7c0dbd29f503377661a6b05930e8d365/riscv/processor.cc#L889) is to intercept csrw to the pmpcfg registers, and clear the W bit if the R bit is not set.

    cfg &= ~PMP_W | ((cfg & PMP_R) ? PMP_W : 0); // Disallow R=0 W=1

The net effect of this is that if you were to write R=0/W=1/X=0, then the field would actually contain R=0/W=0/X=0, and writes to the region would not be allowed. However if you were to write R=0/W=1/X=1 then the field would contain R=0/W=0/X=1, and fetches from the region would be allowed.

The spike behavior doesn't seem to capture the spirit of the spec statement that R=0, W=1 is reserved for future use, at least for the R=0/W=1/X=1 case.

Is the spike behavior considered correct?

Could the spec be clarified here?

On my first reading of the spec I had assumed that it should be possible to write any combination of R/W/X into the CSR, and the PMP checks would allow or deny access to the region according to the R/W/X values, with R=0/W=1 combinations being denied (analogous to R/W/X bits in page tables).

James

Thank you for the clarification. I can see now that it doesn't particularly matter which legal encoding is generated when writing the reserved value since it would be the responsibility of the software doing the write to verify that the write actually happened.

I think a small wording tweak in the spec to clarify what you just said would be helpful, i.e. that RWX are collectively a WARL field and that 010 and 011 are reserved.

I thought that I had pointed this out quite a while ago and also thought that the RWX field had been updated to be a single 3bit WARL field.

If each bit is individually a WARL field, then it is quite legal to write any value, and that a "reserved"value will be read back as exactly the value written, and the effect of that is unspecified. 

On Sat, Jun 5, 2021 at 4:23 AM James Robinson <jrobinson@...> wrote:

Thank you for the clarification. I can see now that it doesn't particularly matter which legal encoding is generated when writing the reserved value since it would be the responsibility of the software doing the write to verify that the write actually happened.

I think a small wording tweak in the spec to clarify what you just said would be helpful, i.e. that RWX are collectively a WARL field and that 010 and 011 are reserved.