amd64 pmap: More unification for psind = 1 vs 2 in pmap_enter_largepage().

[kib]

Summary

Move

• pkru check
• wait for page alloc
• wire accounting update
• asserting allowed updates for valid mappings

out of psind conditions.

Also add assert that psind references supported page size.

[The diff was generated before r365951]

[alc]

sys/amd64/amd64/pmap.c

6547

PG_FRAME -> PG_PS_FRAME

(This is sufficient to exclude the PAT bit from the comparison. There is no reason to handle 1 GB pages specifically.)

6568–6569

I don't understand this sentence. We often modify the paging structure, which I interpret to mean page table, with only a read lock on the vm map.

[kib]

sys/amd64/amd64/pmap.c

6568–6569

Yes, it is (no longer) valid. Initial version of the largepage change instantiated mappings on mmap(2). My reasoning was that it does not make much sense to wait for access to the mmaped region where the pages are essentially wired.

After discussion with Mark I moved the instantiation to fault handler but the comment was not properly adjusted.

I deleted it now.

[kib]

Remove no longer valid comment.
Compare only phys addresses when asserting allowed change in large mapping.

[alc]

sys/amd64/amd64/pmap.c

6510

Why rewalk the page table from the root? Use mp in the same way as below (lines 6531-6532) to more cheaply calculate the pdpe.

6515

In this case, there is no need to rewalk the page table from the root, i.e., repeat the pmap_pml4e(). pmap_pml4e_to_pdpe() can be used.

[kib]

Avoid page table rewalking, as suggested by alc.

[alc]

Is it documented anywhere what can versus can't be done to a non-transparent mapping?

sys/amd64/amd64/pmap.c

6548

pde -> origpte

[kib]

In D26513#590433, @alc wrote:

Is it documented anywhere what can versus can't be done to a non-transparent mapping?

No, there is no such documentation. Effectively we only allow permissions changes and emulate fake wiring status.

Even userspace API docs are not yet written. Arguably it is still premature.