Re: [Qemu-devel] qemu-system-ppc problem with PVR access from user space

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

On Fri, 2007-11-02 at 16:46 -0400, Daniel Jacobowitz wrote:
> On Fri, Nov 02, 2007 at 05:23:59PM +0100, Jocelyn Mayer wrote:
> > No, it's not accidental. An application accessing priviledged SPR,
> > including the PVR, is likely to be buggy. I checked in the kernel
> > (2.6.23), trapping the mfpvr instruction is a huge bug because it breaks
> > the virtualisation features of the PowerPC architecture. Application
> > like mol will suffer of this, not being able to pretend the virtualized
> > CPU is not the same as the host CPU. The PowerPC architecture has been
> > designed to be fully virtualisable but the vanilla Linux kernel breaks
> > this useful feature. The bug is then to be fixed in the kernel (and the
> > glibc if it really uses mfpvr).
> 
> I suggest you take this up with the PowerPC kernel maintainers, which
> might work, instead of making QEMU noisy about it; the people using
> QEMU don't care, and they'll just disable the warning.  It wasn't
> an accidental decision on the kernel maintainers' part either.

You're absolutely right, it's a kernel problem: it would prevent any
attempt to enable a kqemu-like feature for the PowerPC, for example. And
it seems this behavior has been in the Linux kernel for a very long
time...
I will disable the warning in the PVR specific case, but this is ugly as
it will prevent detection of bugged PVR accesses when using OSes that
respect the PowerPC specifications.

> I don't see the PVR read in current glibc, but I thought it was there;
> I don't remember exactly what happened.

One thing is sure: any application which uses mfpvr is bugged. I guess
there might be some libraries that would like to do it to enable some
optimisations at run-time. Or applications like mplayer... But I don't
see why init should ever have any usage of knowing the CPU features...

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