Re: [Qemu-devel] PreP kernels boot using Qemu

[Aurelien Jarno <aurelien@aurel32.net>]

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