From: Thiemo Seufer <ths@networkno.de>
To: "J. Mayer" <l_indien@magic.fr>
Cc: qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] PreP kernels boot using Qemu
Date: Tue, 23 Oct 2007 12:47:37 +0100 [thread overview]
Message-ID: <20071023114737.GD25397@networkno.de> (raw)
In-Reply-To: <1193092572.16781.128.camel@rapid>
J. Mayer wrote:
>
> On Tue, 2007-10-23 at 00:05 +0200, Aurelien Jarno wrote:
> > J. Mayer a écrit :
> > > On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote:
> > >> On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
> > >>> Hi all,
> > >>>
> > >>> I've been investigating more about PreP kernel boot using Qemu and I
> > >>> achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
> > >>> unmodified OHW.
> [...]
> > >> - The "floating point" problem I reported during the week-end does
> > not
> > >> exists, probably because of the switch from powerpc to ppc. I
> > still
> > >> don't know if it is a kernel problem or a QEMU problem (or both).
> > >
> > > There may be issues with the floating point emulation, especially if
> > > some kernel or programs relies on the FPSCR (floating-point status)
> > > register which is never updated in Qemu.
> > >
> >
> > Is there any technical reason behind that, or is it just a lack of
> > time?
>
> I can say both:
> for most program, using floating point arithmetic ala "fast-math", it's
> not necessary to maintain a precise FPU state, as those program will
> never raise any FPU exception, never generate NaNs, infinites, ...
> The other reason is that it would need to check every FPU insn arguments
> and results at run time and treat all special cases following the actual
> PowerPC implementations behavior if we want to get a precise emulation.
> This behavior could be for example selected at compile time: then one
> would have the choice to have a quick FPU emulation model or a precise
> one.
For mips I chose the middle ground: The emulation is architecturally
correct but may not reflect FPU behaviour of the specific silicon.
E.g. one effect is that in certain cases the emulation computes values
close to underflow, while real hardware would throw the (mips FPU
specific) unimplemented exception.
For most cases this should be good enough, since only specialized
software will rely on a specific implementation's oddities.
Thiemo
next prev parent reply other threads:[~2007-10-23 11:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-22 7:36 [Qemu-devel] PreP kernels boot using Qemu J. Mayer
2007-10-22 9:23 ` Jocelyn Mayer
2007-10-27 1:59 ` Rob Landley
2007-10-22 16:28 ` Aurelien Jarno
2007-10-22 21:12 ` J. Mayer
2007-10-22 22:05 ` Aurelien Jarno
2007-10-22 22:36 ` J. Mayer
2007-10-23 11:47 ` Thiemo Seufer [this message]
2007-10-23 21:53 ` J. Mayer
2007-10-23 21:59 ` Aurelien Jarno
2007-10-23 23:06 ` J. Mayer
2007-10-24 0:08 ` Thiemo Seufer
2007-10-27 8:00 ` Rob Landley
2007-10-27 8:07 ` Aurelien Jarno
2007-10-28 10:25 ` Rob Landley
2007-10-28 9:29 ` Aurelien Jarno
2007-10-28 14:17 ` Rob Landley
2007-10-31 2:30 ` Ed Swierk
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=20071023114737.GD25397@networkno.de \
--to=ths@networkno.de \
--cc=aurelien@aurel32.net \
--cc=l_indien@magic.fr \
--cc=qemu-devel@nongnu.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).