[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Bug report
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] Bug report |
Date: |
Tue, 18 Dec 2007 16:52:47 +0000 |
User-agent: |
KMail/1.9.7 |
> - 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. If you want random data if should be fairly trivial to achieve this
in your OS loader.
> - The timing of the ports are impossibly fast.
> - 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
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.
Paul