Why writing to hgatp.mode with an unsupported MODE value and writing to satp.mode with an unsupported MODE value behave differently？

[xt1104]

The spec explicitly states that A write to hgatp with an unsupported MODE value is not ignored as it is for satp，Why hgatp needs to be handled differently from satp？

Implementations are not required to support all MODE settings, and if satp is written with an
unsupported MODE, the entire write has no effect; no fields in satp are modified.
A write to hgatp with an unsupported MODE value is not ignored as it is for satp. Instead, the fields of
hgatp are WARL in the normal way, when so indicated.

if hgatp initialized by hardware reset， write to hgatp with an unsupported MODE value is ignored as it is for satp , Does this treatment conform to the general definition of WARL in the spec？

[aswaterman]

The key difference is that hgatp is not active while executing in HS-mode, whereas satp is active while executing in S-mode. So, to use satp's WARL property to probe the supported MODE fields, it is necessary to have stricter behavior: an errant write might affect the behavior of the very next instruction.

This is an unusual aspect of the ISA, but it is what it is.

[aswaterman]

if hgatp initialized by hardware reset， write to hgatp with an unsupported MODE value is ignored as it is for satp , Does this treatment conform to the general definition of WARL in the spec？

The spec is highlighting a different property than you are mentioning.

satp is special, in that writing an invalid MODE value causes the entire CSR write to be ignored: even writes to fields other than MODE are ignored.

The sentence you quoted from the spec is just saying that hgatp is not special. That is to say, writing an invalid MODE value adheres to the usual WARL rules, but it does not cause writes to other fields to be ignored.

[xt1104]

thanks！I have one more question with hgatp.mode = Bare，The spec explicitly states that When MODE=Bare，the remaining fields in hgatp must be set to zeros. Is it up to the software to set the remaining fields to zeros? Does the hardware need to guarantee this setting?

Table 31 shows the encodings of the MODE field when HSXLEN=32 and HSXLEN=64. When
MODE=Bare, guest physical addresses are equal to supervisor physical addresses, and there is no
further memory protection for a guest virtual machine beyond the physical memory protection
scheme described in Section 3.7. In this case, the remaining fields in hgatp must be set to zeros.

[aswaterman]

It is purely software's responsibility: "Attempting to select MODE=Bare with a nonzero pattern in the remaining fields has an UNSPECIFIED effect on the value that the remaining fields assume and an UNSPECIFIED effect on G-stage address translation and protection behavior."

[xt1104]

Thanks！

For similar registers like vsatp, is it necessary to ensure that “ When MODE=Bare，the remaining fields in hgatp must be set to zeros” ？ These are not mentioned in the spec。

so for other registers with similar requirements like mttp, are they all guaranteed by software?

No page-based memory protection beyond the physical memory
protection scheme described in Section 3.7 of the RISC-V privileged
architecture specification [3]. The remaining fields in mmpt (SDID, PPN) must
be set to zeros.

[aswaterman]

The description of vsatp is explicit about how it behaves with respect to these properties.

I agree that the definition of mmpt should be tweaked to use language similar to that of hgatp, to make it clear that it is software's responsibility to zero the fields, and that the behavior is unspecified if software fails to do so. But that spec does not live in this repo (yet); you should give feedback directly to its authors.

[rsahita]

I am synchronizing the language of mmpt with language similar to hgatp as we speak.

[aswaterman]

cool, thanks @rsahita.

[rock-ifly]

Hi, please help us to make them clear? @aswaterman @rsahita @xt1104

