John, Now I see that the reason for two bits is three desired outcomes. But why is the first of the three necessary? Why don't we simply have two outcomes: - All custom state is disabled. -

I was asked privately to better explain to the list why having just one special bit in mstateen0 (and presumably likewise for the hstateen0 and sstateen0) isn't sufficient. Here's my attempt: For

Yes, I get it now, and I like your proposal. Thanks for the explanation.

Scott Johnson wrote: Me: Scott: Let's say the custom registers that control lower-privilege access to custom state are all zeros, possibly because they get initialized that way by reset. We now

Oooh. I think I got you now. How would the S-mode software enable all the custom enable bits in those custom CSRs?

The M-mode software would write a 1 to that bit?

Scott Johnson wrote: How would that allow one to enable lower-privilege access to all unknown custom state? You said yourself earlier: - John Hauser

The more bits we dedicate to custom use to ensure that we've got enough for everyone, the quicker we use up each *stateen CSR, when we can be pretty sure most of those custom bits will be unused in

Code that does environment swapping will need to use custom instructions to save custom state, so might as well use custom CSRs for the individual enable bits instead of taking up space in the

Why does all custom state need to be controlled with a single bit? Couldn't we just designate the upper 8 or 16 bits of each xstateenY register to be custom? Any software that wanted to disable all

Allen Baum wrote: It provides a convenient means for software to enable lower-privilege access to all custom state, requiring only the minimal amount of hardware for the task. - John Hauser

Like Allen, I'm not following the need for this complexity. Why not one simple read/write bit that disables all custom state when 0? It would be ANDed with any custom state enable CSR bits, much like

If I understand the above: you can write a 1 to the first bit, but you'll always read back zero? What does that accomplish? I think you need to establish what the (legal) reset state(s) is/are

Having a more misa-like implementation would also allow virtualization of an implementation without support for a particular stateless extension such as A or B, though it would take more bits. Via

I wrote: Scott Johnson: After I wrote my earlier message, I realized we need to be able to revoke permissions, and this is best supported with a second bit alongside the first one. The second bit

Jonathan Behrens wrote: That would be true, except we already have the "H" bit in misa which is expected to be writable. Also, to ease future hardware support for nested hypervisors, it turns out the

I agree one bit is sufficient, but I don’t understand the write-only, read-zero behavior? Would M-mode never be able to revoke permissions?

From: Scott Johnson <scott.johnson@...> Sent: Tuesday, April 20, 2021 8:33 PM To: Bill Huffman <huffman@...> Cc: tech-privileged@... Subject: Re: [RISC-V] [tech-privileged] proposal for stateen CSRs

The proposed mstateenX CSRs feels very similar to misa. It almost seems like you could achieve the same thing as this proposal just by adding sisa and hisa (plus misa2, misa3, ...), but I think I've

Allen Baum wrote: I forgot to say what that means, didn't I? Good point! To quote Admiral Ackbar: "It's a trap!" You get an illegal instruction trap, unless you're executing in a virtual machine