riscv: smarter DMAP construction

[mhorne]

Summary

Currently we create the DMAP by mapping the entire range between the
smallest and largest physical memory addresses with L1 superpages. This
is obviously overkill, and we may end up mapping all kinds of ranges that
are not real memory.

In the case of the HiFive Unmatched (obsolete hardware), there is an
errata resulting in faults when a TLB mapping spans PMP (firmware)
protection regions. So, when our DMAP mapping spans into the memory
reserved by OpenSBI, we get a fatal fault. This highlights the need to
be smarter here.

Therefore, let's attempt to build the DMAP a little more correctly by
walking the physmap array and mapping each range individually. It is not
perfect in that we still only respect the range to a 2MB granularity,
but this can be improved on in the future.

Test Plan

An example physical memory layout (VisionFive v2 SBC):

Physical memory chunk(s):
  0x40000000 - 0x23fffffff,  8192 MB (2097152 pages)
Excluded memory regions:
  0x40000000 - 0x401fffff,     2 MB (    512 pages) NoAlloc NoDump
  0xf6800000 - 0xf961bfff,    46 MB (  11804 pages) NoAlloc

And the corresponding DMAP section of vm.pmap.kernel_maps:

Direct map:
0xffffffd000200000-0xffffffd200000000 rw-s- PMA 7 511 0

...reflecting the 8GB of memory, with the 2MB "NoDump" section excluded from the mapping (7*1GB + 511*2MB).

I intend to perform some more exhaustive testing of the different edge-cases we might encounter.

[markj]

sys/riscv/riscv/pmap.c

575

586

What prevents underflow in the subtraction here?

[mhorne]

sys/riscv/riscv/pmap.c

577–640

I am most likely going to change the behaviour here.

761–764

FYI, this stated limitation is no longer true with the use of subr_physmem.c.

[mhorne]

Handle feedback from markj.

Don't skip small physmap ranges (less than 2MB).

[markj]

sys/riscv/riscv/pmap.c

588

Why should we expect pa to be aligned to 2MB?

593

[mhorne]

Drop unneeded warning print.

[mhorne]

sys/riscv/riscv/pmap.c

588

We shouldn't. It was more of a debugging print, which I've dropped. But as I've noted in the commit message, this version of the function will map things with a 2MB granularity.