Always check the return value of the arm64 pmap_pte

[andrew]

Summary

Add missing KASSERTs to check the arm64 pmap_pte returns a non-NULL
pointer when we expect it to.

[markj]

I'd put the virtual address in the kassert string.

[kib]

May be, it makes sense to add something like pmap_pte_exists() function that asserts that L3 page exists, and use it instead of repeated KASSERT().

Do we want the same for amd64?

sys/arm64/arm64/pmap.c

1597

I just want to note, that there it is not pte which is not found (how could it be at all?), but the page table page. It is probably confusing for somebody who looks at the pmap code first time.

[alc]

sys/arm64/arm64/pmap.c

1597

In the case of L3 tables, pmap_pte() also returns NULL when the L3 table exists, but the entry for the specified address is invalid.

Previously, we have never required that pmap_qremove() only be performed on valid mappings. On that basis, I would argue against this KASSERT.

[alc]

sys/arm64/arm64/pmap.c

1600

In the same vein to my above comment, the if should not be removed.

[andrew]

Drop pmap_qremove changes

[alc]

In D33509#757401, @kib wrote:

May be, it makes sense to add something like pmap_pte_exists() function that asserts that L3 page exists, and use it instead of repeated KASSERT().

It does. And, there is another advantage to the approach that you suggest. It can take the level as a constant parameter to the inline function, enabling the compiler to specialize the generated code. For example, if we expect there to be an L2_BLOCK, the compiler won't generate code for handling L1_BLOCK or L3_PAGE mappings. I wrote a prototype implementation of pmap_pte_exists() and used it in just the above four cases. Using it in just these four cases, the GENERIC-NODEBUG kernel was 224 bytes smaller.

[alc]

See https://reviews.freebsd.org/D33597 for the pmap_pte_exists() prototype.