1. Messages
  2. Appearance of new M-mode CSR bits when Hypervisor is disabled

Re: Appearance of new M-mode CSR bits when Hypervisor is disabled

Greg Favor
 

Thanks.  This is the interpretation we expected to be correct.

For the sake of some future readers of the spec that may not apply the broadest meaning of "behaves" when reading "behaves as though this extension were not implemented", it may be worth a few words to note that "behaves" also means that new CSR bits/fields defined by the extension must have simple read/write behavior the same as when the extension is not implemented (i.e. not just that these bits have the same effect or lack of effect as if the extension is not implemented).

Greg


On Mon, Jun 22, 2020 at 2:58 PM John Hauser <jh.riscv@...> wrote:
Greg Favor wrote:
> The Hypervisor extension adds bits to some of the existing M-mode CSR's.
> When this extension is not implemented, these bits are hardwired to zero.
> When the extension _is_ implemented these bits become either read/write or
> (in a few cases) hardwired to one.
>
> On the one hand the hypervisor spec says that when misa.H=0 (i.e. the
> extension is "disabled"), "the hart behaves as though this extension were
> not implemented".  But where these various added M-mode CSR bits are
> described, they are defined to exist when "the hypervisor extension is
> implemented".
>
> The former statement implies that these new bits must appear to be
> hardwired to zero when misa.H=0, while the latter statement implies that
> these new bits appear to be read/write or hardwired to one irrespective of
> misa.H (although presumably they have no functional effects when misa.H=0).
>
> Which is the correct architectural intention?

The overriding statement in the document is this one:

    When misa[7] (bit H) is clear, the hart behaves as though this
    extension were not implemented, ....

I sympathize with the desire to enforce an intuitive view that, if
misa.H is writable and set to 0, the hypervisor extension really _is_
implemented, just disabled.  However, I believe the statement above
is clear that when misa.H = 0, the hardware must act the same as when
the hypervisor extension is not implemented.  If that statement didn't
override an intuitive interpretation of _implemented_ everywhere in the
chapter, then the statement would be null-and-void, and that can't be
right.

Allowing "implementation" to be configurable at run-time may be
non-intuitive, but I claim the hypervisor chapter is consistent with
similar other uses in the document.  For example, concerning the FS
field in mstatus, the document says:

    In systems that do not implement S-mode and do not have a
    floating-point unit, the FS field is hardwired to zero.

What about when misa.F and misa.S are both writable and set to zero?
In that case I believe the specification requires that mstatus.FS
be read-only zero, the same as when the F extension and S mode are
not implemented.  So what does the document really mean by "do not
implement S-mode" and "do not have a floating-point unit"?

If anything, I think the hypervisor chapter is being slightly more
careful to document the consequences of modifying misa.

    - John Hauser
Join tech-privileged@lists.riscv.org to automatically receive all group messages.