[Qemu-devel] Bug report

* [Qemu-devel] Bug report
@ 2007-12-17 13:48 Bas Wijnen
  2007-12-18 16:52 ` Paul Brook
  0 siblings, 1 reply; 14+ messages in thread
From: Bas Wijnen @ 2007-12-17 13:48 UTC (permalink / raw)
  To: qemu-devel; +Cc: 419369-forwarded, 418036-forwarded, 426781-forwarded

[-- Attachment #1: Type: text/plain, Size: 2730 bytes --]

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.

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread