qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jocelyn Mayer <l_indien@magic.fr>
To: Jason Wessel <jason.wessel@windriver.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qemu-system-ppc problem with PVR access from user space
Date: Fri, 02 Nov 2007 17:23:59 +0100	[thread overview]
Message-ID: <1194020639.8327.47.camel@jma4.dev.netgem.com> (raw)
In-Reply-To: <472B2CD5.9060209@windriver.com>


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 <l_indien@magic.fr>

  reply	other threads:[~2007-11-02 16:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-02 13:04 [Qemu-devel] qemu-system-ppc problem with PVR access from user space Jason Wessel
2007-11-02 13:38 ` J. Mayer
2007-11-02 13:57   ` Jason Wessel
2007-11-02 16:23     ` Jocelyn Mayer [this message]
2007-11-02 20:46       ` Daniel Jacobowitz
2007-11-02 22:10         ` J. Mayer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1194020639.8327.47.camel@jma4.dev.netgem.com \
    --to=l_indien@magic.fr \
    --cc=jason.wessel@windriver.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).