arm64: Handle changing self-referential DMAP pages
ClosedPublic
Actions

Authored by andrew on Mar 19 2026, 4:04 PM.

Details

Reviewers

manu
alc
kib
markj

Group Reviewers

arm64

Commits

rG580958427536: arm64: Handle changing self-referential DMAP pages

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.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

andrew created this revision.Mar 19 2026, 4:04 PM

Herald added a reviewer: manu. · View Herald TranscriptMar 19 2026, 4:04 PM

Herald added subscribers: emaste, imp. · View Herald Transcript

andrew requested review of this revision.Mar 19 2026, 4:04 PM

Harbormaster completed remote builds in B71524: Diff 173913.Mar 19 2026, 4:04 PM

andrew added a child revision: D55944: arm64: mte: cleanup cache register definitions.Mar 19 2026, 4:04 PM

andrew added reviewers: alc, kib, markj.Mar 19 2026, 4:25 PM

kib added inline comments.Mar 19 2026, 10:54 PM

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.

markj added inline comments.Mar 20 2026, 5:11 AM

sys/arm64/arm64/pmap.c
8384	I agree. It would be better to avoid error cases when updating the kernel pmap.

andrew added inline comments.Mar 23 2026, 9:51 AM

sys/arm64/arm64/pmap.c
8384	We already return a failure if demote fails above.

markj added inline comments.Mar 23 2026, 2:52 PM

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.