josecm
commented
1 year ago @yangye-rvcore I must say I disagree with your analysis. Note that the hpt_switch of line 27 is reverting the mappings back to the original ones. And exactly because the hpt_switch is only changing the GPA -> HPA mappings, invalidating the translation caches for that stage would make the read value the same as the original value.
The spec does not preclude invalidating the caching of of GVA -> GPA trsnlations on a hfence.gvma, or of GPA -> HPA on a hfence.vvma, as long as when those instructions are executed the correct translations are invalidated. It really depends on the implementation. Let's think of a simple implementation that only caches direct GVA -> HPA in its TLBs. Executing either of the two instructions would result in the TLB entry being invalidated, therefore, both stages. An implementation might also chose to fully invalidate the whole TLB when any hfence is executed, and still be compliant.
Nevertheless, I now notice there might be something wrong in the check of line 26. Because the hfence_vvma in line 25 might only invalidate GVA -> GPA mappings, line 26 hldv does not necessarily need to return the value for the mapping after the switch (it can, but it does not need to).
yangye212
I have a question that is the hfence_gvma instruction at line 29 of fence_test.c. TLB store the PTEs that gva maps to hpa. Hfence_gvma control guest-physical memory-management data structures, in other words, executing hfence_gvma instruction will flush the PTEs that gpa maps to hpa. So when the hfence_gvma at line 29 of fence_test.c is executed, TLB still retains the PTEs that gva maps to hpa before hpt_switch. I think the code of line 30 of fence_test.c should be cond &= hlvd(vaddr) != val. This is my current understanding, and I hope it can be confirmed. Thank you!