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

[Jocelyn Mayer]

On Fri, 2007-11-02 at 08:57 -0500, Jason Wessel wrote:
> J. Mayer wrote:
> > On Fri, 2007-11-02 at 08:04 -0500, Jason Wessel wrote:
> >   
> >> The typical kernel + user space I boot on the prep machine no longer
> >> boots due to an issue accessing the PVR special purpose register.  When
> >> the PVR is accessed from user space, it should generate an exception
> >> with the PC set to the instruction that it occurred at when it saves to
> >> the stack.  In the latest CVS, it is off by 4 bytes.  With out the fix
> >> /sbin/init gets killed because the kernel's trap handler which does the
> >> userspace emulation of the instruction does not clean up the trap.
> >>
> >> I am using the attached patch to work around the problem, but I wonder
> >> if there is a more generic problem that was introduced as a regression
> >> with all ppc merges in the last month or so, given this used to work
> >> fine through the generic handler.
> >>
> >> Any insight into this would certainly be useful.
> >>     
> >
> > Seems like I made a mistake for program exception generation while
> > fixing floating-point ones, I'm sorry. Your patch is incorrect but the
> > one attached should fix the problem. Could you please check it in your
> > case ?
> >   
> 
> That worked quite well.  Now my patch is back to normal.  I use the
> attached patch to silence the warning about the privileged access else
> it prints every time the glibc processor feature check is used.  The
> only difference of course from the last one is that the PC no longer
> needs to be adjusted, much like before.
> 
> The other option would be for you to remove the printf of the debug
> information?  Perhaps that was something accidentally left behind?

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).
The kernel may provide informations about the CPU features to the
userland (but this is absolutelly not PowerPC specific) but it's very
important that it never shows priviledge resources directly to user
programs, or the model is broken and virtualisation application won't be
able to run properly anymore.

-- 
Jocelyn Mayer <address@hidden>