Seeking clarification on PMP behavior when R=0, W=1


Bill Huffman
 

I believe the proposed change is not backward compatible.  An implementation that writes the reserved combinations but faults all accesses to the region changes from legal to illegal, right?

 

      Bill

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Andrew Waterman
Sent: Monday, June 7, 2021 4:56 AM
To: Allen Baum <allen.baum@...>
Cc: James Robinson <jrobinson@...>; tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Seeking clarification on PMP behavior when R=0, W=1

 

EXTERNAL MAIL

That sounds familiar, but perhaps we never actually acted upon it.  This time, I've made a PR here: https://github.com/riscv/riscv-isa-manual/pull/658

 

On Sun, Jun 6, 2021 at 5:45 PM Allen Baum <allen.baum@...> wrote:

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.


Xinhao (Freddie) Qu
 

To clarify, I didn’t mean WARL – you can’t do this to the page tables. But will combining the 3 bits into 1 single field make any sense?

 

Regards,

Freddie

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Xinhao (Freddie) Qu via lists.riscv.org
Sent: Monday, June 7, 2021 11:29 AM
To: Allen Baum <allen.baum@...>; James Robinson <jrobinson@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Seeking clarification on PMP behavior when R=0, W=1

 

On a related thought, should the same be applied to the PTE’s RWX bits?

 

Regards,

Freddie

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Allen Baum
Sent: Monday, June 7, 2021 1:46 AM
To: James Robinson <jrobinson@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Seeking clarification on PMP behavior when R=0, W=1

 

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.


Xinhao (Freddie) Qu
 

On a related thought, should the same be applied to the PTE’s RWX bits?

 

Regards,

Freddie

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Allen Baum
Sent: Monday, June 7, 2021 1:46 AM
To: James Robinson <jrobinson@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Seeking clarification on PMP behavior when R=0, W=1

 

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.


Andrew Waterman
 

That sounds familiar, but perhaps we never actually acted upon it.  This time, I've made a PR here: https://github.com/riscv/riscv-isa-manual/pull/658


On Sun, Jun 6, 2021 at 5:45 PM Allen Baum <allen.baum@...> wrote:
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.


Allen Baum
 

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.


James Robinson
 

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.


Andrew Waterman
 

This is indeed a pretty vague statement, but Spike certainly isn't violating it.  (I also know that several HW implementations do exactly what Spike is doing here.)

A more precise statement would be that RWX are collectively a WARL field, with 000, 001, 100, 101, 110, 111 being the valid combinations.  Then (from the definition of WARL) it would be legal to translate 011 into either 000 (which you prefer) or 001 (which is a popular choice).

On Fri, Jun 4, 2021 at 5:42 AM James Robinson <jrobinson@...> wrote:
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


James Robinson
 

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