Page MenuHomeFreeBSD

arm64: Handle changing self-referential DMAP pages
Needs ReviewPublic

Authored by andrew on Thu, Mar 19, 4:04 PM.
Tags
None
Referenced Files
F149402319: D55943.diff
Tue, Mar 24, 5:36 AM
F149392457: D55943.diff
Tue, Mar 24, 3:55 AM
Unknown Object (File)
Mon, Mar 23, 4:17 AM
Unknown Object (File)
Mon, Mar 23, 3:43 AM
Unknown Object (File)
Mon, Mar 23, 3:24 AM
Unknown Object (File)
Sat, Mar 21, 10:26 PM
Subscribers

Details

Reviewers
manu
alc
kib
markj
Group Reviewers
arm64
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 Skipped
Unit
Tests Skipped
Build Status
Buildable 71524
Build 68407: arc lint + arc unit

Event Timeline

sys/arm64/arm64/pmap.c
8366

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
8366

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

sys/arm64/arm64/pmap.c
8366

We already return a failure if demote fails above.

sys/arm64/arm64/pmap.c
8366

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.