whether support Zicfiss or not when MPRV=1

[Qin0803]

in RISCV privilege spec, it describes as follow:

Activating Zicfiss in M-mode is currently not supported.

The MPRV (Modify PRiVilege) bit modifies the effective privilege mode, i.e., the privilege level at which loads and stores execute.

when current privilege mode is M mode, and we can config MPRV MPV MPP to make effective privilege mode is HS/U/VS/VU.
So when MPRV=1, is it illegal to activate zicfiss and use SSPOPCHK, SSPUSH, SSAMOSWAP?

[ved-rivos]

In machine mode, sspush and sspopchk revert to being may-be-ops and these may-be-ops do not make memory accesses. In machine mode samoswap can be invoked, including with mprv set to 1, and the instruction will make a memory access with effective privilege mode determined by priv, mprv, mpv, and mpp.

[ved-rivos]

Based on this query and the prior query about DTSO, I suspect the confusion stems from misunderstanding that when MPRV is set to 1 the instruction itself executes at privilege determined by MPRV. That is not the case. The instructions execute in machine mode even when MPRV is 1, however the the loads and stores, including the implicit accesses to memory management structures, execute with an effective privilege mode that is determined by MPV and MPP

[Qin0803]

thank you very much

in unprivilege spec, it describes ssamoswap that

  if privilege_mode != M && menvcfg.SSE == 0
  raise illegal-instruction exception
  else if S-mode not implemented
  raise illegal-instruction exception
  else if privilege_mode == U && senvcfg.SSE == 0
  raise illegal-instruction exception
  else if privilege_mode == VS && henvcfg.SSE == 0
  raise virtual instruction exception
  else if privilege_mode == VU && senvcfg.SSE == 0
  raise virtual instruction exception
  else
  X(rd) = mem[X(rs1)]
  mem[X(rs1)] = X(rs2)
  endif

Does the privilege_mode referred to here mean the effective privileged mode?

if current privilege mode is M mode, {MPRV,MPV,MPP}=3'b101, menvcfg.sse=0, effective privilege mode is S Mode, What exceptions should be raised? illegal-instruction exception？

[ved-rivos]

Privilege mode in this pseudocode is not the effective privilege mode . It’s the current privilege mode

Btw - mpp is a 2 bit field

[Qin0803]

So if current privilege mode is M mode, MPRV=1,MPV=0,MPP=2‘b01, menvcfg.sse=0, effective privilege mode is S Mode, What exceptions should be raised for SSAMOSAWP? illegal-instruction exception？

[Qin0803]

Similarly, for SSAMOSAWP instructions, current privilege mode is M mode,

1. MPRV=1, MPV=0, MPP=2'b01, effective privilege mode is HS mode, menvcfg.sse=0
2. MPRV=1, MPV=0, MPP=2'b00, effective privilege mode is U mode, senvcfg.sse=0
3. MPRV=1, MPV=1, MPP=2'b00, effective privilege mode is VU mode, senvcfg.sse=0
4. MPRV=1, MPV=1, MPP=2'b01, effective privilege mode is VS mode, henvcfg.sse=0

In the above scenario, is it legal for the ssamo instruction to access memory? should an exception be raised? and what type of exception should be raised?

[ved-rivos]

First, consider the pseudocode for the instruction. In M-mode, assuming S-mode is implemented, the conditions at lines 1, 2, 5, 7, and 8 all evaluate to false. Therefore, the shadow-stack load at line 12 and the shadow-stack store at line 13 (which together implement the atomic swap) are selected.

1. if privilege_mode != M && menvcfg.SSE == 0
2.   raise illegal-instruction exception
3. else if S-mode not implemented
4.   raise illegal-instruction exception
5. else if privilege_mode == U && senvcfg.SSE == 0
6.   raise illegal-instruction exception
7. else if privilege_mode == VS && henvcfg.SSE == 0
8.   raise virtual instruction exception
9. else if privilege_mode == VU && senvcfg.SSE == 0
10.   raise virtual instruction exception
11. else
12.   X(rd) = mem[X(rs1)]
13.   mem[X(rs1)] = X(rs2)
14. endif

The shadow-stack load and store at lines 12–13 execute at the effective privilege mode determined by MPRV, MPV, and MPP when MPRV = 1.

The possible exceptions generated by these shadow-stack memory accesses follow from:

• Section 23.2.3 (Shadow Stack Memory Protection)
• Section 12.3.2 (Virtual address translation process)
• Section 22.5 (Two-stage address translation)

MPRV=1, MPV=0, MPP=2'b01, effective privilege mode is HS mode, menvcfg.sse=0
MPRV=1, MPV=0, MPP=2'b00, effective privilege mode is U mode, senvcfg.sse=0

The resulting exception is either a store/AMO access fault or a store/AMO page fault, depending on:

• satp.MODE
• the state of the PTEs accessed by the shadow-stack load/store
• PMA/PMP checks triggered by implicit PTE walks

MPRV=1, MPV=1, MPP=2'b00, effective privilege mode is VU mode, senvcfg.sse=0
MPRV=1, MPV=1, MPP=2'b01, effective privilege mode is VS mode, henvcfg.sse=0

