There was one item regarding the specification – what are the implications for H-extension? Since the H-extension is part of the privileged spec, I think it should be specified. I do have a

Hi Greg, I am working on the SBI PMU extension implementation in OpenSBI & Linux kernel. I will update the SBI PMU extension based on Sscofpmf extension as well. I can work on implementing the

How would one make compliance tests for this extension? For example, how can one test the overflow exception when there is no standard on how to configure any of the HPM event counters to count, in

Just to emphasize: If a number of people can pitch on on various DoD pieces, that would help a lot. Spec-wise we're in good shape (even though there is work to be done), and I've already submitted

Cc'ing tech-priv since others may be wondering about the answer to Brian's question. Brian, As Mark touched on below, there is a whole "Definition of Done" checklist of items that needs to be done

It's been three weeks since this proposal has been floated, and feedback was provided on the list. Everyone I've checked with off-list has been okay with the spec. Does anyone object to moving it

This was just a question about existing behavior. It is unrelated to the ongoing security conversation on the virtual memory TG mailing list, if that's what you're asking. Dan

it makes sense but in what way does this make us more secure?

Hi Gracy, When satp.mode is not bare, virtual addresses must be sign-extended to fill XLEN. When the physical address generated in any mode is smaller than the implementation's physical address

I reused a topic title under https://github.com/riscv/riscv-isa-manual/issues/131 And also I attached some comments in section 4.4.1 of privileged spec those confused me so much, A. Sv39

I mis-misremembered. To clarify the mtval behavior for [C.]EBREAK instructions: mtval is permitted to either be zeroed or written with the faulting address (i.e. the PC) on a software breakpoint.

Indeed, I misremembered.

The proposal appears to address the VSEE and in the "I/O to memory" direction, and just for the channel 0 implicit strong ordering / no fence case. It's not clear to me that that is the only problem.

I agree that it is an unusual operation but if it is needed I don’t think you can use mtval as it is defined to be zero on an ebreak/c.ebreak. Mark

My experience has been that simply skipping over a [C.]EBREAK without first knowing how wide the instruction is not a commonly desired operation. If the instruction was inserted by a debugger, the

Note that if the EBREAK comes from a lower privilege mode, the address put into mepc is the virtual (not physical) instruction address of the EBREAK instruction. Hence M-mode will need to use the

Hi Anne, Nice to hear from youJ Yes you will need to increment the epc to continue. The handler needs to read the byte at the address mepc, if the bottom two bits are 0’b11 then it’s a 4

Hello The Privileged spec says that "ECALL and EBREAK cause the receiving privilege mode’s epc register to be set to the address of the ECALL or EBREAK instruction itself, not the address of the

The rasd group has started [https://lists.riscv.org/g/tech-rasd/topics] and it's charter, still being formulated, could help to address this. Contribute if interested. -Josh

The existing Linux platform expects strongly ordered point-to-point I/O, so while convenient for the HW, I don't think it's a workable solution.