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