1. satp,
   1a）when written with satp.mode=bare,
   -- software should make sure that satp[63:0]=64'b0.
   -- Shold hardware make sure all the writting data be 64b0 when satp.mode=bare? or hart just take the satp as a WARL CSR, that is to say any data with satp.mode=Bare & (satp.asid= any value | satp.ppn=any value) can be written into the sapt. e.g, satp.mode=Bare & satp.asid=16'h5 & satp.ppn=16'h5 can be written into the satp, since "Attempting to select MODE=Bare with a nonzero pattern in the remaining fields has an UNSPECIFIED effect on the value that the remaining fields assume and an UNSPECIFIED effect on address translation and protection behavior."
   1b） when written with satp.mode=any supported mode, -- clear
   -- software can config any vaule for asid & ppn
   -- hardware just take all the configuration since mode=supported
   1c）when written with satp.mode=any UN-supported mode,
   -- software can config any vaule for asid & ppn, since software may make mistake
   -- hardware should keep the entire original value (mode, asid, and ppn) for satp, and just neglect the entire new data. That is a special kind of WARL.

2. hgatp,
   2a）when written with hgatp.mode=bare,
   -- software should make sure that hgatp[63:0]=64'b0.
   -- Shold hardware make sure all the writting data be 64b0 when hatp.mode=bare? or hart just take the hgatp as a WARL CSR, that is to say any data with hgatp.mode=Bare & (hgatp.vmid= any value | hgatp.ppn=any value) can be written into the hgapt. e.g, hgatp.mode=Bare & hgatp.vmid=14'h5 & hgatp.ppn=16'h5 can be written into hgatp, since WARL properity.
   2b） when written with hgatp.mode=any supported mode, -- clear
   -- software can config any vaule for vmid & ppn
   -- hardware just take all the configuration since mode=supported
   2c）when written with hgatp.mode=any UN-supported mode,
   -- software can config any vaule for asid & ppn, since software may make mistake
   -- what should hardware do, planA, or planB?
   planA: refresh the hatp with the new writting-data
   planB: just keep the original value
   since A write to hgatp with an unsupported MODE value is not ignored as it is for hgatp are WARL in the normal way, when so indicated. How to understand the WARL? since hgatp.mode must be one of {0,8,9,10} for read and write, while vmid and ppn can be any data? If planA is OK, data with hgapt.mode=15(not supported) hgatp.asid=16'h5 & hgatp.ppn=16'h5 is written into hgatp, what are the results for write and read operation?

3. vsatp,
   3a）when written with vsatp.mode=bare,
   -- software should make sure that vsatp[63:0]=64'b0.
   -- Shold hardware make sure all the writting data be 64b0 when vsatp.mode=bare? ,or hart just take the vsatp as a WARL CSR, that is to say any data with vsatp.mode=Bare & (vsatp.asid= any value | vsatp.ppn=any value) can be written into the vsapt. e.g, vsatp.mode=Bare & vsatp.asid=16'h5 & vsatp.ppn=16'h5 can be written into hgatp, since WARL properity.
   3b） when written with vsatp.mode=any supported mode, -- clear
   -- software can config any vaule for vmid & ppn
   -- hardware just take all the configuration since mode=supported
   3c）when written with vsatp.mode=any UN-supported mode,
   -- software could config any vaule for asid & ppn, since software may make mistake
   -- what should hardware do? since When V=0, a write to vsatp with an unsupported MODE value is either ignored as it is for satp , or the fields of vsatp are treated as WARL in the normal way. However, when V=1, a write to satp with an unsupported MODE value is ignored and no write to vsatp is effected. then when V=1, unsupported MODE value is ignored by satp and no write to vsapt. but for V=0, what should hardware do? planA, or planB?
   planA: refresh the vsatp with the new writting-data
   planB: just keep the entire original value, like satp.
   How to understand the WARL? for planA, if vsatp is write with data of vsapt.mode=15(not supported) vsatp.asid=16'h5 & vsatp.ppn=16'h5, then what should be written into the vsatp, and what is the reasonable results for the read operation?

