amd64: Make it possible to grow the KERNBASE region of KVA

[markj]

Summary

pmap_growkernel() may be called when mapping a region above KERNBASE,
typically for a kernel module. If we have enough PTPs left over from
bootstrap, pmap_growkernel() does nothing. However, it's possible to
run out, and in this case pmap_growkernel() will try to grow the kernel
map all the way from kernel_vm_end to somewhere past KERNBASE, which can
easily run the system out of memory. This happens with large kernel
modules like the nvidia GPU driver, see PR 265019. I also have a WIP
dtrace provider which needs to map KVA in the region above KERNBASE (to
provide trampolines which allow a copy of traced kernel instruction to
be executed), and it could potentially trigger this scenario.

This change modifies pmap_growkernel() to manage the two regions
separately, allowing them to grow independently. The end of the
KERNBASE region is tracked by modifying "nkpt".

[markj]

sys/amd64/amd64/pmap.c

5051

Is there a reason the second parameter here isn't pmap_pdpe_pindex(end)?

[imp]

Looks sensible to me after the kboot stuff I've done, but the x86 pmap makes me a bit nervous so you might want to get more confirmation from others.

sys/amd64/amd64/pmap.c

5037–5048

It took me a second to puzzle out that this is the 'already mapped in' case so a comment might not be amiss

[alc]

sys/amd64/amd64/pmap.c

5006

Maybe add the word "dynamic" to the first case, i.e., "dynamic kernel memory allocations".

I think that it would be clearer to simply say the uppermost 2GB and avoid the word "negative" that may briefly confuse people.

5027

Add: if (end == 0) return;

5051

No. Once upon a time, the value passed here was nkpt. I changed it to its current value during an ill-fated attempt to eliminate nkpt, before nkpt became a tunable.

[kib]

Should we start passing the start address to pmap_growkernel() as well? I mean, vm_map_insert() can pass the range, instead of the end of the range. Then the end calculation should be more clean, and the interface more future-proof.

[markj]

In D36673#832777, @kib wrote:

Should we start passing the start address to pmap_growkernel() as well? I mean, vm_map_insert() can pass the range, instead of the end of the range. Then the end calculation should be more clean, and the interface more future-proof.

I'm not sure how it would make the calculation of end cleaner. We'd still have to determine whether the range comes before or after KERNBASE, or else I misunderstand.

[markj]

Handle review comments

[kib]

IMO it is cleaner to compare start and not end. Also you can assert that the region does not intersects with kernel.