Greetings ! I am sharing a link to a proposal for a Quality of Service (QoS) Identifiers extension. This proposal has been approved by the AR committee to be pursued through the fast-tack extension

> Just to point out that I was pointing out only one specific example of a document (where I recently encountered this) that used section numbering references. It's not the only one, it's all over.

I would suggest talking with Mark to see what he thinks would be a suitable way to both document and communicate this. It's especially not clear what would be an effective way to do the former.

Just to point out that I was pointing out only one specific example of a document (where I recently encountered this) that used section numbering references. It's not the only one, it's all over.

Okay, my motivation is Svpbmt, not Svnapot. I agree to only introduce [31:30] as Svpbmt in the proposal. -- Best Regards Guo Ren

It's clear to me that we should not preemptively reserve space for Svnapot in RV32. Unlike Svpbmt, it's merely an optimization, and it's a less important optimization in RV32 than in RV64. (TLB

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 |

My off-hand thought is that this proposal should either support both Svnapot and Svpbmt (and always steal three PPN bits), and treat them as orthogonal extensions as in RV64. Or decide to only

Or just point to a specific spec PDF...

Using chapter numbers instead of chapter titles for cross-reference purposes seems quite brittle (as you're pointing out) and undesirable. And that constancy of all chapter (and section numbers)

In Sv32x4 mode, supporting Svnapot depends on PBMTE=1. Sv32x4 supporting Svnapot with PBMTE=0 is another proposal that causes Sv32p33 (the current suggestion is Sv32p31). Do you think the current

So " In general every new extension will be a separate new chapter." But of course, but.... will they always be added to the end of the spec, or could they be inserted into the middle? The latter

In the current arch, the 'N' bit exists only as a function of whether the Svnapot extension is implemented or not. Otherwise it is a Reserved bit. And all this is orthogonal to bits [30:29] and

Okay Okay Yes, henvcfg.PBMTE is important. We need henvcfg.PBMTE for V=1. Yes, you are right (menvcfg.PBMTE for V=0, and henvcfg.PBMTE is for V=1) When menvcfg.PBMTE = 1, henvcfg.PBMTE could be 1

When PBMTE=0, the [31:29] are treated as PA bits. When PBMTE=1, the [31] is N-bit and the [30:29] is Svpbmt-bits. Even if there is no svnapot supported, software needs to keep N-bit zero. -- Best

From that version onwards the ratified chapters are frozen other than "typo" corrections and clarifications. The plan is for all Priv-related ratified extensions to be integrated into the Priv

First note that the Svpbmt extension and associated PBMTE bits only affects two bits in a PTE - namely bits [30:29] in your proposal. It has no effect on bit [31] (the 'N' bit) - which is a function

Hello, I appreciate no guarantees are possible but is it anticipated that the final v1.12 of the RISC-V privileged specification will be the v. 20211203 currently listed on the RISC-V website

The bit 31-29 of any Sv32x4 PTE isn't addressing bits when menvcfg.PBMTE is 1. Okay? -- Best Regards Guo Ren

Pleas see few notes inline regards ved Thanks. I think for 2) I would suggested "reserved" instead of "ignored" I suggest reserved instead of ignored. Thanks for agreeing that a change to