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

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

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

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

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: 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

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

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

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

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

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

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

Ah..... yeah, ok. that "atoimc" (single-copy atomicity) vs the "atomic" (LR/SC pair). My bad. Apologies Mark (assuming Andy is right and you meant load and store instructions that are

I assumed that Dr Mark Hill was talking about 256 bit atomic loads and stores to ask the FIFO, not LR/SC. Also, double width CAS (and other double width atomics) is used not just for A-B-A

Interesting. If you had a H/W FIFO, seems like it would be easier to make it work with single-copy atomic loads or stores to read from or write to the FIFO rather than bothering with the tedium of

Another possible use case is access sensitive devices, for example a FIFO of 128-bit records with multiple RV64 harts reading from the FIFO.

Just for you, Allen. https://github.com/riscv/riscv-isa-manual/commit/a1c7d2553cb6fba3d8636355e2a7cb247d047d7c

To widen your question even further Mark (no pun intended), do we need 256 bits for RV128? Yes, RV128 is a bit speculative, but it does at least rate being in the book, so best to have all the

more mtimecmp questions: - the spec says that an interrupt occurs is posted when the mtime register contains a value greater than or equal to the value inthe mtimecmp register. but doesn't