It's clear from context that the spec intends that SFENCE.VMA with rs1 != x0 be sufficient to purge an invalid PTE from an address-translation cache.  (And the alternative of requiring SFENCE.VMA with rs1=x0 would be preposterous.)

Anyway, I think there is a slight bug in your reasoning in inferring that step 5 of the algorithm circumscribes the set of leaf PTEs.  Although it is true that reaching step 5 implies the PTE is a leaf, nothing says that not reaching step 5 implies a PTE is a non-leaf.  So, a clarification might be in order, but by my reading, there isn't an outright contradiction.

My preferred resolution would be to clarify that non-leaf PTEs have the V bit set.

On Fri, Dec 9, 2022 at 4:10 PM Paul Donahue <pdonahue@...> wrote:

The priv spec says that a leaf PTE can be at any level of the walk.  If you get to step 5 in the "Virtual Address Translation Process" then you've found a leaf PTE. However, if pte.v=0 then you terminate at step 3.  Therefore, a PTE at any level with V=0 (or various reserved encodings) is not a leaf.  (Elsewhere, a leaf PTE is defined to be one with RWX!=000.  But RWX are don't-cares if V=0 so this definition is presumably N/A.)

RISC-V allows caching of invalid translations.  If you're changing a PTE from invalid to valid then you must execute the sfence.vma instruction.  Sfence with rs1!=x0 is defined to apply only to leaf entries. The consequence of all of this is that every time any PTE is changed from invalid (non-leaf) to valid then software must sfence with rs1=x0 which will invalidate all address-translation cache entries for the whole ASID (or all ASIDs).

However, a non-normative comment in the sfence description says that software should execute sfence.vma in accordance with "the previous bullet point."  My reading is that this refers to the immediately previous bullet point which refers to a leaf, but that would contradict the above.

Should the non-normative text be changed to explicitly refer to the third bullet instead of implicitly referring to the fourth bullet?  Or should the definition of leaf also include invalid PTEs (which would reduce large-scale invalidations but might not match existing expectations)?

Thanks,

-Paul