-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Kernel: Support Meteor Lake memory map #25725
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2 small notes, otherwise LGTM, ig
Hello! One or more of the commit messages in this PR do not match the SerenityOS code submission policy, please check the |
7908eae
to
575a16b
Compare
On Meteor Lake this range covers the GFX address space reservations, at a very high address. Nothing actually ends up using it, so we can ignore it. Moreover if we don't we end up with highest_address at the 4 TiB mark which would need an enormous page table to map this huge (0-4TiB) range. Until we support mapping I/O space piecewise we need to skip this range.
When running with 32GiB of system RAM, 2MiB is not enough for the page usage bitmap. New value should be enough for 128GiB of RAM
On my darp10-b the memory map ends up breaking the early init routines. Here are the fixes