Page MenuHomeFreeBSD

arm64: Handle changing self-referential DMAP pages
ClosedPublic

Authored by andrew on Mar 19 2026, 4:04 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Apr 19, 2:07 PM
Unknown Object (File)
Sat, Apr 18, 5:45 PM
Unknown Object (File)
Sat, Apr 18, 5:45 PM
Unknown Object (File)
Sat, Apr 18, 3:22 PM
Unknown Object (File)
Sat, Apr 18, 10:14 AM
Unknown Object (File)
Sat, Apr 18, 2:00 AM
Unknown Object (File)
Fri, Apr 17, 7:55 PM
Unknown Object (File)
Wed, Apr 15, 1:35 AM
Subscribers

Details

Summary

Support changing the property of a DMAP page that holds it's own page
table entry.

Because we need to perform a break-before-make sequence to change the
properties of pages a page that also holds it's own page table entry
will fault in the make part of the sequence.

Handle this by mapping the page with a temporary mapping as we already
do when demoting a superpage.

Sponsored by: Arm Ltd

Diff Detail

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

Event Timeline

sys/arm64/arm64/pmap.c
8384

IMO it makes more sense to reserve a page frame and use it there instead of allocating and then freeing KVA, similar to the CMAPs on amd64. You would avoid the weird EINVAL from below.

sys/arm64/arm64/pmap.c
8384

I agree. It would be better to avoid error cases when updating the kernel pmap.

sys/arm64/arm64/pmap.c
8384

We already return a failure if demote fails above.

sys/arm64/arm64/pmap.c
8384

We can remove the first error path in pmap_demote_l2() by implementing kib's suggestion. The second one won't happen for kernel maps. The third one is quite unlikely to happen for kernel maps given that we use VM_ALLOC_INTERRUPT to allocate the new L3 page. I still think it's better to avoid the failure mode here.

This revision is now accepted and ready to land.Fri, Apr 10, 2:33 PM