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 <[EMAIL PROTECTED]> Never organized
