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

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

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

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,

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