From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IkRgt-0002vD-PB for qemu-devel@nongnu.org; Tue, 23 Oct 2007 17:53:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IkRgs-0002tP-Vs for qemu-devel@nongnu.org; Tue, 23 Oct 2007 17:53:35 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IkRgs-0002t4-FB for qemu-devel@nongnu.org; Tue, 23 Oct 2007 17:53:34 -0400 Received: from bangui.magic.fr ([195.154.194.245]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IkRgr-0001hN-ST for qemu-devel@nongnu.org; Tue, 23 Oct 2007 17:53:34 -0400 Subject: Re: [Qemu-devel] PreP kernels boot using Qemu From: "J. Mayer" In-Reply-To: <20071023114737.GD25397@networkno.de> References: <1193038567.16781.108.camel@rapid> <20071022162810.GA12778@hall.aurel32.net> <1193087522.16781.121.camel@rapid> <471D1E98.50303@aurel32.net> <1193092572.16781.128.camel@rapid> <20071023114737.GD25397@networkno.de> Content-Type: text/plain; charset=ISO-8859-15 Date: Tue, 23 Oct 2007 23:53:23 +0200 Message-Id: <1193176403.16781.189.camel@rapid> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thiemo Seufer Cc: qemu-devel@nongnu.org, Aurelien Jarno On Tue, 2007-10-23 at 12:47 +0100, Thiemo Seufer wrote: > J. Mayer wrote: > >=20 > > On Tue, 2007-10-23 at 00:05 +0200, Aurelien Jarno wrote: > > > J. Mayer a =E9crit : > > > > 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 C= VS and > > > >>> unmodified OHW. > > [...] > > > >> - The "floating point" problem I reported during the week-end do= es > > > not > > > >> exists, probably because of the switch from powerpc to ppc. I > > > still=20 > > > >> don't know if it is a kernel problem or a QEMU problem (or bot= h). > > > >=20 > > > > There may be issues with the floating point emulation, especially= if > > > > some kernel or programs relies on the FPSCR (floating-point statu= s) > > > > register which is never updated in Qemu. > > > >=20 > > >=20 > > > Is there any technical reason behind that, or is it just a lack of > > > time? > >=20 > > 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 argume= nts > > and results at run time and treat all special cases following the act= ual > > PowerPC implementations behavior if we want to get a precise emulatio= n. > > 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 precis= e > > one. >=20 > 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. >=20 > For most cases this should be good enough, since only specialized > software will rely on a specific implementation's oddities. Well, what you've done for Mips is exactly what I called the "precise emulation" and is far slower than the "fast math" emulation I got for PowerPC. I was wrong talking about "PowerPC implementations" when I should have said "PowerPC specification"; but there should be no difference between the two (or it's not a PowerPC CPU...) because the POWER/PowerPC specification describes very precisely the behavior of the FPU. The "fast math" model relies on the native-softmmu code and is suficient for most applications. But there are a few instructions that should always take care (or maybe at least reset) the FPSCR register, which is not done in the current code. --=20 J. Mayer Never organized