-
Notifications
You must be signed in to change notification settings - Fork 211
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
better handling of very large memory maps #259
Comments
(as a side note, I'd be happy to work on some or all of these changes) |
Thanks a lot for creating this issue! I'm a bit short on time right now, so I would appreciate any help! I would suggest that we fix things in the following order:
The code for version Regarding:
I think this is already happening. I was just confused because we don't specify the page size for the start frame here: Lines 227 to 229 in ac46d04
However, we do specify the size for the end frame. Since start and end frame must be of the same type, type inference should automatically choose Size2MiB for the start frame as well. It would still be a good idea to make this more explicit :D.
|
When determining the maximum physical address for the BIOS bootloader's identity mapping, we currently use the highest address in the E380 memory map, no matter how high it is. However, the bootloader runs in protected mode, and therefore, it cannot address more than 4 GiB of memory. We can save some time by not identity mapping addresses over 4 GiB, as the bootloader cannot address them anyway. This commit changes the BIOS bootloader to skip addresses over 4 GiB when determining the maximum physical address. This is one of the changes described in issue rust-osdev#259.
Opened #260 to ignore physical addresses in excess of 4 GiB when identity mapping for the bootloader itself. |
I'm working on implementing this. This will also fix #262. |
This updates the `bootloader` crate to version 0.10.13, which fixes issues when booting on systems that report memory regions at high physical addresses in their memory map (see rust-osdev/bootloader#259). This should make it possible to run Mycelium in QEMU v7.1.0 and later, without very poor boot performance, as well as on real hardware which reports high addresses (many AMD systems). In addition, there are some new bootloader features we might want to play around with. Fixes #321.
This updates the `bootloader` crate to version 0.10.13, which fixes issues when booting on systems that report memory regions at high physical addresses in their memory map (see rust-osdev/bootloader#259). This should make it possible to run Mycelium in QEMU v7.1.0 and later, without very poor boot performance, as well as on real hardware which reports high addresses (many AMD systems). In addition, there are some new bootloader features we might want to play around with. Fixes #321
Currently, the bootloader has some issues handling BIOS memory maps that contain very high addresses, such as around the 1TB mark, and/or very large regions (in excess of 500 GB). Depending on the
bootloader
version and configuration, memory maps with high addresses or large regions may result in crashes or degrade boot performance significantly.In particular, the following issues have been observed:
bootloader
contains an assertion that may be triggered when the memory map contains an address too big for a single PML4 entry if themap_physical_memory
feature flag is enabled:bootloader/src/main.rs
Lines 289 to 291 in 42da77b
bootloader
doesn't contain that assertion, but does have offset selection code that assumes no region will require multiple PML4 entries:bootloader/src/binary/level_4_entries.rs
Lines 172 to 174 in ac46d04
bootloader
exhibits very long boot times when a memory map contains a reserved region at a ~1TB offset. This is because the bootloader will identity map all pages up to the highest reserved address in the memory map using 4K pages, and does this twice (once for the bootloader itself, and a second time when setting up physical memory mappings for the kernel). This results in a very slow boot process.These issues are relevant because AMD systems with an IOMMU have a reserved hole close to the 1TB mark. In recent QEMU versions (>= v7.1.0), QEMU will report this region as reserved in its
e380
BIOS memory map, resulting in assertion failures or boot performance degradation. I would assume this would cause issues when booting on real AMD hardware, as well.Some changes that would improve how
bootloader
handles high addresses in the memory map (many of which were suggested by @phil-opp on Gitter):The text was updated successfully, but these errors were encountered: