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

To widen the question slightly further are there any plans to provide atomic load/store pair operations (128-bits for RV64, 64-bits for RV32)?

I think your interpretation of that sentence is accurate. FWIW, the insufficiently described Linux platform does assume such accesses are legal (more precisely, the various SBI implementations make

So the only constraint is that when a 64b naturally-aligned access is made to mtime/mtimecmp, the access must be completed atomically if the platform allows 64b naturally-aligned accesses to those

The second half of my answer was addressing the more general matter. For mtime and mtimecmp specifically, the spec is now clear:

Asking this slightly differently (I think) to clarify.... With respect to mtime/mtimecmp, does an RV64 processor place constraints on the platform, or can the platform place constraints on the RV64

The spec strongly implies by omission that 64-bit accesses are atomic for RV64, in that it gives an unusually detailed RV32-specific code example to cope with non-atomicity, but mentions nothing of

The mtime and mtimecmp registers are defined as 64-bit memory-mapped registers. The priv spec says that - in RV32 - mtimecmp can be written as a pair of 32-bit registers. Since this was made

John, thanks for the full responses. I had suspected the former. But as can sometimes be the case, we were looking at certain parts of the spec and weren't looking at the tables in section

Having SPP/SPV hold the real values makes the most sense to me. The strategy I'd expect hypervisors to use would be to set a bit before issuing any HLV or HSV instructions and clear it after. Then in

Greg Favor wrote: The actual virtualization and privilege modes, same as always. Consider the analogy with memory accesses made in M mode when mstatus.MPRV = 1. The document says that such memory

When one of the new HLV/HSV instructions faults, what virtualization and privilege modes are recorded in mstatus.mpp/mpv, or in sstatus.spp/spv and hstatus.spvp? Are they based on the actual modes

Hi Jonathan, All cases for CSR accesses have not been thought through (initial draft) and written out. Regarding WARL CSR with hardwired bits, the HW will always read/write fixed values of

Your description of un-accelerated nested virtualization seems workable to me. I'm less sure of the proposal to avoid trapping on h<xyz> and vs<xyz> accesses. Aren't you going to run into issues with

A clarification is required in RISC-V H-Extension spec regarding scope of HSTATUS.VTVM bit. Currently as-per the spec, all virtual memory management instructions (both SFENCEs and HFENCEs) will trap

As Andy already pointed out, the RDINSTRET could be quite useful for other purposes as well (e.g., record-and-reply or redundant execution). Would it be possible to add a filter or mask so that