Implement reclaim_pv_chunk on arm64

[andrew]

Summary

Add reclaim_pv_chunk on arm64. This is based on the amd64 code so should
operate similarly, other than not needing the delayed invalidation.

It has been tested with artificial injection of vm_page_alloc failures.

[alc]

Calling pmap_invalidate_page() on each destroyed mapping makes the pmap_invalidate_all() calls redundant. In case you ever want to duplicate the batching that is performed on amd64, I would suggest commenting out the pmap_invalidate_all() calls with a few words in the comment about the pmap_invalidate_page() calls.

[andrew]

Further testing has found a few bugs in the code.

The main one I'm hitting is the pmap_pv_demote_l2: pv not found KASSERT when I run sort /dev/zero with vm_page_alloc being skipped 0.1% of the time falling into reclaim_pv_chunk (via a fail point).

[alc]

sys/arm64/arm64/pmap.c

1906 ↗

(On Diff #27933)

Is this actually correct? You want to continue if this is a superpage mapping and fall through if it is a 4KB page mapping.

[andrew]

sys/arm64/arm64/pmap.c

1906 ↗

(On Diff #27933)

I think the error is line 1905, it should be pmap_pde. I later perform the l2 to l3 to get the pte, however we need the pde to pass to pmap_unuse_l3.

[andrew]

Clean up and bug fixes based on reviews and testing:

• Remove an unneeded pmap_invalidate_all
• Add a missed PTE_SYNC
• Correctly call pmap_pde
• Use the correct value in pmap_l2_to_l3
• Use pmap_load

This is stable now. While failing 1% of vm_page_alloc calls in get_pv_entry
I can sort /dev/zero and boot to multiuser mode without a panic.

[alc]

sys/arm64/arm64/pmap.c

1970 ↗

(On Diff #28019)

This invalidate is also redundant.

[andrew]

Remove another unneeded pmap_invalidate_all