On Tue, Dec 18, 2007 at 04:52:47PM +0000, Paul Brook wrote: > > - 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.
Not a bug, indeed, but a feature request. :-) > If you want random data if should be fairly trivial to achieve this in > your OS loader. 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). > > - The timing of the ports are impossibly fast. 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. > > - 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 I understand, and I don't have a problem with that. > 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. 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 -- 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
