Hello tech-privileged guys,

I've created a pull request for the RISC-V privileged spec in response
to requests from our hypervisor software authors:
https://github.com/riscv/riscv-isa-manual/pull/518

For those with an interest, please review.

This change would add to the hypervisor extension a new kind of
exception, "virtual instruction exception".  The following is copied
from new text added to the hypervisor chapter:

--------------------

When V = 1, a virtual instruction trap (not an illegal instruction
trap) is taken for:

  - attempts to access a counter CSR when the corresponding bit in
    hcounteren is 0 and the same bit in mcounteren is 1;

  - attempts to execute WFI, unless the instruction completes within an
    implementation-specific, bounded time;

  - attempts to execute a virtual-machine load/store instruction, HLV,
    HLVX, or HSV;

  - in VS-mode, attempts to execute an HFENCE instruction or to access
    an implemented hypervisor CSR or VS CSR;

  - in VS-mode, attempts to execute SRET when hstatus.VTSR = 1; or

  - in VS-mode, attempts to execute an SFENCE instruction or to access
    satp, when hstatus.VTVM = 1.

On a virtual instruction trap, mtval or stval is written the same as
for an illegal instruction trap.

\begin{commentary}
When V = 1, circumstances that might otherwise cause an illegal
instruction trap instead cause a virtual instruction trap if a
hypervisor is normally expected to emulate the instruction.  Notably,
for VS-mode this includes the hypervisor instructions (HLV, HLVX, HSV,
and HFENCE) and accesses to the hypervisor-level CSRs, all of which
must be emulated for nested hypervisors.  A hypervisor that does not
support nested hypervisors should convert many virtual instruction
traps into illegal instruction exceptions for the guest virtual
machine.

Machine level is expected ordinarily to delegate virtual instruction
traps directly to HS-level, whereas illegal instruction traps are
likely to be processed first in M-mode before being conditionally
delegated (by software) to HS-level.  Consequently, virtual instruction
traps are expected typically to be handled faster than illegal
instruction traps.
\end{commentary}

--------------------

Regards,

    - John Hauser

Jonathan Behrens wrote:
> I like this plan. The one comment I have is that it seems unnecessarily
> opinionated about which operations trigger virtual instruction traps vs
> illegal instruction traps when run in VU mode. I think we should error more
> on having things trigger virtual instruction traps everywhere that it is
> unlikely to require M-mode emulation. To give one example of where the
> current design might go wrong: analogously to HLV and friends, HFENCE from
> U-mode might be allowed via a CSR in the future, in which case it would now
> require hypervisor emulation when a nested VM tried to run it in VU-mode.

Point taken.  Would you like to take a stab at listing every case you
think should be included, besides HFENCE?

    - John Hauser