Resending from correct email address Begin forwarded message: From: krste@... Subject: Re: [RISC-V] [tech-privileged] RISC-V H-extension freeze consideration Date: August 1, 2021 at 1:41:10 PM PDT To:

It’s a cheap, effective solution. But I think Andrew’s question is whether a solution is needed. If the early boot code knows what hardware it’s running on, it doesn’t need the information. But will t

Section 25.7 of the unprivileged spec says that standard supervisor-level ISA extensions are named using S as a prefix. Section 25.9 says that standard machine-level ISA extensions are named using Zxm

I'm unclear whether you are objecting to 4 byte alignment, or reserving the low bits for something else in the future. In any case, I am not seeing why 4 byte alignment should cause any issue even wit

Greg wrote: You are correct. An editing error, of course. I'm aware of at least one other mistake. Under "Motivation" it currently says: Actually, only some of the AIA's supervisor-level CSRs need swa

John, See below for a couple of small but important typos. Greg The references to bits 57 and 58 in the following two paragraphs are incorrect and should be to bits 58 and 59.

Josh Scheid wrote: For that very reason, we don't intend to allow such extensions to be enabled by a stateen bit. The dual-use case can apply only for extensions that don't have this issue, like Zfinx

This works for pure state enables, but may have issues for extensions that use the field for more than that (the allowed use for, say, the dual-purpose cases above). Particularly if the extension is o

Forwarding to tech-privileged so the hypervisor folks can weigh in...

Hello Greg, Στις 2021-06-28 22:29, Greg Favor έγραψε: Have you considered using mscratch for this instead of defining a new CSR ? Regards, Nick

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