Fixes to page table page mapping

[alc]

Summary

We need to add barriers between page table page initialization and mapping. See the comment added to _pmap_alloc_l3(). (Both Darwin and Linux do this.)

Simplify page table page mapping in pmap_growkernel(). In particular, we don't need to perform a TLB invalidation. There is nothing to invalidate.

[alc]

Add a comment to pmap_demote_l2_locked() about pmap_fill_l3().

[markj]

Suppose we pmap_enter() a zero-filled page. How do we guarantee that the PTP update isn't visible to another CPU before the page's contents are zero'ed?

[alc]

In D21126#459279, @markj wrote:

Suppose we pmap_enter() a zero-filled page. How do we guarantee that the PTP update isn't visible to another CPU before the page's contents are zero'ed?

The validation of the zero-filled page requires the object lock, which is released before the mapping is created, and the mapping requires the pmap lock. In other words, we have a one-way barrier, a store release, that orders the zero-filling, and a one-barrier, a load acquire, that orders the page table update. As long as these two "special" accesses are completed in program order, we have guaranteed ordering between the zero-filling and the PTP update. (I believe but am not certain that ARMv8 originally guaranteed sequential consistency among "special" accesses, i.e., acquires and releases.)

This argument won't apply to pmap_qenter(). However, the dsb performed by the arguably redundant TLB invalidation at the end of pmap_qenter() will significantly reduce the size of the window in which problematic reordering of the zeroing and PTP update could occur.