Clarify SFENCE.VMA for invalid virtual addresses

[Timmmm]

The existing wording sounds like the instruction is required to have no effect, but SFENCE.VMA is allowed to over-fence, so it still can have an effect even for invalid addresses.

[aswaterman]

This isn't consistent with the rest of the description of SFENCE.VMA, which only mentions the over-fencing property once, rather than mentioning it in every subcase.

For example, the previous paragraph, which describes the behavior when rs1 != x0 and rs2 != x0, says "the fence orders only reads and writes made to leaf page table entries corresponding to the virtual address in rs1", rather than saying something like "the fence orders only [...] and might also have other effects".

Also, the proposed wording invites new questions: what is the set of effects that is valid? Is it limited to over-fencing, or might the instruction change architectural state in other ways?

So I think the current description is easier to digest while remaining accurate. Over-fencing is implicitly always allowed because implementations are allowed to evict lines from the TLB at any point at any reason. (This is why the over-fencing remark is non-normative.) So it's completely correct to say that SFENCE.VMA does nothing when rs1 is invalid, since, say, flushing the whole TLB when rs1 is invalid is indistinguishable from the SFENCE.VMA doing nothing, but the implementation then deciding to flush the TLB of its own volition immediately afterwards.

[Timmmm]

Hmm very good point. Though I still think it's weird to say it has no effect, when it actually might do incidentally. Perhaps just moving the NOTE next to this statement would make it better? So it reads like "it has no effect .... But..."

If the value held in _rs1_ is not a valid virtual address, then the
SFENCE.VMA instruction has no effect. No exception is raised in this
case.

[NOTE]
====
It is always legal to over-fence, e.g., by fencing only based on a
subset of the bits in _rs1_ and/or _rs2_, and/or by simply treating all
SFENCE.VMA instructions as having _rs1_=`x0` and/or _rs2_=`x0`. For
example, simpler implementations can ignore the virtual address in _rs1_
and the ASID value in _rs2_ and always perform a global fence. The
choice not to raise an exception when an invalid virtual address is held
in _rs1_ facilitates this type of simplification.
====

When __rs2__≠``x0``, bits SXLEN-1:ASIDMAX of the value held
in _rs2_ are reserved for future standard use. Until their use is
defined by a standard extension, they should be zeroed by software and
ignored by current implementations. Furthermore, if
ASIDLEN<ASIDMAX, the implementation shall ignore bits
ASIDMAX-1:ASIDLEN of the value held in _rs2_.

[aswaterman]

I think you threaded the needle!

[Timmmm]

Thanks!