[email protected]
[Top] [All Lists]

Bug#426781: marked as forwarded (qemu: virtual machine has impossible t

Subject: Bug#426781: marked as forwarded qemu: virtual machine has impossible timing characteristics.
From: Debian Bug Tracking System
Date: Mon, 17 Dec 2007 13:58:12 +0000
Your message dated Mon, 17 Dec 2007 14:48:20 +0100
with message-id <[email protected]>
has caused the Debian Bug report #426781,
regarding qemu: virtual machine has impossible timing characteristics.
to be marked as having been forwarded to the upstream software
author(s) [email protected]

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Subject: Bug report
From: Bas Wijnen
Date: Mon, 17 Dec 2007 14:48:20 +0100

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

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

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

--- End Message ---
<Prev in Thread] Current Thread [Next in Thread>
  • Bug#426781: marked as forwarded (qemu: virtual machine has impossible timing characteristics.), Debian Bug Tracking System <=