Re: [Qemu-devel] Bug report

[Bas Wijnen]

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