Re: xTVAL Compliance restriction proposal
toggle quoted messageShow quoted text
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.
On Sun, Jun 14, 2020 at 2:39 PM Allen Baum <allen.baum@...> wrote: