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
signature.asc
Description: Digital signature
