Oscar -- 1. As you said: if hardware doesn't want to spend the hardware cost/complexity of reporting the faulting GPA, then the hardware can choose anytime to report GPA=0, and still be compliant with

+priv sw -------- sent from a mobile device. please forgive any typos.

To whom it may concern, In RISC-V privileged spec says that mtval2/htval can be written zero when guest page faults occur. I have some questions regarding the statement: 1. Under what

I also forgot to remind everyone that one of the things we encourage at RISCV is custom extensions. It breeds innovation. Implementers choose to do custom extensions for a lot reasons including time

Dong, thank you! this is great. let's make sure as the TG get started that all proposals and POCs get a chance to present their ideas. Also note as a reminder that a number of previous TGs have had

Hi all, The ARC recently approved the Instret & Cycle Privilege Mode Filtering (Zicntrpmf) ISA extension to be pursued as a fast-track extension. This extension allows the instret and cycle counters

Zicond (fast-track): The last PR - to move the DVI text from non-normative to normative text (plus any other last edits) - is to be created shortly by the ARC. After which Zicond should be ready to

WFMI instruction - The ARC discussed whether the current draft proposal for a WFMI instruction (Wait For "My" Interrupt) had any significant issues for virtualization. The committee concluded it

The relevant passage in the Unpriv spec is actually: When any instruction executes, it implicitly reads mcountinhibit to decide whether to increment instret. That implicit read happens in program

Yes, good point, I would not expect that to be part of the ultimate spec.

Shouldn't the whole "Usage" section be a non-normative comment?

Hi all, The ARC recently approved the Supervisor Counter Delegation ISA extension to be pursued as a fast-track extension. This extension allows M-mode software to allow select Zicntr and/or Zihpm

Hi all, Consider the following code sequence, assuming that mcountinhibit.IR has initial value 1: csrc mcountinhibit, 0x4 # uninhibit instret csrs mcountinhibit, 0x4 # inhibit instret My read of the

Thanks, Andrew and Greg, for your feedback. I understand that is not ARC's official responsibility, but it's always good to get opinions on that from ARC as well as timelines. I also agree it's

Now that I have a chance, I was going to respond similarly. I would only add that at this very early stage in the process for a new arch extension, the ARC doesn't worry about how it may fit into

I'm not speaking on behalf of the entire committee, but my take is that these are the kind of instructions that would be most useful if mandated by an RVA profile. It's hard to see them making the

Does the AR committee have an opinion on how those new instructions will surface in a Profile? i.e. RVA23? Or beyond?

Vector Crypto: Received and starting to review final draft with hopes to finalize next week. IOMMU: After receipt of the final draft of the spec, review has been completed and AR approval has been

The spec mentions that implementations are permitted to ignore rs1 altogether, so trapping is certainly not required.

Greetings ! I understand that the SFENCE.VMA/SINVAL.VMA instructions have unspecified behavior if a non-canonical form virtual address is specified and specifically no page fault is expected. I