Control-Flow Integrity (CFI) mechanisms - Concerning a shadow stack, the ARC wondered whether, in addition to an instruction that pops from the shadow stack and checks the return address, it was neces

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 belie

Pointer-masking extension - On Monday, members of the ARC met with the J Extension Task Group to review the status of the proposed pointer-masking extension. - It is the sense of the ARC that the curr

Pointer-masking extension - The ARC proposed a meeting with the J Extension Task Group to discuss some specifics of the latest draft proposal. IOMMU - Discussed the ongoing rework of the IOMMU draft s

Oscar Jupp wrote: The caption on Table 7.1 says: The effects of hideleg and hvien on vsip and vsie for major interrupts 13-63. Bits 10, 6, and 2 in vsip are major interrupts 10, 6, and 2 for VS level,

Greg Favor wrote: To emphasize Greg's point, the next sentence says, "When V=1, an attempt to read or write a VS CSR directly by its own separate CSR address causes a virtual instruction exception." O

Tariq Kurd wrote: Yes, let's assume bit 2 is allocated for this purpose, in mstateen0, hstateen0, and sstateen0. We'll probably change the wording later, but for now, replace the word _encodings_ by _

Mark wrote: We expect people to implement the new Zcm* extensions together with Zca and Zcb. Zca is the subset of C that drops the compressed instructions for double-precision floating-point loads and

I wrote: Correction: Zca is a subset of C; Zcb is not. - John Hauser

Greg Favor wrote: Actually, there's no conflict between Zcmt and the D extension. The conflict is between Zcmt and the C extension, because it's the C extension that defines the compressed instruction

In the latest ratified Privileged Architecture document, 1.12, the hpmcounter* CSRs are specified as _unprivileged_ CSRs, not user CSRs. - John Hauser

Vedvyas Shanbhogue wrote: That's why we write "unless specified otherwise". If there were a supervisor CSR that changed satp to read-only, then this particular case would need to be more tightly speci

Andrew Waterman wrote: I just knew somebody was going to say that. Scott Johnson: Exactly right. It does seem intuitive that, when the set of legal values changes, the CSR/subfield value should avoid

Allen Baum wrote: Yes, you have it correct, Allen, although my text only addressed writable-versus-read-only and not the possibility that the set of valid values might change due to another CSR. Some

Hi Privileged ISA group, There's been a longstanding shortcoming in the RISC-V Privileged ISA document that it doesn't precisely explain what may happen when one CSR controls the writability of bits o

Ved wrote: Thank you, much better. (I think you could go ahead and reveal the unnamed "Member". It won't be a secret to the TG, and you may as well take some credit for your effort, in my opinion. But

Nick Kossifidis wrote: Thanks for sharing this, Nick. I support the long-term efforts to develop a standard RISC-V I/O MMU, but I must raise one serious complaint at this time: The status of this docu

Paul Donahue wrote: You have the effect of "HS-qualified" backwards. An instruction raises a virtual instruction exception _only if_ it is HS-qualified. If it isn't HS-qualified, then it must raise an

I invite comment on this proposed update to the rules for raising virtual instruction exceptions when in VU mode: https://github.com/riscv/riscv-isa-manual/pull/730 - John Hauser

Paul Donahue wrote: From the hypervisor extension chapter, Section 5.2, "Hypervisor and Virtual Supervisor CSRs": Some standard supervisor CSRs (scounteren and scontext, possibly others) have no match