-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mutable references in page table implementation? #416
Comments
Hey @phil-opp, I recently went down the rabbit hole researching references to "volatile" memory in Rust. If you haven't seen them yet, here are some convincing resources that support your idea to use raw pointers and volatile operations:
Many of those resources are more concerned with spurious reads, but what I got from them is when interacting with memory "owned" by the hardware and that can be modified by the hardware, it is better to wrap raw pointers and use volatile reads/writes. My current thinking is Rust references are more appropriate for data created by Rust, either on the heap or the stack, that is fully "owned" by Rust. In my OS, I wrote some simple wrapper types around raw pointers for registers, and a I actually came across this specific issue because I wanted to wrap a type I have for physical memory allocation in a P.S. I read both editions of your "Writing an OS in Rust" blog series and I learned so much! Thanks for investing in the bare metal Rust ecosystem. It is really rewarding to learn about and use. |
The current API of
RecursivePageTable
,OffsetPageTable
, andMappedPageTable
encourages the creation of&mut PageTable
references to the active page table hierarchy. This might be problematic because the page tables are also accessed by the hardware at the same time. The hardware might even modify the page table, e.g. set theaccessed
ordirty
flags.To avoid any semantic issues, it would be a good idea to also provide methods based on raw
*mut PageTable
pointers. We should also update the implementations to never create&mut
references internally either. We might even want to use volatile operations...See also phil-opp/blog_os#1202
The text was updated successfully, but these errors were encountered: