Scott Johnson wrote:
> 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 misa.X=0 disables
> all custom extensions.

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

> But there's also the use model of the M-mode software that doesn't do any
> environment swapping and just wants to enable all state for the S-mode. It
> would be nice if that didn't have to be aware of custom state.

    - John Hauser

Scott Johnson wrote:
> 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 misa.X=0 disables
> all custom extensions.

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

> But there's also the use model of the M-mode software that doesn't do any
> environment swapping and just wants to enable all state for the S-mode. It
> would be nice if that didn't have to be aware of custom state.

    - John Hauser

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 custom state would just clear all those bits, while software that wanted to enable all custom state would just write ones. (WARL would cause any unused bits to stay zero even after they were written with a value of one).

Jonathan

On Wed, Apr 21, 2021 at 12:37 PM John Hauser via lists.riscv.org <jh.riscv=jhauser.us@...> wrote:

Allen Baum wrote:
> 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?

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

Allen Baum wrote:
> 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?

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

I wrote:
> This seems like a sensible request to me, except I would accomplish the
> same effect by adding a single "write-only" bit to mstateen0.  The bit
> always reads as zero, and writing zero to it does nothing; but writing
> a one causes all custom state to be enabled for lower privilege levels.
> [...]

Scott Johnson:
> 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?

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 reads as one if any custom
state is enabled, and as zero if no custom state is enabled.  For the
second bit, writing one does nothing, but writing zero disables access
to all the custom state.

In summary, on reads:

    1st bit:  always 0
    2nd bit:  1 if any custom state is enabled; 0 if none is enabled

On writes:

    1st bit:  0 does nothing; 1 enables all custom state
    2nd bit:  0 disables all custom state; 1 does nothing

To safely support read-modify-write of the stateen CSRs, the first bit
could read as one only to indicate that all custom state is enabled.
However, I don't believe software needs to know that, hence I don't
want to require people to build the AND-gate tree for that, regardless
of how small it might be.  So that's how that bit ended up as read-only
zero.

On the other hand, for the second bit, software may be interested to
know whether _any_ custom state has been enabled.  The alternative
for the second bit would be to make it read-only one, which isn't as
attractive.

    - John Hauser

I wrote:
> This seems like a sensible request to me, except I would accomplish the
> same effect by adding a single "write-only" bit to mstateen0.  The bit
> always reads as zero, and writing zero to it does nothing; but writing
> a one causes all custom state to be enabled for lower privilege levels.
> [...]

Scott Johnson:
> 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?

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 reads as one if any custom
state is enabled, and as zero if no custom state is enabled.  For the
second bit, writing one does nothing, but writing zero disables access
to all the custom state.

In summary, on reads:

    1st bit:  always 0
    2nd bit:  1 if any custom state is enabled; 0 if none is enabled

On writes:

    1st bit:  0 does nothing; 1 enables all custom state
    2nd bit:  0 disables all custom state; 1 does nothing

To safely support read-modify-write of the stateen CSRs, the first bit
could read as one only to indicate that all custom state is enabled.
However, I don't believe software needs to know that, hence I don't
want to require people to build the AND-gate tree for that, regardless
of how small it might be.  So that's how that bit ended up as read-only
zero.

On the other hand, for the second bit, software may be interested to
know whether _any_ custom state has been enabled.  The alternative
for the second bit would be to make it read-only one, which isn't as
attractive.

    - John Hauser

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 convinced myself that wouldn't quite work.

I'll also point out that we'll probably want to reserve a bit in [m|s]stateen0 for the H-extension.

Jonathan

On Tue, Apr 20, 2021 at 11:01 PM John Hauser via lists.riscv.org <jh.riscv=jhauser.us@...> wrote:

Allen Baum wrote:
> Questions: (I suspect I know the answers, but want to be clear):
>   -if  mstateenY[n] is cleared, and s-mode code tries to read/write a CSR
> that is controlled by that bit
>     -- does the access trap?
>     -- else does it cause read/writes of the CSR from Smode
>         --- to return zero/have no effect
>         --- to return the value it had at the time that the bit was
> cleared/have no effect
>
> Or put another way: what exactly does "control access" mean?

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 (V = 1)
and the access is _not_ being blocked by the mstateen CSRs, in which
case you get a virtual instruction trap.

(Related to that, it's on my to-do list to add to the Privileged
Architecture's hypervisor chapter a better general explanation for
when you should get a virtual instruction trap instead of an illegal
instruction trap.)

    - John Hauser

Scott Johnson wrote:
> It seems the use model is to enable older environment-swapping software to
> run on newer hardware without opening a security hole via new state. Only
> if the software is aware of the state will it enable that state via
> *stateen.
>
> For custom state, you can always make custom *stateen-like CSRs to enable
> it. You're going to need custom software to swap that state anyway.

Yes, that's exactly what we were thinking.

> But there's also the use model of the M-mode software that doesn't do any
> environment swapping and just wants to enable all state for the S-mode. It
> would be nice if that didn't have to be aware of custom state.
>
> So, I join Bill in his question. It seems a good idea to reserve some bits
> for custom state for that latter use model.

This seems like a sensible request to me, except I would accomplish the
same effect by adding a single "write-only" bit to mstateen0.  The bit
always reads as zero, and writing zero to it does nothing; but writing
a one causes all custom state to be enabled for lower privilege levels.
As you suggested, there will presumably be custom CSRs containing
one or more bits that control access to the custom state, akin to
the mstateen CSRs for standardized state.  Machine-level software may
consult and modify those custom-state-controlling bits directly if it
has sufficient knowledge, but won't have to.

    - John Hauser

Allen Baum wrote:
> Questions: (I suspect I know the answers, but want to be clear):
>   -if  mstateenY[n] is cleared, and s-mode code tries to read/write a CSR
> that is controlled by that bit
>     -- does the access trap?
>     -- else does it cause read/writes of the CSR from Smode
>         --- to return zero/have no effect
>         --- to return the value it had at the time that the bit was
> cleared/have no effect
>
> Or put another way: what exactly does "control access" mean?

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 (V = 1)
and the access is _not_ being blocked by the mstateen CSRs, in which
case you get a virtual instruction trap.

(Related to that, it's on my to-do list to add to the Privileged
Architecture's hypervisor chapter a better general explanation for
when you should get a virtual instruction trap instead of an illegal
instruction trap.)

    - John Hauser