Conversation
|
🤖 SemverChecks 🤖 No breaking API changes detected Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered. |
If it's not-present --> present, my understanding is that in worst case CPU would trigger page fault. Once it's resolved, TLB would be updated. So, we don't need to flush TLB proactively. |
There are some corner cases that I can reproduce and that's why I wrote this PR :) |
What is the corner case? |
This is about a kernel-level page fault. we don't have demand paging / page fault handler for it. |
CvvT
left a comment
CvvT
left a comment
There was a problem hiding this comment.
Overall LGTM, left one question.
| // Flush old (unmapped) addresses — other cores may hold stale entries. | ||
| let page_count = (end.start_address() - flush_start.start_address()) / Size4KiB::SIZE; | ||
| flush_tlb_range(flush_start, page_count.truncate()); | ||
| flush_tlb_range(new_flush_start, page_count.truncate()); |
There was a problem hiding this comment.
Is remap_pages only used to remap user space memory or can be also used to remap kernel space memory in lvbs case? If it's the former case, we may avoid this extra flush (but I guess it's safer to flush the TLB anyway).
There was a problem hiding this comment.
You're right. Let me take a look this PR again to see whether we can skip some TLB flushes.
2 participants
This PR fixes missing TLB flushes. In particular, it covers cases like cross-core kernel-page not-present -> present or PDE widening, which result in faults because we do not maintain VM areas for kernel address space such that a page fault handler cannot properly update the PTEs. This PR simply flushes corresponding TLB entries.