Behavior of SFENCE.VMA, HFENCE.GVMA, and HFENCE.VVMA instructions when the Smsdid extension is implemented

[chara811]

Do the SFENCE.VMA, HFENCE.GVMA, and HFENCE.VVMA instructions require an sdid comparison, where the sdid is sourced from the CSR mmpt register?

[ved-rivos]

Please see section 3.4 "Extension to Behavior of Memory-Management Fences"

[chara811]

I've reviewed the spec, but I want to avoid any misunderstanding. So, does the description below imply that an sdid comparison is performed, and that the sdid is sourced from the CSR mmpt register?

The ASID and VMID arguments of these instructions correspond to the ASIDs and VMIDs that are active within the current supervisor domain, which is identified by the SDID field of the CSR
mmpt. The SDID augments the ASID and VMID values to form the effective identifiers used by these
instructions

[rsahita]

This is stating that An effective S/HS-level ASID can be considered to be the combination of the SDID with the S/HS-level ASID. Likewise, an effective VS-level ASID can be considered to be the combination of the SDID withthe VS-level ASID. Similarly, An effective VMID can be considered to be the combination of the SDID with the VMID.So the important aspect is that the ASID or VMID is unique within a SD context and may be non-unique across SDs so the combination along with SDID must be considered as the effective ASID or VMID. RaviSent from my cell phone. Pardon the brevity. On Apr 13, 2026, at 20:55, chara811 ***@***.***> wrote:chara811 left a comment (riscv/riscv-smmtt#279) I've reviewed the spec, but I want to avoid any misunderstanding. So, does the description below imply that an sdid comparison is performed, and that the sdid is sourced from the CSR mmpt register? The ASID and VMID arguments of these instructions correspond to the ASIDs and VMIDs that are active within the current supervisor domain, which is identified by the SDID field of the CSR mmpt. The SDID augments the ASID and VMID values to form the effective identifiers used by these instructions —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[chara811]

So, since the same ASID or VMID might exist in different SDs, to flush data for a specific SD domain, I need to first switch the mmpt back to the corresponding sdid. This ensures the correctness of the sfence or hfence instructions. Is that correct?

[rock-ifly]

This is stating that An effective S/HS-level ASID can be considered to be the combination of the SDID with the S/HS-level ASID. Likewise, an effective VS-level ASID can be considered to be the combination of the SDID withthe VS-level ASID. Similarly, An effective VMID can be considered to be the combination of the SDID with the VMID.So the important aspect is that the ASID or VMID is unique within a SD context and may be non-unique across SDs so the combination along with SDID must be considered as the effective ASID or VMID. RaviSent from my cell phone. Pardon the brevity. On Apr 13, 2026, at 20:55, chara811 @.***> wrote:chara811 left a comment (riscv/riscv-smmtt#279)
I've reviewed the spec, but I want to avoid any misunderstanding. So, does the description below imply that an sdid comparison is performed, and that the sdid is sourced from the CSR mmpt register?

The ASID and VMID arguments of these instructions correspond to the ASIDs and VMIDs that are active within the current supervisor domain, which is identified by the SDID field of the CSR
mmpt. The SDID augments the ASID and VMID values to form the effective identifiers used by these
instructions

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

Thank you for your reply. @rsahita please help to make it clear as the following description.

I am stuck at this situation. There are 4 PEs in a multi-core SoC, pe0 and pe1 work at SD0(sdid=0) while pe2 and pe3 work at SD1(sdid=1).
Q1: will the tlb entry of peX store the sdid vaule? or peX always use the mmpt.sdid? what is the better choice, Q1A or Q1B?
Q1A: tlb entry store the sdid, then the SoC can switch to different SD without flush the tlb, the sdid is like the vmids/asid
Q1B: peX use the mmpt.sdid as the current SD indentifier. then the peX must flush its own tlb entries when swith the SD.

Q2: we think Q1A is better, and then Q2B is a better choice, right?
step1: if SD0, vmid0, asid0 wants to sfence by VA0, a instruction with sfence rs1=va0, rs2=asid0 is executed, and a DVM operation with (sdid0, vmid0, asid0, va0) is broadcasted to SD1.
step2: SD1 get the DVM operation, what should SD1 do? execute sfence by compare sdid/vmid/asid/va, right?
Q2A: compare the incoming sdid0 with sdid1(from the pe2 or pe3 mmpt CSR) ?
---- this seems aligned with Q1B, always use the mmpt.sdid as the current SD identifier
Q2B: compare the incoming sdid0 with sdidX(from the sdid field of the pe2 or pe3 tlb entry) ?