Why I Built the Computer in QEMU Before I Built the Computer
QEMU was never the destination. It was the laboratory — a reference machine where I could isolate architecture mistakes from hardware-driver mistakes before either one had a chance to hide behind the other.
QEMU was never the destination. I want to say that as plainly as I can, because it's easy to read "I built it in a VM first" and assume that's a placeholder step on the way to the real thing, like scaffolding you tear down once the building's up. That's not what it was. QEMU was the laboratory, and a laboratory is a permanent, useful thing, not a placeholder.
The actual problem it solves
Here's the failure mode I was trying to avoid: you're building a new system, and something doesn't work. Is it because your architecture is wrong, or because you're fighting a driver for a specific piece of real hardware that has its own quirks, its own undocumented behavior, its own timing weirdness? On bare metal, those two categories of bug look identical from the outside. They both just look like "it doesn't work." And when they look identical, you end up debugging the wrong layer half the time, because you genuinely can't tell which one you're looking at.
A virtual reference machine breaks that tie. QEMU's virtual hardware is well-documented, consistent, and — critically — the same every single time you boot it. If something's broken in QEMU, it is overwhelmingly likely to be my architecture, my IPC design, my service boundaries, because the virtual hardware underneath isn't the kind of thing that has mystery quirks nobody's written down.
What actually got built and tested this way
Storage. Networking. Display. Interrupt handling. The lifecycle of services starting up, checking in, and (when I did it right) getting torn down cleanly. DMA-like data paths between components. All of that got built and exercised against QEMU's virtual hardware first, where I could trust that any weirdness I saw was a weirdness I'd introduced, not a weirdness the silicon introduced.
Reproducibility was a big part of the appeal too, and I don't think I appreciated how much until I had it. Every boot starts from the same state. Every bug is, in principle, reproducible by just booting again with the same inputs. That's a genuinely rare property to have handed to you for free, and bare metal does not hand it to you for free — bare metal hands you thermal variance, firmware quirks, and hardware that ages differently than the hardware on someone else's desk.
The plan for what comes after
The eventual plan — and I want to flag this as a plan, not a thing that's done, because overclaiming that part would be exactly the kind of thing I'm trying not to do in this journal — is to use everything proven in the virtual reference machine as a template and a comparison point once real hardware enters the picture. If bare metal behaves differently than the virtual reference did, that's a signal, not a surprise to just shrug at. It tells you where the real hardware's assumptions diverge from the clean ones, and that's exactly the information you want before you start blaming your own architecture for a problem the silicon caused.
This decision held up well. It's still how I work today. What didn't hold up nearly as well was the early display and media architecture I built on top of it — and that one's next, because it's the first real gut-punch of this whole project, and I'm not going to sand the edges off it.
Originally published on The Weekend Report: https://theweekendersproject.com/report/why-i-built-the-computer-in-qemu-before-i-built-the-computer