QEMU Debugging Notes

QEMU makes OS development approachable because it gives fast iteration without rebooting real hardware. It also makes it easy to fool yourself when there is no output.

I was trying to separate boot image issues, target configuration problems, framebuffer failures, and kernel panics that all looked like the same blank screen.

• A blank screen does not point to one specific bug.
• Serial logs are critical because graphics initialization can fail silently.
• QEMU flags, boot image layout, panic behavior, and target setup all affect the first visible signal.
• The fastest debugging path is to create a known-good minimal output path before adding visual complexity.

• Start with serial output before relying on framebuffer rendering.
• Confirm the boot image is being loaded before debugging kernel code.
• Treat panic handlers as part of the debugging interface.
• Keep QEMU launch commands reproducible so configuration does not become hidden state.

• Which QEMU flags should become the default development profile?
• How much debug output belongs in normal boot logs?
• Should debug output be separated into levels this early?

• Create a minimal smoke test for serial output.
• Document the QEMU command used for each milestone.
• Add clearer panic output before expanding keyboard or shell features.