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

["J. Mayer" <l_indien@magic.fr>]

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.

-- 
J. Mayer <l_indien@magic.fr>
Never organized