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

just to comment. in the sigHPC working group we will begin to think about a true 64 bit address space (at a minimum). meaning ALL 64 bits have a meaning. at BSC we are working on such a system. in the

Riscv-privileged_1.12-draft, Table 6.2 gives a list of hedeleg bits which must be writable, and it is stated: "Requiring that certain bits of hedeleg be writable reduces some of the burden on a hyperv

I expect, and have observed in Spike, that `sstatus.SIE` will apply to interrupts delegated to HS-mode, and `vsstatus.SIE` will apply to interrupts delegated to VS-mode. But I cannot find this explain

Hi All, On a 64-bit implementation RISCV that supports a writable XML field in the MISA CSR and that supports writing 1 to that field (to turn on 32-bit mode), if we apply section 2.4 (CSR width modul