Allen,

How is compliance testing going to handle this issue for software (versus hardware) writes to *tval CSRs?  For example, when software writes stval with an address, how is the validity judged?  Is it based on S-mode and satp.MODE, or on the state of the current privilege and translation modes?  Similarly, what happens when HS-mode writes vstval?

This is further ambiguity in the Priv spec that needs to be resolved - possibly (?) by you proposing a behavior that compliance will test for and thus require of any compliant implementations (and which the arch spec would then need to incorporate).  I suspect there is no great answer; each has its own ugly points for software and/or for hardware.

Or should the specified behavior for software writes simply be that the written value is always treated as if valid, i.e store the low N bits in the storage flops and set the special N+1 flop as sign-extension of the low N bits?  Or that hardware checks whether written bits [63:N] are sign-extension of the low N bits?  Both of these have their own uglinesses, and both would be wrong for Bare and M modes.

Greg

On Sun, Jun 14, 2020 at 2:39 PM Allen Baum <allen.baum@...> wrote:

When address-related exceptions occur, the xTVAL CSR is written with the faulting effective address.  However, the spec also says:

  Implementations may convert some invalid address patterns into other invalid addresses prior to writing them to xTVAL.

The purpose of this statement is to allow implementations to reduce the number of xTVAL storage bits when addresses are smaller than XLEN.  (If your implementation implements all XLEN bits of mtval, this point is moot, and you can skip to the last paragraph.)

We propose to constrain this behavior to simplify the task of compliance-testing the xTVAL registers.  In particular, allowing implementations to arbitrarily convert any invalid address to any other invalid address is impractical to test.

Some implementations, including the Rocket core, make xTVAL a two's complement value that's just 1-bit wider than the largest virtual address.  This allows xTVAL to represent all valid virtual addresses with the minimal number of physical storage bits, yet still allows it to distinguish properly sign-extended VAs from improperly sign-extended VAs.  

The scheme replaces improperly sign-extended bits with the inverse of a properly signed address[VA] bit. Or (in pseudo code):

  xTVAL[XLEN-1:VASIZE] = (address[XLEN-1:VASIZE] == sign_extend( address[VASIZE-1]))

    ?    sign_extend(address[VASIZE-1]

    :   ~sign_extend(address[VASIZE-1]; 

 The effect of this scheme is that valid virtual addresses are always preserved, whereas invalid virtual addresses always remain invalid, even though their MSBs are discarded.

We are proposing to restrict xTVAL implementations with fewer than XLEN physical storage bits to support only this invalid address conversion scheme.

-->   If your implementation conforms to this scheme, or if your xTVAL register can represent all XLEN bits unconditionally,  please select (reply with X following) "Yes."  

-->  If your implementation doesn't conform to this scheme, but still conforms to the ISA spec, please select (reply with X following) "No", and carefully explain in the comments field how your implementation recodes invalid addresses.  

"No" responses without a sufficient explanation in the comments will not be considered.

Yes: ___ (our implementation conforms to this constraint or implements XLEN bits)

No:  ___ (our implementation is ISA compliant but doesn't conform to this constraint)

Comment (if you select "no" above):