MPRV + MXR

[jiahzhang]

MPRV and SPVP affect pointer masking as well, causing the pointer masking settings of the effective
privilege mode to be applied. The exception to this rule is the case where MPRV is set while MXR is
also set, in which case pointer masking does not apply (see Section 3.1, “Ssnpm” for the rationale).

Should this be clarified to say the exception only applies for non-hypervisor load/store instructions? Although, the hypervisor spec does note that SPVP overrides MPRV in this case.

[martinmaas]

The reason for this exception is that pointer masking does not apply to instructions. The equivalent for hypervisor load/store instructions is described in Section 2.6: Pointer masking applies to HLV. and HSV., but not HLVX.*. We will add a note to clarify this, as we agree it can be easily overlooked.

[jiahzhang]

Yes, I understand that part. I am more so pointing out that for hlv and hsv, their effective privilege mode is determined by SPVP and not MPRV (as is already mentioned in the first sentence).

But from the second sentence, if MPRV=1 and MXR=1, then hlv and hsv would also be unaffected by pointer masking. If this is the intended behavior then ignore this issue.

It would also be good if MXR could be clarified for 2-stage translation. Is this referring to mstatus.MXR and/or vsstatus.MXR (is this dependent on MODE)?

[martinmaas]

Ah, thanks for clarifying – I had misunderstood the question. I agree that we should define the behavior in both of these cases. We'll probably need to bring this to the architecture review committee, but my take is the following:

• Given that hypervisor load/store instructions already have different instructions to disambiguate between instructions and data, my weakly held opinion is that the cleanest approach is that the hypervisor load/stores are not affected by MPRV=1 and MXR=1. I think this is what you suggested in your original comment.

• For 2-stage translation, I think it should be mstatus.MXR by default, but we could revisit this if there is a reason why it should be vsstatus.MXR depending on the MODE.

[jiahzhang]

I believe the current spec will make vsstatus.MXR override mstatus.MXR for VS-stage translation. However, section 3.5 says we will apply pointer masking depending on whether *atp is BARE, in which case it may still be applied in G-stage where vsstatus.MXR would not apply. I don't know what the right answer is here.

[martinmaas]

After consulting with the Architecture Review Committee, we settled on the following language:

When MXR is in effect at the effective privilege mode where explicit memory access is performed, pointer masking does not apply.

This clarifies that the MXR field used is determined by the existing RISC-V specification, rather than introducing a special case for pointer masking.

[aswaterman]

It looks like the spec change was incomplete. There is another reference to MXR only disabling pointer masking when MPRV is set. I'll make a PR to fix it. (It's a non-normative note, so fixing it requires no normative change.)