Folks, I have below the latest version of the plan to add optional "stateen" (State Enable) CSRs to the RISC-V Privileged Architecture, now in the form of a fast-track extension proposal. Much of this

Why does it need to be a CSR? In other parts of the boot flow the device tree pointer is passed via a normal general purpose register. Why can't the same be done here? Jonathan

The new "unified RISC-V low-level discovery method" being developed by tech-config (for use by all extensions that have information that needs to be easily discoverable by software), is almost complet

Note that in an earlier discussion with Greg, I had proposed all-ones as the escape, as a single-byte message can not be valid.

I think we can extend meaning of that CSR register (for future) by allowing write of some 'keyed/secret' value into it. Keeping it 'clean address' is IMO better for now. /Robert -- Regards, Robert Chy

Hi All, The RISC-V H-extension v0.6.1 draft was released almost a year back in May 2020. There has been no changes in the H-extension specification since then. Meanwhile, we have RISC-V H-extension v0

Hello tech-privileged, The proposal below has been discussed by some of the principle RISC-V architects for incorporation into the official Privileged Architecture. The text below makes reference to Z

Hi, We are proposing to remove the N extension from the architecture. The most important role the N extension fills is supporting untrusted interrupt handling in microcontrollers. These systems have M

I found this thread implying that certain SYSTEM opcodes are available for defining custom instructions: https://github.com/riscv/riscv-isa-manual/issues/385 I didn't find any statement about this in

Wouldn't you also want to isolate different interrupt handlers from each other and from any non-interrupt handler user code running on the system? With the N-extension itself none of that would be pos

I would like to clarify the intended behavior of PMP regions when R=0, W=1. The privileged spec (https://github.com/riscv/riscv-isa-manual/blob/4f83798332ad8cf9a7a752f4e9f59ce16d325c73/src/machine.tex

sPMP(MPU) is designed for the separation between U-mode and S-mode and it only make sense only when paging is not available. With H extension, there're 3 atp registers to control the translation for d

What combinations has the TEE group come up with so far that have justifying use cases? Or are you searching for combinations that have justifying use cases? If the latter (and this admittedly reflect

Hello all, After the discussion of the tee group, we decide to rename sPMP to MPU (the RISC-V Memory Protection Unit), and reuse page fault for MPU fault based on our discussion and feedback of the pr

Here's my next attempt to define the absolute minimum that will satisfy all requirements: There are two standard XLEN-wide CSRs for controlling lower-privilege access to custom state: 0x30B mcstateen

I'm forwarding the following announcement while I'm having a mysterious problem with the tech-announce email alias. ---------- Forwarded message --------- From: Greg Favor <gfavor@...> Date: Wed, Apr

I'm going to push back against the proposal to allocate new cause values for sPMP faults. Allocating new cause values has knock-on effects and incremental costs throughout the architecture (with respe

Hi privileged group, The TEE group are proposing the sPMP mechanism for S-mode physical memory protection. (As linked below) The TEE group discusses the proposal for quite a while, and we believe that

My apologies if this topic was discussed and archived. I did search but mostly came across Unix platform style discussions on interrupt support. But my interest here is mostly around RTOS-based low-en

I found that the manual in the ratified state that I downloaded did not match the code that I viewed.The main relevant command is HFENCE.GVMA. Its encodings has been changed. Will there be machines wi