From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: 426781-forwarded@bugs.debian.org, Bas Wijnen <wijnen@debian.org>,
419369-forwarded@bugs.debian.org,
418036-forwarded@bugs.debian.org
Subject: Re: [Qemu-devel] Bug report
Date: Tue, 18 Dec 2007 16:52:47 +0000 [thread overview]
Message-ID: <200712181652.49156.paul@codesourcery.com> (raw)
In-Reply-To: <20071217134820.GA515@pcbcn10.phys.rug.nl>
> - 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
next prev parent reply other threads:[~2007-12-18 16:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-17 13:48 [Qemu-devel] Bug report Bas Wijnen
2007-12-18 16:52 ` Paul Brook [this message]
2007-12-19 1:11 ` Bas Wijnen
-- strict thread matches above, loose matches on Subject: below --
2013-10-06 16:55 [Qemu-devel] bug report Peter Cheung
2009-01-11 12:07 Artem Kozarezov
2006-12-03 16:40 [Qemu-devel] Bug report Mike Smith
2005-11-01 23:48 Julien Lancien
2005-11-01 23:57 ` Mike Kronenberg
2005-11-02 0:00 ` Karl Magdsick
[not found] ` <e1843770511011607m1cda6256o37102cf17cc75fea@mail.gmail.com>
2005-11-02 0:08 ` Julien Lancien
2005-11-02 0:42 ` Jim C. Brown
2005-11-02 0:20 ` Philip Machanick
2005-11-02 7:03 ` Gwenole Beauchesne
2004-04-11 15:04 J. Mayer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200712181652.49156.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=418036-forwarded@bugs.debian.org \
--cc=419369-forwarded@bugs.debian.org \
--cc=426781-forwarded@bugs.debian.org \
--cc=qemu-devel@nongnu.org \
--cc=wijnen@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).