There will be an annual release of all the specs, which can be reference as Andrew says. But, use the extension name as a key. If the extension doesn't have a name, we'll give it a name. Krste | On Tu

The current PMP checks isolate M mode from lower-privilege modes. In terms of software compatibility and profiles, for U/S/HS modes - which are not aware of PMPs - the discussion can be pushed to plat

For the case of the Alibaba vector extension based on pre-frozen 0.7.1 draft, we had already agreed to use the -X custom extension name for this, so there is no confusion about this being a RISC-V sta

The syntax is fine, but the version number was meant for pre-ratified extensions during development, not for final production use. There is a related issue of how the support is managed upstream. Ther

Yes, that was the plan, Krste | On Thu, Aug 26, 2021 at 8:31 PM Kito Cheng <kito.cheng@...> wrote: | For non-priverage extension, toolchain can control version for each | extension by ISA strin

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 P

Jessica and Greg are right - I was wrong about the existing use of "p". Actually, elsewhere in CSR names, we haven't really used "Hungarian Notation" at all: https://en.wikipedia.org/wiki/Hungarian_no

| I didn't understand the point of #3) Alignment | If I understand the proposed format (*not* a given), fields are either always a byte long, or are byte - not word - aligned. Fields aren't padded, as

Some input: 1) Read-only or writeable. For super-minimalist spec, it's fine to only define a CSR number and say it holds the config address and every thing else is TBD. This at least allows folks to g

| On Mon, May 31, 2021 at 11:17 AM John Hauser <jh.riscv@...> wrote: | There is nothing novel about the situation I'm describing. I'm certain | that hypervisors have emulated such devices in ju

RNMI has separate exception vector from regular exceptions. Krste | Oops - I reread that - Paul is correct; nmcause is not modified. The handler has no guaranteed way of handling an exception. | IT ca

| I would like a clarification on whether this replaces the existing NMI, or are you saying there are two different things, NMI and RNMI? I doubt it, but I wanted to check. Enhances NMI by adding stat

M-mode or HS-mode can always create equivalent for S-mode. I don't believe hardware delegation makes sense for NMIs. Krste | I'd expect that S-mode software will also want to be able to receive RNMIs,

| I'll jump in with a few more. :) | From an architectural point of view, I don't like the fact that an NMI blocks further NMI until it leaves its handler. There may be NMIs that can save | the state

| Even though this is hot off the press, I'll jump in with a few small comments: | - In mnstatus, shouldn't there also be a bit like the mstatus.MPV bit (for when the H extension is implemented and en

Current RISC-V specs only have a non-resumable NMI definition. The following proposal would add resumable NMI support. This was one of the features requested for priv 1.12 or RVA/RVM22. This is up for

The basic design is already laid out for expansion to Sv57 and Sv64 following the template of fewer bits, Krste

Yes, should share the flag. Code that has an outer check for saturation to check if re-scaling needed, won’t want to care whether it was caused by scalar or vector routine. Krste

mcycle is considered part of the HPM facility. If the clock to the core is not running, mcycle does not need to increment. If part of the core is being clocked (including just mcycle), then mcycle can