panic on large memory regions when map-physical-memory is enabled

[hawkw]

Trying to test out a higher half kernel using PR #229, the bootloader panics when the map-physical-memory, map-framebuffer, and dynamic-range-start configurations are all present.

I have the following configurations in my Cargo.toml:

[package.metadata.bootloader]
map-physical-memory = true
# the kernel is mapped into the higher half of the virtual address space.
dynamic-range-start = "0xFFFF_8000_0000_0000"

[patch.crates-io]
# patch `bootloader` to use https://github.com/rust-osdev/bootloader/pull/229
# for dynamic range address configuration support.
#
# remove this patch once rust-osdev/bootloader#229 makes it into a release
# version.
bootloader = { git = "https://github.com/rust-osdev/bootloader", rev = "ac46d0455b41c11e5d316348d068df1c495ce0af" }

I get the following panic:

bootloader/src/binary/mod.rs

Line 355 in ac46d04

Err(err) => panic!("failed to map page {:?}: {:?}", page, err),

which fails on a ParentEntryHugeFrame error:

[hawkw]

When the map-page-table-recursively setting is also true, there's a different panic while setting up the recursive mapping:

bootloader/src/binary/mod.rs

Lines 264 to 267 in ac46d04

	panic!(
	"Could not set up recursive mapping: index {} already in use",
	u16::from(index)
	);

[package.metadata.bootloader]
map-physical-memory = true
map-page-table-recursively = true
dynamic-range-start = "0xFFFF_8000_0000_0000"

It appears the recursive index has already been used while mapping the dynamic range in this case?

[Freax13]

I feel like this is also related to #259. I can reproduce this on qemu 7.1, but not on 7.0.

[Freax13]

bootloader/src/binary/level_4_entries.rs

Lines 172 to 174 in ac46d04

	let base =
	Page::from_page_table_indices_1gib(self.get_free_entry(), PageTableIndex::new(0))
	.start_address();

This allocates a level 4 entry which spans 2^39 bytes irregardless of the requested size. QEMU's reported memory regions at 1TB are larger than that (2^40 bytes) which results the physical memory mapping overlapping into other regions.

[Freax13]

dynamic-range-start is not actually required for the crash, only map-physical-memory.

[hawkw]

dynamic-range-start is not actually required for the crash, only map-physical-memory.

Ah, yeah, you're right — it turns out I can reproduce this without the dynamic range configuration, and it's having map-physical-memory enabled that's the culprit. My bad!

This is definitely related to #259, then.

[hawkw]

I can close this issue as a duplicate of #259 if you like?

[Freax13]

Sure