Page MenuHomeFreeBSD

arm64: Move cpu0 dpcpu and msgbuf to the DMAP
ClosedPublic

Authored by andrew on Nov 23 2023, 2:20 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Apr 22, 4:17 PM
Unknown Object (File)
Tue, Apr 22, 5:51 AM
Unknown Object (File)
Mon, Apr 21, 12:28 PM
Unknown Object (File)
Mon, Apr 21, 5:10 AM
Unknown Object (File)
Mon, Apr 21, 4:41 AM
Unknown Object (File)
Sat, Apr 19, 8:40 PM
Unknown Object (File)
Thu, Apr 17, 2:46 AM
Unknown Object (File)
Wed, Apr 16, 8:06 PM
Subscribers

Details

Summary

When these are allocated we already have the DMAP region mapped. Search
for the largest region and use this to hold these.

Pr: 269726
Sponsored by: Arm Ltd

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

What's the motivation behind this?

It's part of a general clean up of the early page table creation code. In this case I'm trying to reduce the size of the 6M of extra virtual address space added in create_pagetables in locore.S as it may not be usable memory, e.g. if the kernel and modules are loaded at the end of physical memory and use almost all the 64M allocation in loader.efi.

It looks like it also fixes https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269726

sys/arm64/arm64/pmap.c
1360

Other variables in this function which represent physical addresses have a suffix of "_pa", not "_phys".

1399

Don't you need to rebuild the physmap and compute largest_phys after this point? Otherwise, how is it guaranteed that the dmesg/dpcpu allocations are not stomping over the region we're using to bootstrap?

1406
sys/arm64/arm64/pmap.c
1368

Some explanation of "why" here would be nice.

I'd also like to see a little more on the why we need to find such memory in the comment.

sys/arm64/arm64/pmap.c
1393

why delete this?

markj added inline comments.
sys/arm64/arm64/pmap.c
1367
This revision is now accepted and ready to land.Fri, Apr 18, 2:19 PM
This revision was automatically updated to reflect the committed changes.