4. mmpt CSR for Smmpt,
   4a）when written with mmpt.mode=bare,
   -- software should make sure that mmpt[63:0]=64'b0.
   -- hart just take the mmpt as a WARL CSR, that is to say any data with mmpt.mode=Bare & (mmpt.asid= any value | mmpt.ppn=any value) can be written into the vsapt. e.g, mmpt.mode=Bare & mmpt.asid=16'h5 & mmpt.ppn=16'h5 can be written into hgatp, since WARL properity.
   --since smmpt spec says When mmpt MODE=Bare, supervisor physical addresses have no MPT-based protection across supervisor domains beyond the physical memory protection scheme described in Section 3.7 of the RISC-V privileged architecture specification [3]. In this case, the remaining fields (SDID, PPN) in mmpt must be set to zeros., it seems both software and hardware should make sure that mmpt shoule be written with 64h0 when mmpt.mode=Bare.
   4b） when written with mmpt.mode=any supported mode,
   -- software can config any vaule for sdid & ppn
   -- hardware just take all the configuration since mode=supported
   4c）when written with mmpt.mode=any UN-supported mode,
   -- software could config any vaule for asid & ppn, since software may make mistake
   -- what should hardware do? planA, or planB?
   planA: refresh the mmpt with the new writting-data
   planB: just keep the entire original value, like satp.
   Implementations are not required to support all defined MODE settings when XLEN=64. A write to mmpt with an unsupported MODE value is not ignored. Instead, the fields of mmpt are WARL in the normal way, when so indicated.
   -- How to understand the WARL? how to understand the "not ignored" in the A write to mmpt with an unsupported MODE value is not ignored. for planA, if mmpt is write with data of mmpt.mode=15(not supported) mmpt.sdid=6'h5 & mmpt.ppn=16'h5, then what should be written into the mmpt, and what is the reasonable results for the read operation?
   --

[aswaterman]

I'm in a crunch, so it's someone else's turn to help this time.

[gfavor]

There's a lot to parse and try to respond to.. For now I'll try and tackle #1.

When attempting to select MODE=Bare, proper software - to avoid UNSPECIFIED behavior - should write a nonzero pattern in the remaining fields. Otherwise UNSPECIFIED behavior can result - for which the Unpriv defines what "UNSPECIFIED Behaviors" means.

[rock-ifly]

There's a lot to parse and try to respond to.. For now I'll try and tackle #1.

When attempting to select MODE=Bare, proper software - to avoid UNSPECIFIED behavior - should write a nonzero pattern in the remaining fields. Otherwise UNSPECIFIED behavior can result - for which the Unpriv defines what "UNSPECIFIED Behaviors" means.

Can we just implemented like these for xatp and mmpt CSR:

1. if Mode=Bare, then it is software responsibility to let all the field = 0, hardware just refresh the CSR as the writing-data, no any hardware check needs here.
2. if Mode=Supported, then do this as an usual CSR writing.
3. If mode=un-supported, to align with WARL, mode keep original value (aligned to Read logically), and the other fields update with the new writing data. Except satp, which keep the entire orignal value for the whole CSR.

[gfavor]

1. The spec does not require (i.e. does not specify) any hardware check and just specifies a software responsibility to either write a zero pattern in the remaining fields or accept that UNSPECIFIED behavior will result. And, to be clear, the spec does not say that the hardware will "just refresh the CSR as the writing-data". The hardware may do that as part of its UNSPECIFIED behavior, but software cannot depend on that being the specific behavior that is implemented.

Items 2 and 3 should simply follow the spec - which I think is what the above texts for 2 and 3 are reiterating.

[gfavor]

Re item 4 in #2050 (comment), that needs to be directed to the TG that is developing that extension.

[gfavor]

I believe similar comments as in #2050 (comment), apply to items 2 and 3 in #2050 (comment).

Re the "for V=0, what should hardware do? planA, or planB?" question in item 3, the spec is clear that an implementation has two choices that it is free to pick between: "When V=0, a write to vsatp with an unsupported MODE value is either ignored as it is for satp , or the fields of vsatp are treated as WARL in the normal way."