Hi All, We have updated QEMU RISC-V, KVM RISC-V and Xvisor RISC-V for RISC-V H-Extension v0.6 spec. The QEMU repo with RISC-V H-Extension v0.6 support can be found

Hello tech-privileged guys, I've created a pull request for the RISC-V privileged spec in response to requests from our hypervisor software

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

Jonathan Behrens wrote: Point taken. Would you like to take a stab at listing every case you think should be included, besides HFENCE? - John Hauser

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

It would be great to have this controlled by a bit in the hstatus CSR. For example a hypervisor that does not overcommit CPUs will probably want to delegate WFI to the guest. Guest-delegated

Paolo Bonzini wrote: I'm afraid this makes no sense to me. Ordinary user-mode applications don't execute WFI. In U mode, WFI is useful only in connection with support for user-level interrupts

But this would be a VS-mode application, not an ordinary user-mode application. I'm not sure why U-mode matters. Anyway... ... I guess this is the misunderstanding. I'm not proposing to

Paolo Bonzini wrote: Okay, I get it now. You're proposing we bring back hstatus.VTW, the HS-mode analog to mstatus.TW. (We had the VTW bit originally in hstatus, but dropped it long ago.) Anyone

Dear Privspec members, You may recall that I had argued for an operation to flush microarchitectural state in order to allow the OS to prevent timing channels. I believe the need for this was not

Hi, Reading through the hypervisor extension v0.6, I noticed the new register called hvip. The spec says that this register is intended for the hypervisor to write to indicate pending interrupts

Siqi (zhaosiqi3@...) wrote: The same question was raised not long ago on the RISC-V ISA Dev mailing list. The following is clipped from that conversation. -------------------- Jose Martins

Siqi (zhaosiqi3@...) wrote: Also, sorry, failed to notice you said vsip, not hip. The previous draft of the hypervisor extension, 0.5, never allowed writing directly to vsip from VS mode,

I wrote: I've created a pull request for the RISC-V privileged manual: https://github.com/riscv/riscv-isa-manual/pull/523 Comments welcome. - John Hauser

Hi all, I have a simple question: does the architecture allow table walk accesses (reads or writes) to regions with the non-idempotent PMA? The architecture doesn't explicitly disallow it, so the

The specification machinery exists to allow implementations to impose such a restriction: "For systems with page-based virtual memory, I/O and memory regions can specify which combinations of hardware

Although I haven't seen any such implementation, I would imagine that a non-idempotent region that was, say, counting accesses to each address as a side-effect of each access may be a "benign" kind of

That sounds a bit like a performance counter to me, but it does raise an interesting question whether "idempotent" in the architectural sense is idempotent in a mathematical sense (i.e. operations are

On 5/18/20 5:10 PM, David Kruckemyer wrote: I've always assumed that it included any side-effects that mattered to the program. It obviously does not include bringing the demise of a chip nearer with