pmap_remove_l3() already performs the requisite invalidation. (This is
in contrast with amd64, where pmap_remove_ptes() only invalidates global
mappings.) In the long term it might be preferable to do what amd64
does, but for now just get rid of the extra code.
On SMP systems the invalidate_range()'s here would seem to be more efficient since you can batch up the IPI's. I almost wonder if it wouldn't even be better to just do a single invalidate_range at the end instead of dealing with va_next and trying to be perfect about avoiding invalidation of ranges that weren't mapped. The only other call to pmap_remove_l3() in pmap_ts_referenced() is also followed by a call to pmap_invalidate_page(), so I wonder if removing pmap_invalidate_page() wouldn't be the better change?
(We discussed this further on #freebsd-riscv.) I agree and will hold off on this change; instead, following the superpage patches I'll change pmap_remove_l3() so that the caller handles invalidation. This will be part of a broader cleanup of pmap invalidation. RISC-V is a bit special in that we should perform a local TLB invalidation even after overwriting an invalid PTE: the implementation is permitted to cache invalid addresses, so a failure to issue an sfence.vma can result in a spurious fault following a pmap_enter(). We do handle such faults in pmap_fault_fixup(), but obviously it's preferable to avoid them in the first place.