The resulting exception is either a store/AMO access fault, store/AMO page fault, or a stora/AMO guest page fault, depending on:

• vsatp.MODE and the VS-stage PTEs
• whether G-stage translation is active and the state of G-stage PTEs
• PMA/PMP checks on the implicit memory accesses taken during the VS-stage and/or G-stage walks

In the above scenario, is it legal for the ssamo instruction to access memory?

A shadow-stack load or store may only be performed to a shadow-stack page. In all of the scenarios above, no shadow-stack pages exist because SSE = 0 forces XWR = 010 (the encoding that designates shadow-stack pages) to be reserved. As a result, no explicit shadow-stack load or store will occur. However, implicit memory accesses may still occur due to PTE walks triggered by the attempted shadow-stack operation.

[Qin0803]

in unprivilege and privilege spec, it describes that

Use of Zicfiss in M mode is no supported.

Activating Zicfiss in M-mode is currently not supported.

when current privilege mode is M mode, menvcfg.sse=0, MPRV=1 and effective privilege mode may be S/U/VS/VU, since menvcfg. sse=0, SSAMOSWAP does not support explicit memory access for shadow stack. Why is PTE walk still required?
I don't understand what the role of PTE walk is in this scenario? Can you help explain it clearly?

[chara811]

I have some questions and would appreciate your clarification.
Q1: When executing in M-mode with MPRV=1 and menvcfg.sse=0, what page-table checking rules apply to the implicit memory accesses performed by the ssamoswap instruction?
Q2: At this point, is the ssamoswap instruction affected by menvcfg.sse=0?
Q3: In this scenario, given the PTE.xwr encoding for the implicitly accessed page by the ssamoswap instruction as follows, is it correct to report an exception?
X W R
0 0 1 page fault or access fault?
0 1 0 access fault or page fault?
0 1 1 access fault
1 0 0 access fault
1 0 1 access fault
1 1 0 page fault
1 1 1 access fault

[rock-ifly]

two question on sse=0 && ssamoswap instruction,
Q1： check and report a illeagle Instruction in Decode unit, no implicit access to PTW moudle?
Q2： Decoder didn't check, and implicit access to PTW module, and report a fault. then what fault should be? access fault for ss instruction or page fault since sse=0 and consider it as a usual pte?

[ved-rivos]

Q1: When executing in M-mode with MPRV=1 and menvcfg.sse=0, what page-table checking rules apply to the implicit memory accesses performed by the ssamoswap instruction?

Same as any other load or store

At this point, is the ssamoswap instruction affected by menvcfg.sse=0?

Please see the detailed discussion on this earlier in this issue.

In this scenario, given the PTE.xwr encoding for the implicitly accessed page by the ssamoswap instruction as follows, is it correct to report an exception?

Implicit accesses are either instruction fetches or page table accesses . The shadow stack load/store generated by instructions like ssamoswap and sspush are explicit accessss. A shadow stack load/store.

[ved-rivos]

two question on sse=0 && ssamoswap instruction,

Please see #2408 (comment)

[Qin0803]

Q1: When executing in M-mode with MPRV=1 and menvcfg.sse=0, what page-table checking rules apply to the implicit memory accesses performed by the ssamoswap instruction?

Same as any other load or store

and in unprivilege spec, it describes as follow:

For RV32, SSAMOSWAP.W atomically loads a 32-bit data value from address of a shadow stack location in rs1, puts the loaded value into register rd, and stores the 32-bit value held in rs2 to the original address in rs1. SSAMOSWAP.D (RV64 only) is similar to SSAMOSWAP.W but operates on 64-bit data values.

In your opinion, is SSAMO's page table check the same as LW and SW instructions in the above scenario?
For example, if pte.wxr=3'b111 on the leaf page and all other PMP and PMA checks are met, then implicit access to PTE walk will not raise any exceptions. I understand that the SSAMO instruction can only access the shadow stack. In the scenario of M mode, MPRV=1, and menvcfg. sse=0, if the page table check rules are consistent with other LW or SW instructions, explicit access will occur in the scenario for SSAMO. Is this legal?

[ved-rivos]

For example, if pte.wxr=3'b111 on the leaf page and all other PMP and PMA checks are met, then implicit access to PTE walk will not raise any exceptions.

There seems to be some confusion in your statement when you say “implicit access” . Implicit accesses are used to load a PTE. Once the lead PTE is read using an implicit read to the PTE, the permissions in the PTE are checked. The rules for permission checks are as stated in Section 23.2.3 (Shadow Stack Memory Protection) and Section 12.3.2 (Virtual address translation process)

[Qin0803]

thanks, In the scenario of M mode, MPRV=1, and menvcfg. sse=0, for SSAMO, what exception should be raised if pte.xwr=3'b010 on the leaf page? page fault or access fault?

And in the scenario of M mode, MPRV=1, and menvcfg. sse=0, for SSAMO, if leaf page is only-read page, raise page fault? if leaf page is read-write, read-write-execute, read-execute, or execute-only, raise access fault? is it right?