Hi Krste, Dumping the entire i-cache via FENCE.I is different. I am requesting invalidation of a single cache block from the i-cache. The Zifencei spec recognizes Zifencei is expensive to

| +tech-privileged  | On Thu, Aug 11, 2022 at 6:48 AM Guy Lemieux <guy.lemieux@...> wrote: | On Wed, Aug 10, 2022 at 10:39 PM Derek Williams <striker@...> wrote: || You say below

My understanding is that the physical address size is implementation dependent. Iif any bit above that is set, it should report an access fault. The ACTs don't specifically test for that now, but

+tech-privileged

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

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

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

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

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

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

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

+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

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

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

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

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

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

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

Below are my comments ...

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