What address does rs1 hold for HFENCE.GVMA?
When rs1 is nonzero it holds the guest physical address shifted right by 2 bits (GPA>>2); rs1=x0 selects all guest physical addresses.
HFENCE.GVMA
RISC-V HFENCE.GVMA Instruction Details
Instruction ManualR-typeHypervisor G-stage translation fence: rs1 selects GPA>>2 scope, rs2 selects VMID, ordering later local-hart G-stage implicit translations.
Instruction Syntax
hfence.gvma 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.GVMA is the Hypervisor extension G-stage memory-management fence. It orders prior stores already visible to the current hart before later implicit reads for G-stage address translation; nonzero rs1 contains the guest physical address shifted right by 2 bits (GPA>>2), and nonzero rs2 specifies a VMID. rs1=x0 selects all guest physical addresses, and rs2=x0 selects all VMIDs. It affects only the local hart; it is not a generic data-cache flush or a concrete TLB-entry walk.
HFENCE.GVMA Hypervisor Translation Decode Animation
G-stage translation fence: shows SYSTEM encoding, rs1/rs2 scope selection, and local-hart fence ordering without modeling TLB or cache implementation.
rs1
rs2
hfence.gvma
,
G-stage Scope
rs2 selects VMID directly; nonzero rs1 holds GPA>>2.
31..25
24..20
19..15
14..12
11..7
6..0
0110001
funct7
01011
rs2/VMID
01010
rs1/GPA>>2
000
funct3
00000
rd=x0
1110011
SYSTEM
Hypervisor Translation State
instruction
0x62B50073
opcode
1110011 -> SYSTEM
funct7
0110001 -> HFENCE.GVMA
rs1
a0(x10) -> GPA>>2 0x0000000020000400
rs2
a1(x11) -> VMID 5
scope
a0(x10)=GPA>>2 0x0000000020000400 (GPA 0x0000000080001000); a1(x11)=VMID 5
fence
order prior stores before later G-stage implicit reads
complete
local-hart G-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.GVMA is a G-stage translation fence: rs1 selects address scope with GPA>>2, rs2 selects VMID scope, and the effect is local to the current hart.
funct7=0110001, funct3=000, rd=x0, opcode=1110011 identify HFENCE.GVMA.
rs1=x0 selects all GPAs; rs2=x0 selects all VMIDs.
It orders G-stage implicit translation reads, not data-cache or instruction-cache flushing.
Common Usage Scenarios
Virtualization memory management
Understand this scenario with real code like «hfence.gvma a1, a2 # a1 = GPA >> 2; a2 = VMID».
G-stage page-table sync
Understand this scenario with real code like «hfence.gvma a1, a2 # a1 = GPA >> 2; a2 = VMID».
VMID-scoped fence
Understand this scenario with real code like «hfence.gvma a1, a2 # a1 = GPA >> 2; a2 = VMID».
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
Nonzero rs1 holds GPA>>2, not a guest virtual address and not an unshifted GPA.
rs2 selects VMID; rs2=x0 means all VMIDs.
The effect is local to the current hart; other harts need their own matching synchronization.
HFENCE.GVMA is a G-stage translation fence, not a generic data-cache flush or page-table-walk simulation.
Executability is constrained by the Hypervisor extension and privileged-mode rules.
FAQ
Does HFENCE.GVMA affect all harts?
No. The official semantics are local to the current hart; multi-hart synchronization needs other harts to execute their own synchronization sequence.