While I would have to go through all the bits/fields affected by the H extension to double-check, the main issue are bits/fields that were previously reserved (and hardwired to zero).  So there isn't the general issue of what the "unimplemented" read values should be.  Similarly, the "unimplemented" behavior for CSR's added by the H extension is straightforward.

Greg

On Mon, Jun 22, 2020 at 5:43 PM Allen Baum <allen.baum@...> wrote:

And we should be careful to define the corner cases, e.g. the values that are in the registers when the features are enabled: the values they last held, or undefined, or.... something else.

On Mon, Jun 22, 2020 at 4:08 PM Greg Favor <gfavor@...> wrote:

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