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.
Details
- Reviewers
alc kib jhb br mhorne063_gmail.com
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 21819 Build 21087: arc lint + arc unit
Event Timeline
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.