fix(TLB): L1 TLB will not save the high bit of PPN#4455
Merged
Conversation
Actually, the bit-width of s1ppn is sectorppnLen, which is defined as PaddrBits(48) - Offset(12) - TLB compression(3). In contrast, the L2 TLB returns item.s1.entry.ppn with a bit-width of sectorptePPNLen, which equals ptePaddrLen(56) - Offset(12) - TLB compression(3). The part of the PPN beyond PaddrBits is only used to generate gpaddr when a guest page fault occurs, so it isn’t stored in the L1 TLB entry. Here, we simply assign the lower (sectorppnLen - 1, 0) bits. In fact, the original implementation would also work correctly, as it automatically truncates the lower bits of item.s1.entry.ppn and assigns them to s1ppn. TODO: Not storing gpaddr (the upper PPN bits) in the L1 TLB currently provides minimal benefits and significantly increases the complexity, scalability, and maintainability issues of the TLB. In the new architecture, we need to store gpaddr in the L1 TLB to avoid all the additional handling related to guest page faults (gpf).
|
[Generated by IPC robot]
master branch:
|
linjuanZ
approved these changes
Mar 27, 2025
good-circle
added a commit
that referenced
this pull request
Mar 27, 2025
Similar to #4455, ppn_s1 has a width of 44 bits, ppn_s2 has a width of 38 bits, and both of them need to finally assign to a 36-bits signal `ppn(d)`. The original code does not result in a functional error, but the designer should be aware of the bit-widths of these signals and whether they can be directly truncated during assignment. Therefore this PR was committed.
Tang-Haojin
pushed a commit
that referenced
this pull request
Mar 29, 2025
Similar to #4455, ppn_s1 has a width of 44 bits, ppn_s2 has a width of 38 bits, and both of them need to finally assign to a 36-bits signal `ppn(d)`. The original code does not result in a functional error, but the designer should be aware of the bit-widths of these signals and whether they can be directly truncated during assignment. Therefore this PR was committed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Actually, the bit-width of s1ppn is sectorppnLen, which is defined as PaddrBits(48) - Offset(12) - TLB compression(3). In contrast, the L2 TLB returns item.s1.entry.ppn with a bit-width of sectorptePPNLen, which equals ptePaddrLen(56) - Offset(12) - TLB compression(3).
The part of the PPN beyond PaddrBits is only used to generate gpaddr when a guest page fault occurs, so it isn’t stored in the L1 TLB entry. Here, we simply assign the lower (sectorppnLen - 1, 0) bits. In fact, the original implementation would also work correctly, as it automatically truncates the lower bits of item.s1.entry.ppn and assigns them to s1ppn.
TODO: Not storing gpaddr (the upper PPN bits) in the L1 TLB currently provides minimal benefits and significantly increases the complexity, scalability, and maintainability issues of the TLB. In the new architecture, we need to store gpaddr in the L1 TLB to avoid all the additional handling related to guest page faults (gpf).