Is rs2 a VMID for HFENCE.VVMA?
No. rs2 selects guest ASID; the current VMID comes from virtualization context.
HFENCE.VVMA
RISC-V HFENCE.VVMA Instruction Details
Instruction ManualR-typeHypervisor VS-stage translation fence: rs1 selects guest virtual address, rs2 selects ASID, and later local-hart translations are ordered under the current VMID.
Instruction Syntax
hfence.vvma rs1, rs2
Operand Breakdown
Destination rd: register receiving the operation result.
Source rs1: register holding the first operand.
Source rs2: register holding the second operand.
HMemory Management
Instruction Behavior
HFENCE.VVMA is the Hypervisor extension VS-stage memory-management fence, similar in effect to executing SFENCE.VMA for VS-stage under the current VMID. It orders prior stores already visible to the current hart before later implicit reads for VS-stage address translation under the same VMID; nonzero rs1 specifies a guest virtual address and nonzero rs2 specifies a guest ASID. The current VMID comes from virtualization context, not rs2. rs1=x0 selects all guest virtual addresses, and rs2=x0 selects all ASIDs.
HFENCE.VVMA Hypervisor Translation Decode Animation
VS-stage translation fence: shows SYSTEM encoding, rs1/rs2 scope selection, and local-hart fence ordering without modeling TLB or cache implementation.
rs1
rs2
hfence.vvma
,
31..25
24..20
19..15
14..12
11..7
6..0
0010001
funct7
01011
rs2/ASID
01010
rs1/GVA
000
funct3
00000
rd=x0
1110011
SYSTEM
Hypervisor Translation State
instruction
0x22B50073
opcode
1110011 -> SYSTEM
funct7
0010001 -> HFENCE.VVMA
rs1
a0(x10) -> GVA 0x0000000040001000
rs2
a1(x11) -> ASID 3
VMID
current VMID 7 from virtualization context
scope
a0(x10)=0x0000000040001000; a1(x11)=ASID 3, current VMID=7
fence
order prior stores before later VS-stage implicit reads
complete
local-hart VS-stage translation fence completed
This animation shows only the local-hart translation fence/invalidation semantics defined by the privileged architecture; it does not show OS shootdown protocols, TLB structures, cache flushes, page-walk latency, or platform interrupt mechanisms.
Quick Understanding & Search Notes
HFENCE.VVMA handles VS-stage translation fencing under the current VMID: rs1 selects guest virtual address, rs2 selects ASID, and VMID is not read from rs2.
funct7=0010001, funct3=000, rd=x0, opcode=1110011 identify HFENCE.VVMA.
rs1=x0 selects all guest virtual addresses; rs2=x0 selects all ASIDs.
The current VMID comes from virtualization context; rs2 is not a VMID field.
Common Usage Scenarios
Virtualization memory management
Understand this scenario with real code like «hfence.vvma a1, a2 # a1 = guest virtual address; a2 = ASID».
VS-stage page-table sync
Understand this scenario with real code like «hfence.vvma a1, a2 # a1 = guest virtual address; a2 = ASID».
ASID-scoped fence
Understand this scenario with real code like «hfence.vvma a1, a2 # a1 = guest virtual address; a2 = ASID».
Pre-Use Checklist
Syntax Check
- Confirm the current instruction format is R-type.
- Confirm the operand order matches the example.
Semantic Check
- Ensure the destination register usage is compatible with the calling convention.
- Confirm this is not the lower-level form of a pseudo-instruction expansion.
Pitfalls / Common Confusions
rs1 is a guest virtual address; do not confuse it with HFENCE.GVMA GPA>>2.
rs2 is a guest ASID, not a VMID; the current VMID comes from virtualization context.
The effect is local to the current hart; other harts need their own matching synchronization.
HFENCE.VVMA is a VS-stage translation fence, not a generic data-cache flush.
Executability is constrained by the Hypervisor extension and privileged-mode rules.
FAQ
Do HFENCE.VVMA and HFENCE.GVMA select the same address kind?
No. HFENCE.VVMA uses guest virtual address; nonzero HFENCE.GVMA rs1 uses GPA>>2.