Skip to content

make VirtAddr generic over address validity#586

Draft
Freax13 wants to merge 1 commit intorust-osdev:masterfrom
Freax13:feature/la-57-with-generics
Draft

make VirtAddr generic over address validity#586
Freax13 wants to merge 1 commit intorust-osdev:masterfrom
Freax13:feature/la-57-with-generics

Conversation

@Freax13
Copy link
Member

@Freax13 Freax13 commented Mar 7, 2026

As proposed by Joe and Philipp, this patch adds a generic parameter for VirtAddr. This generic parameter can be used to enforce validity for addresses with 4 level paging or 5 level paging.

This patch is still a work in progress because I wanted to make that this is what you had in mind before I spend more time on it.

I slightly modified the VirtValidity interface to because check_virt_addr by itself cannot be used to implement truncation, but truncation can be used to implement check_virt_addr. That's just a minor implementation detail though, we can discuss this later.

TODO:

  • Add a feature to gate enabling the const_trait_impl feature.
  • Fix up the remaining code. I didn't adjust all of the code to take a generic parameter for the validity yet. As of right now, there are a ton of compilation errors.
  • Figure out how to make the mapper impls work with VirtValidity. VirtValidity by itself doesn't tell the mappers how many levels there are. I don't expect this to be difficult to solve.
  • Default the validity generic parameter to Virt48. Currently, I intentionally left the default out, so that the compiler would tell me about all the code that needed to become aware of it. Rust doesn't allow defaulted generic parameters after non-defaulted ones, so I currently put the validity parameter before the page size parameter for Page. We'll probably want to swap that once we set the default.
  • Test that the Add/Sub/Step impls work and fix them if they don't. Up until now I mostly focused on fixing compilation errors and not so much on the code actually working.
  • Add type aliases? User would probably benefit from VirtAddr48, VirtAddr57, Page48, and Page57.
  • Do the same thing for PhysAddr.
  • Rebase this on next. This will very likely be a breaking change.

Closes #435

As proposed by Joe and Philipp, this patch adds a generic parameter for
VirtAddr. This generic parameter can be used to enforce validity for
addresses with 4 level paging or 5 level paging.

This patch is still a work in progress because I wanted to make that
this is what you had in mind before I spend more time on it.

I slightly modified the VirtValidity interface to because
check_virt_addr by itself cannot be used to implement truncation, but
truncation can be used to implement check_virt_addr. That's just a
minor implementation detail though, we can discuss this later.

TODO:
- Add a feature to gate enabling the const_trait_impl feature.
- Fix up the remaining code. I didn't adjust all of the code to take a
  generic parameter for the validity yet. As of right now, there are a
  ton of compilation errors.
- Figure out how to make the mapper impls work with VirtValidity.
  VirtValidity by itself doesn't tell the mappers how many levels there
  are. I don't expect this to be difficult to solve.
- Default the validity generic parameter to Virt48. Currently, I
  intentionally left the default out, so that the compiler would tell
  me about all the code that needed to become aware of it. Rust doesn't
  allow defaulted generic parameters after non-defaulted ones, so I
  currently put the validity parameter before the page size parameter
  for Page. We'll probably want to swap that once we set the default.
- Test that the Add/Sub/Step impls work and fix them if they don't. Up
  until now I mostly focused on fixing compilation errors and not so
  much on the code actually working.
- Add type aliases? User would probably benefit from VirtAddr48,
  VirtAddr57, Page48, and Page57.
- Do the same thing for PhysAddr.
- Rebase this on next. This will very likely be a breaking change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Question] Is there a reason to not support pagemaps level 5 ?

1 participant