misa WLRL field

[pdonahue-ventana]

"The misa CSR is a WARL read-write register" seems not entirely true since it contains a WLRL field.

Also, the definition of WLRL says that such fields must only be written with legal values (a software requirement) and that the reset value of WLRL fields must be legal (a hardware requirement). The software requirement can be complied with by always doing read-modify-write. But the hardware requirement can only be complied with if legal values are specified. Unlike the other WLRL fields in the privileged spec, there is no description of what values are legal for this misa field. We can infer that zero is one of the legal values since the whole register is allowed to be zero, but that doesn't rule out other legal values.

Is this field implementation-specific and UNSPECIFIED? Must it be zero (as was the case when the field was WIRI two years ago)? Something else?

[aswaterman]

It is true that forward-compatible software shouldn't try to write fields it doesn't know about to nonzero values, because newer versions of the spec could assign meaning to such fields. But I don't think it means the unused bits are actually WLRL. Writing them to a nonzero value on future hardware could cause behavior that software doesn't expect, because it could enable some extension that software doesn't know about. But that's different from causing UNSPECIFIED behavior.

The unused misa bits are analogous to pmpcfg bits 6:5, which are currently always 0, but which might take on new meaning in the future. We label those pmpcfg bits as "0 (WARL)". I think we should be doing the same thing for the unused misa bits.

[allenjbaum]

Is there a reason that bits MXLEN-3...26 aren't WARL (0)? or WPRI ? IF they're being reserved for future standard features, WPRI makes sense. The architecture defines WARL, WLRL, and WPRI, and describes how each behaves - but doesn't describe the use cases. CSRs with WLRL that are written with illegal values are allowed to trap, but ordinarily we've said that we don't have data dependent traps on CSRs. That can still occur if the CSRRxI immediate forms are used, but otherwise not. It seems strange that writing the same value to the same CSR will trap if the immediate form is used, but not if the register version is used. The only CSRs that have WLRL fields are MISA, the exception code in the various versions of the xcause CSRs, and VGEIN in the hypervisor status CSR. I'm wondering what makes those fields so special that they couldn't use WARL or WPRI.

…

On Fri, Jul 10, 2020 at 1:57 PM Andrew Waterman ***@***.***> wrote: It is true that forward-compatible software shouldn't try to write fields it doesn't know about to nonzero values, because newer versions of the spec could assign meaning to such fields. But I don't think it means the unused bits are actually WLRL. Writing them to a nonzero value on future hardware could cause behavior that software doesn't expect, because it could enable some extension that software doesn't know about. But that's different from causing UNSPECIFIED behavior. The unused misa bits are analogous to pmpcfg bits 6:5, which are currently always 0, but which might take on new meaning in the future. We label those pmpcfg bits as "0 (WARL)". I think we should be doing the same thing for the unused misa bits. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#537 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJRNTBZQPV4M2TRJYATR256CDANCNFSM4OW5MHMQ> .

[aswaterman]

@allenjbaum I guess I'm saying I think this is an editing oversight, and they should indeed be marked WARL (0).

[allenjbaum]

And the next step is: can we eliminate the other two cases and simplify the architecture so there are only 2 types of fields? The description that says that fields should be written with the same value read: that is a SW requirement - I'm not sure that "requirement" is even the right word here. I don't think it makes sense to define HW field behavior based on some software rule, as opposed to having a note about the expected SW behavior where the field is defined, and the possible consequences if you don't follow the rule If we can have WARL fields where you have no idea what happens if you write an illegal value (well, you know its legal, but not which legal and therefore with unknown side effects and putting the hart into an unknown state) - how is that any worse than telling implementors that only the value that is legal is the one that is read, so they shouldn't change it or bad things may happen?

…

On Fri, Jul 10, 2020 at 10:30 PM Andrew Waterman ***@***.***> wrote: @allenjbaum <https://github.com/allenjbaum> I guess I'm saying I think this is an editing oversight, and they should indeed be marked WARL (0). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#537 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJTJUY3RZHDNU2E3BMDR272GNANCNFSM4OW5MHMQ> .