panicked at 'assertion failed: max_phys_addr < (1 << 48) / 512' in post-09

[willothy]

Crashed when running my code, and confirmed occurring as well with the code from post-09 branch.

It does not appear to be using my own panic handler (won't print text other than the error), even though other panics do.

Running Arch Linux, Rustc 1.65 nightly, QEMU 7.1.0. Same error occurs on Windows.

6th gen i7, 48GB RAM.

Error does not appear on another PC which is running a 10th gen i7 (QEMU 7.0.0).

[abusch]

Seeing the same thing on Macos with rustc 1.65.0-nightly (9243168fa 2022-08-31). It seems to happen as soon as I enable the map_physical_memory feature of the bootloader crate.

[phil-opp]

Thanks for reporting!

We currently see a test failure on our macOS CI runners as well. When I compared the logs for the last-working run and the first failing one, I noticed that QEMU updated from v7.0.0 to v7.1.0. The runners for Ubuntu and Windows stil use much older QEMU versions and don't show any problems.

Since Arch Linux is also typically running the newest software, I could imagine that this is triggered by the QEMU v7.1.0 release. Could you check your QEMU versions to see if my suspicion is correct?

[phil-opp]

The assertion failure happens here: https://github.com/rust-osdev/bootloader/blob/42da77b47558478c5a948d27cac80767b484eacc/src/main.rs#L289-L291 . If the assertion fails, it means that the memory map contains a memory region at address >512GiB, which is a bit strange. I think you should be able to bypass the assertion by creating a [package.metadata.bootloader] table in your Cargo.toml and add a physical-memory-offset = "0x0000f00000000000" field to it (choose any address you like). Then you should be able to inspect the memory map in your kernel. Maybe this tells us the reason for this assertion failure.

[abusch]

I can confirm I have QEmu 7.1.0 installed.

I used your workaround which indeed removed the panic, and was able to print the memory map:

Memory map: [
    MemoryRegion {
        range: FrameRange(0x0..0x1000),
        region_type: FrameZero,
    },
    MemoryRegion {
        range: FrameRange(0x1000..0x5000),
        region_type: PageTable,
    },
    MemoryRegion {
        range: FrameRange(0x5000..0x17000),
        region_type: Bootloader,
    },
    MemoryRegion {
        range: FrameRange(0x17000..0x18000),
        region_type: BootInfo,
    },
    MemoryRegion {
        range: FrameRange(0x18000..0x1f000),
        region_type: Kernel,
    },
    MemoryRegion {
        range: FrameRange(0x1f000..0x9f000),
        region_type: KernelStack,
    },
    MemoryRegion {
        range: FrameRange(0x9f000..0xa0000),
        region_type: Reserved,
    },
    MemoryRegion {
        range: FrameRange(0xf0000..0x100000),
        region_type: Reserved,
    },
    MemoryRegion {
        range: FrameRange(0x100000..0x280000),
        region_type: KernelStack,
    },
    MemoryRegion {
        range: FrameRange(0x280000..0x400000),
        region_type: Usable,
    },
    MemoryRegion {
        range: FrameRange(0x400000..0x448000),
        region_type: Kernel,
    },
    MemoryRegion {
        range: FrameRange(0x448000..0x854000),
        region_type: PageTable,
    },
    MemoryRegion {
        range: FrameRange(0x854000..0x7fe0000),
        region_type: Usable,
    },
    MemoryRegion {
        range: FrameRange(0x7fe0000..0x8000000),
        region_type: Reserved,
    },
    MemoryRegion {
        range: FrameRange(0xfffc0000..0x100000000),
        region_type: Reserved,
    },
    MemoryRegion {
        range: FrameRange(0xfd00000000..0x10000000000),
        region_type: Reserved,
    },
]

Hope this helps.

[phil-opp]

It does, thanks a lot! Looks like there is indeed a new reserved memory region just below the 1TiB mark now.

[willothy]

Since Arch Linux is also typically running the newest software, I could imagine that this is triggered by the QEMU v7.1.0 release. Could you check your QEMU versions to see if my suspicion is correct?

Yes, can confirm that the computer it's failing on runs QEMU 7.1.0 and the one it works on is running 7.0.0.

Also, set the offset in Cargo.toml and it is now working again (on 7.1.0). Thanks for the workaround!

[phil-opp]

Thanks! Let's keep this issue open for now, this is something that we should fix in the bootloader crate.

[phil-opp]

Fixed in rust-osdev/bootloader#264