Details
- Reviewers
manu alc kib - Group Reviewers
arm64 - Commits
- rS366089: Add largepage support to the arm64 pmap.
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 33629 Build 30872: arc lint + arc unit
Event Timeline
sys/arm64/arm64/pmap.c | ||
---|---|---|
2923 | pmap_l0(pmap, sva) -> l0 | |
3479 | I'm confused. l1 can't have ATTR_DESCR_VALID set, but the pmap's resident count isn't being incremented here (like it is below in the else). | |
3503 | Can't the l0 entry be invalid? In which case, l1p will be NULL. | |
3516 | See my earlier comment. | |
4291 | Assert that the l1 entry has the "wired" bit set, like we do below? |
sys/arm64/arm64/pmap.c | ||
---|---|---|
3479 | You're right, I'm not sure why I didn't just follow what the amd64 implementation does. |
sys/arm64/arm64/pmap.c | ||
---|---|---|
1267 | Hmm. This is wrong for managed mappings. We should be testing whether the page is supposed to be writeable, not whether we've dirtied it. |
sys/arm64/arm64/pmap.c | ||
---|---|---|
1267 | Right. We should be checking (tpte & ATTR_SW_DBM) != 0 I believe. Does this bug impact correctness? If we fail here because the logically writable mapping is clean, then vm_fault_quick_hold_pages()'s fallback logic will invoke the fault handler and locate the page. I'm not sure about stage2 translations yet. |
sys/arm64/arm64/pmap.c | ||
---|---|---|
3499 | Don't you need to do some kind of dsb() after store, at least for the new mapping ? |
sys/arm64/arm64/pmap.c | ||
---|---|---|
3499 | Yes. |
Address feedback:
- When mapping a large page, don't look up the PTP unless we need it.
- Simplify pmap wired count updates.
- Unconditionally issue dsb after updating a large page PTE.