I just finished debugging a particularly hard bug in my new hobby OS.
The problem was that I was using uninitialised memory.  In qemu (and
bochs), this was all 0, which was exactly what it should be initialised
to.  This means the problem wasn't triggered in qemu.  However, on real
hardware the memory isn't 0, so I had a wild pointer.  The hard part of
the bug was mostly that I couldn't use qemu (or bochs) to debug it,
since the bug didn't show up there.

So I think the memory should be initialised as garbage to be more like
real hardware, so that bugs like mine can be debugged using qemu.

Hi,

While writing a kernel and testing it with qemu, I found some bugs in
qemu (and many in my kernel ;-) ).  Here's a list of them.  They are all
about x86 emulation on x86.  Some are a bit old, and since my kernel is
now fixed I can't easily test if they still aren't fixed, though.

- When a protection level 0 process returns with iret to a pl3 process,
  and the segment registers (other than cs and ss) are set to values
  that shouldn't be usable by pl3, real hardware will hang (if there's
  no gpf handler) when they are used.  However qemu doesn't seem to have
  a problem with it at all.

- 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).

- The timing of the ports are impossibly fast.  When writing a byte to a
  serial port and immediately asking if the send buffer is empty, it
  says it is.  This means that code which only runs when waiting for
  data to be transmitted will never get tested in qemu, because it is
  never "waiting".  The same is at least true for the keyboard, I
  suppose for other devices as well.

- The system timer (irq 0) runs on real-time, not on emulated time.
  This means that the behaviour of programs may differ between machines,
  and that sending a test case to someone else may not work.r

  For example, if I write (too) much output to the serial port in the
  irq0 handler, the cpu never exits the handler (that is, it reenters
  when it's about to exit).  However, when redirecting the serial port
  output from screen into a file (it's going to stdout), the machine
  suddenly does execute programs other than the irq handler.

That's all (so far).  I can imagine that it is not always desirable to
emulate these things "right", for example with the timing: it's more
important that the emulated machine behaves properly, for example when
it plays music, than that it is reproducible.  However, I think
reproducibility would be a nice feature as well.  Perhaps it would be
better to add it via a commandline option.

Thanks,
Bas Wijnen

Ps: Please CC me, I'm not subscribed to the list.

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.

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

Not a bug, indeed, but a feature request. :-)

Yes, once I found out that this was about using uninitialized memory it
was easy to trigger.  But coming to that conclusion took a long time,
because testing on real hardware requires rebooting and such, and it's
not so easy to get dumps of processor registers.  I've streamlined the
process quite a bit, but debugging inside qemu is still much easier than
on a real machine.  Therefore anything which makes code run when it
shouldn't is worth making stricter IMO, if only through a commandline
option (--os-test, or something, to switch on all such options
together).

This is also a thing which makes kernel debugging harder.  It's fine if
the timing isn't "correct" as far as I'm concerned.  But if it never
reports the ports as busy at all, important parts of kernel code are
never executed, and thus never tested within qemu.

I understand, and I don't have a problem with that.

The cool thing about an emulator is that in theory it would be possible
to have a truely reproducible setup.  So I can send you an image file
plus a qemu command line, and you can reproduce whatever I want you to
see (usually a kernel crash, I suppose).  On real hardware it is very
well possible that this approach doesn't work: the kernel may behave
completely different on your system.  If qemu also behaves different on
your system than on mine, that's not a bug, but it is a missed
opportunity IMO. :-)

Of course if it's a lot of work to implement it, I can understand that
other things have more priority.  But I hope to convince you that it
would be a useful feature. :-)

Thanks,
Bas

This is clearly a wishlist item, not a bug,
stating as such.

Thanks,

/mjt