Is there an existing issue for this?
Current Behavior
Today when a large page is split, it is temporarily unmapped, the new page table is filled out (remapping the large page). This can cause issues if the split fails and this was say, the SerialIo region and all prints and exceptions (which try to print) cause a triple fault (or recursive exceptions) as was the case in one bug.
This was implemented this way because we need to use the self map address, which doesn't exist for the new page table until it is mapped in the self map.
Expected Behavior
By using the zero VA range that has 512 GB of unused space, we can stage the new page table there, fill it out, then do an atomic swap; the large page is never unmapped this way.
Steps To Reproduce
n/a
Build Environment
- OS(s):
- Tool Chain(s):
- Targets Impacted:
Version Information
Urgency
Low
Are you going to fix this?
I will fix it
Do you need maintainer feedback?
No maintainer feedback needed
Anything else?
No response
Is there an existing issue for this?
Current Behavior
Today when a large page is split, it is temporarily unmapped, the new page table is filled out (remapping the large page). This can cause issues if the split fails and this was say, the SerialIo region and all prints and exceptions (which try to print) cause a triple fault (or recursive exceptions) as was the case in one bug.
This was implemented this way because we need to use the self map address, which doesn't exist for the new page table until it is mapped in the self map.
Expected Behavior
By using the zero VA range that has 512 GB of unused space, we can stage the new page table there, fill it out, then do an atomic swap; the large page is never unmapped this way.
Steps To Reproduce
n/a
Build Environment
Version Information
Urgency
Low
Are you going to fix this?
I will fix it
Do you need maintainer feedback?
No maintainer feedback needed
Anything else?
No response