SO WHAT WAS HAPPENING? i realized that because the BIOS memory map from QEMU now contained this new reserved region at 0xfd00000000 to 0x10000000000, that loop is now running for a *really* long time
Conversation
the highest virtual address is now 0x10000000000, which is exactly 1 TB. and the bootloader is now trying to identity map every 4 KB page from 1 GB to 1 TB, which is...something like 2.684Γ10^8 4K pages. that's...a lot!
1
1
75
for each of those 4k pages, the bootloader had to create a page table entry (possibly allocating a new page table for that entry to go on), and execute the `invlpg` instruction to flush the changes to the page table. that's kind of a lot of work to do, especially in an emulator!
1
53
and the bootloader does all of this identity mapping before it maps the framebuffer region and starts actually logging what it's doing. the earlier bootloader stages, written in assembly, will write to the VGA buffer if they *fail*, but don't write to the screen otherwise...
1
49
so this loop, which takes about ~3 minutes on my machine, was happening before the bootloader displays any kind of visual indication that it's even alive at all. and i was seeing the black screen for longer than i was used to, and assuming it was totally dead (i'm impatient)
1
67
when running with gdb attached, i was a bit more patient, because i was at least interacting with the kernel and seeing that it was "doing stuff", and not in some obviously bad state, so i didn't immediately assume it was dead and kill the emulator...
1
53
so it turns out, there wasn't really a "bug" at all, exactly. i don't know why QEMU started reporting that new reserved region, but i'm assuming it's for *something* i might want someday, and the bootloader was doing what it's supposed to (and mycelium is totally innocentπ)
1
59
maybe the bootloader didn't *need* to be identity mapping all the non-reserved regions up to the highest reserved physical address, but it seems like a basically reasonable thing to do...
1
44
and if it had written something to the framebuffer occasionally to show it's still alive, i probably wouldn't have killed it quite so impatiently. but nothing is *really* doing anything *wrong*, per se.
1
53
so, the moral of this story is (a) OS dev is a really miserable thing to do, (2) sometimes every component of a system can "work correctly" individually and still result in bad behavior, and (iii) code that runs before a system can print to ANYTHING is a special level of Hell
6
5
135
this generalizes to any kind of embedded software work without good debugging infrastructure. i definitely feel your pain
in the immortal words of James Mickens, " I HAVE NO TOOLS BECAUSE IβVE DESTROYED MY TOOLS WITH MY TOOLS."
read image description
ALT
1
1
12
that whole article is fucking hilarious
usenix.org/system/files/1
1

