1. Tech-Privileged
  2. Messages

Re: proposal to add "virtual instruction exception" to the hypervisor extension

Jonathan Behrens <behrensj@...>
 

It mostly just comes down to crossing out "In VS-mode" in your list of cases for trapping when V=1:

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

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

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

A few more cases I'm less sure if they make sense:

  - attempts to access an unimplemented hypervisor CSR

  - attempts to access a supervisor CSR in VU-mode

  - attempts to execute MRET or access an M-mode CSR

Jonathan


On Tue, May 5, 2020 at 8:31 PM John Hauser via lists.riscv.org <jh.riscv=jhauser.us@...> wrote:
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
Join tech-privileged@lists.riscv.org to automatically receive all group messages.