Page MenuHomeFreeBSD

riscv: smarter DMAP construction

Authored by mhorne on May 23 2024, 7:53 PM.
Referenced Files
F88688390: D45328.id139379.diff
Thu, Jul 18, 7:13 AM
Unknown Object (File)
Sun, Jul 14, 10:41 AM
Unknown Object (File)
Sat, Jul 6, 8:37 PM
Unknown Object (File)
Sat, Jul 6, 5:55 PM
Unknown Object (File)
Tue, Jul 2, 8:52 PM
Unknown Object (File)
Tue, Jul 2, 8:51 PM
Unknown Object (File)
Tue, Jul 2, 8:51 PM
Unknown Object (File)
Tue, Jul 2, 8:51 PM



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.

Diff Detail

rG FreeBSD src repository
Lint Not Applicable
Tests Not Applicable

Event Timeline


What prevents underflow in the subtraction here?


I am most likely going to change the behaviour here.


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

mhorne marked 2 inline comments as done.
mhorne edited the test plan for this revision. (Show Details)

Handle feedback from markj.

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

markj added inline comments.

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

This revision is now accepted and ready to land.Jun 9 2024, 10:24 PM

Drop unneeded warning print.

This revision now requires review to proceed.Jun 14 2024, 5:51 PM
mhorne added inline comments.

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.

This revision is now accepted and ready to land.Thu, Jun 20, 3:56 PM
This revision was automatically updated to reflect the committed changes.
mhorne marked an inline comment as done.