tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: Status of v1.12 privileged specification

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.

By Allen Baum · #1075 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

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

By Guo Ren · #1074 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

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

By andrew@... · #1073 ·

Re: Status of v1.12 privileged specification

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 |

By Krste Asanovic · #1072 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

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

By Greg Favor · #1071 ·

Re: Status of v1.12 privileged specification

Or just point to a specific spec PDF...

By andrew@... · #1070 ·

Re: Status of v1.12 privileged specification

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)

By Greg Favor · #1069 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

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

By Guo Ren · #1068 ·

Re: Status of v1.12 privileged specification

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

By Allen Baum · #1067 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

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

By Greg Favor · #1066 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

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

By Guo Ren · #1065 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

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

By Guo Ren · #1064 ·

Re: Status of v1.12 privileged specification

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

By Greg Favor · #1063 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

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

By Greg Favor · #1062 ·

Status of v1.12 privileged specification

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

By Greg Chadwick · #1061 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

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

By Guo Ren · #1060 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

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

By Ved Shanbhogue · #1059 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

Note that in general reserved PTE bits that are non-zero - whether due to the bit still simply being reserved, or it corresponding to an unimplemented extension or to a disabled extension (via

By Greg Favor · #1058 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

I didn't mention satp or hgatp, because menvcfg.PBMTE would affect all of them. I agree to make it more explicit: {\tt satp}.Sv32x4 and {\tt hgatp}.Sv32x4 implementation could support Svnapot

By Guo Ren · #1057 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

Guo Hi - I have a few additional question I see you mentioned Sv32 implementations. I am reading it literally as Sv32 as in one of the presently defined modes of satp. I dont see anywhere in the

By Ved Shanbhogue · #1056 ·

261 - 280 of 1334

Home Hashtags Subgroups Terms