tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Topics Expanded Polls

Export Group Data

Between

and

Re: [RISC-V] [tech-cmo] [riscv-CMOs:master] reported: Can CMO extension support icache management? #github #risv #cmos

+tech-privileged

By mark · #1095 ·

Re: [RISC-V] [tech-virt-mem] Help needed on physical address issues

Thanks Scott, Allen and Ved for your clarification! Still one little question: What happens when MMU is disabled (VA=PA) and bit [63:56] is not zero? Still report Access Fault? Or are we assuming the

By Ke Chai · #1094 ·

Re: [RISC-V] [tech-virt-mem] Help needed on physical address issues

It works on virtual addresses, and when MMU is disabled, virtual=physical. As I said, not "simply" ignored..

By Allen Baum · #1093 ·

Re: [RISC-V] [tech-virt-mem] Help needed on physical address issues

I think the pointer-masking extension would ignore upper bits in a virtual address - but only for the canonicality check. Of course, when virtual memory systems are not enabled then they are the same

By Ved Shanbhogue · #1092 ·

Re: [RISC-V] [tech-virt-mem] Help needed on physical address issues

Note that the (unratified) pointer masking extension would permit upper bits to be ignored (but not "simply" be ignored).

By Allen Baum · #1091 ·

Re: [RISC-V] [tech-virt-mem] Help needed on physical address issues

Ignoring the high bits is not acceptable. It must take an access fault. I agree the specs do not make this entirely clear.

By Scott Johnson · #1090 ·

Re: [RISC-V] [tech-virt-mem] Help needed on physical address issues

Hi Greg, Thanks for replying! I am sure your answer about the RISC-V Unified Discovery perfectly answered my question 2. In my current implementation, bit [55:50] is simply ignored, which means my

By Ke Chai · #1089 ·

Re: [RISC-V] [tech-virt-mem] Help needed on physical address issues

The way to view this matter is that PA's are full 56-bit zero-extended values. It is up to PMAs to, for example, mark the top six bits of PA space as a big 'vacant' region that results in an Access

By Greg Favor · #1088 ·

Re: [RISC-V] [tech-virt-mem] Help needed on physical address issues

+tech-privileged The virt-mem list is quiescent and will go away shortly. Please send questions like this to the governing committee (priv). I have plus'ed them in. Mark

By mark · #1087 ·

Re: Fast-track extension proposal V2 for "Sv32 Svpbmt"

Update above with Allen help, to make the description flow better: Svpbmt32 support is being added to allow the two highest bits of a PTE to be used as PBMT instead of PA[33:32] for Sv32. The S-mode

By Guo Ren · #1086 ·

Re: Fast-track extension proposal V2 for "Sv32 Svpbmt"

Okay. Okay. Okay. Okay, I would try; see below. Okay Okay, I will fix it. \subsection{Svpbmt32} .\label{sec:translation} Svpbmt32 support is being added to allow the two highest bits of

By Guo Ren · #1085 ·

Re: Fast-track extension proposal V2 for "Sv32 Svpbmt"

Yes. The more proper way to say this is that PBMT support is being added (versus saying that an existing extension is being added). Maybe say "... to allow use of the two highest bits instead as

By Greg Favor · #1084 ·

Re: Fast-track extension proposal V2 for "Sv32 Svpbmt"

Sorry for the typo, It should be: "The satp and hgatp depend on menvcfg.PBMTE, and the vsatp depends on henvcfg.PBMTE." Good point. I would try; see below. Svpbmt32 is good, I would put it

By Guo Ren · #1083 ·

Re: Fast-track extension proposal V2 for "Sv32 Svpbmt"

The preceding, as worded, could be simplified down to "The satp, hgatp, and vsatp CSRs all depend on henvcfg.PBMTE." But the above sentence is not correct in that satp does not depend on

By Greg Favor · #1082 ·

Re: Fast-track extension proposal V2 for "Sv32 Svpbmt"

Hi Greg, Thx for the review, here is my reply. Agree, I would put it in the Svpbmt chapter as a separate section. My meaning here is satp with V=0 or V=1, but I agree using vsatp is clearer. vsatp

By Guo Ren · #1081 ·

Re: Fast-track extension proposal V2 for "Sv32 Svpbmt"

Below are my comments ...

By Greg Favor · #1080 ·

Fast-track extension proposal V2 for "Sv32 Svpbmt"

Hi, Here is the second version of the proposal. The current Privileged specification only defines Svpbmt for RV64 with the 62-61 bits in PTE, and there are no spare highest bits in rv32 for 34-bit

By Guo Ren · #1079 ·

Fast-track extension proposal for QoS Identifiers

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

By Ved Shanbhogue · #1078 ·

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 Greg Chadwick · #1077 ·

Re: Status of v1.12 privileged specification

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.

By Greg Favor · #1076 ·

241 - 260 of 1334

Home Hashtags Subgroups Terms