From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IkRmy-0000RV-S4 for qemu-devel@nongnu.org; Tue, 23 Oct 2007 17:59:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IkRmy-0000QD-1m for qemu-devel@nongnu.org; Tue, 23 Oct 2007 17:59:52 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IkRmx-0000Pr-RS for qemu-devel@nongnu.org; Tue, 23 Oct 2007 17:59:51 -0400 Received: from hall.aurel32.net ([88.191.38.19]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IkRmx-0002u8-75 for qemu-devel@nongnu.org; Tue, 23 Oct 2007 17:59:51 -0400 Message-ID: <471E6ED2.6020003@aurel32.net> Date: Tue, 23 Oct 2007 23:59:46 +0200 From: Aurelien Jarno MIME-Version: 1.0 Subject: Re: [Qemu-devel] PreP kernels boot using Qemu 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> <1193176403.16781.189.camel@rapid> In-Reply-To: <1193176403.16781.189.camel@rapid> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "J. Mayer" Cc: qemu-devel@nongnu.org J. Mayer a écrit : > On Tue, 2007-10-23 at 12:47 +0100, Thiemo Seufer wrote: >> 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. > > 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. > Then I guess it is what has been done on the SPARC target: after each FP instruction, check_ieee_exceptions() is called to accumulate the IEEE exceptions and generate real exceptions if they are enabled. That doesn't look really complex, but I agree that could slow down a bit the emulation. I will get a closer look in two or three weeks. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net