expanding amd64 past the 1TB limit

[Chris Torek]

>The changes associated with pt_p, pd_p and p4_p are cosmetic and IMHO
>detract from the meat of the change.
>
>My preference would be for the cosmetic changes to be committed
>separately from the changes that rearrange the KVA.

I can split these out.

>> -       DMPDPphys = allocpages(firstaddr, NDMPML4E);
>> +       ndmpdpphys = howmany(ndmpdp, NPML4EPG);
>
>NPDPEPG should be used here instead of NPML4EPG even though they are
>numerically identical.

Ah, late-night editing thinko. :-)

>> + * KERNBASE.  Similarly, if KMPL4I < (base+N), extra level 4 PDEs are
>
>level 2 PDE's, right?

Er, yes (and L1s of course), and that should be < (base+N-1).

The idea here is that if for some reason KERNBASE were "in the
middle" of the NKPML4E entries, you'd have, at least initially
when only a few things are valid at VM_MIN_ADDRESS and at
KERNBASE:

             L4 table    L3 page              ... mapping:
            +-------+                         VM_MIN_KERNEL_ADDRESS
  KPMLBASE  |   * ---> [valid at 0 --> L2, then all-0s]
            +-------+
            |   * ---> [all-0s]
            +-------+
            |   * ---> [all-0s]
            +-------+
            |  ...  |
            +-------+                         KERNBASE
    KPML4I  |   * ---> [mostly-0s; the KDPDI'th --> L2]
            +-------+
  base+N-1  |   * ---> [all-0s]
            +-------+                         VM_MAX_KERNEL_ADDRESS

but then eventually allocating something between KERNBASE and
VM_MAX_KERNEL_ADDRESS would cause that last page of "all-0s" to
get filled in, etc.  Of course KPML4I should be the very last
(511'th) L4 table entry always, unless the kernel grows really
huge :-)

I'll fix the comments in the split-up patch.

Chris