> - Qemu initializes all its memory to 0. Real hardware doesn't seem to > do that. This means that usage of uninitialized memory is very hard > to debug (because 0 is often a good value, while [random] is not, so > the problem can only be seen on real hardware, which makes it hard to > debug).
Definitely not a bug. I'm fairly sure I've seen real machines that zero memory on reset. If you want random data if should be fairly trivial to achieve this in your OS loader. > - The timing of the ports are impossibly fast. > - The system timer (irq 0) runs on real-time, not on emulated time. Qemu is not cycle accurate, so any notion of "emulated time" is completely arbitrary. Currently qemu is also fairly non-deterministic. The rate at which it executes instructions may vary greatly. It's not uncommon for the CPU to stall for several ms, and executing the same code sequence multiple times may take vastly different amounts of time This is often true of modern hardware, though generally to a lesser extent. There are many things that can stall execution, e.g. frequency scaling, thermal throttling, cache or TLB interactions, DRAM refresh cycles, external bus masters, etc. You have to lock things down really tightly (and be extremely careful what hardware you use) if you want hard-realtime guarantees. Paul