linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Peter Bergner <bergner@brule.borg.umn.edu>
To: Paul Mackerras <paulus@samba.org>
Cc: Mike Corrigan <mikejc@us.ibm.com>,
	Anton Blanchard <anton@samba.org>,
	Peter Bergner <bergner@borg.umn.edu>,
	linuxPPC Dev <linuxppc-dev@lists.linuxppc.org>
Subject: Re: FP save/restore code in ppc32/ppc64 kernels
Date: Thu, 8 Aug 2002 21:09:27 -0500	[thread overview]
Message-ID: <20020808210927.A870681@brule.borg.umn.edu> (raw)
In-Reply-To: <15698.61945.251112.661796@argo.ozlabs.ibm.com>


Paul Mackerras wrote:
: We used to do this (have FE0/1 = 11 for user processes all the time)
: in the 32-bit kernel, but we found we had a situation where random
: processes were occasionally getting spurious SIGFPEs.  What was
: happening was that another process would leave the FPSCR with an
: exception condition enabled and pending.  Then we switched to another
: task which would have MSR.FP=0 and MSR.FE0/1 = 11 and the cpu would
: immediately take a trap (i.e. an interrupt in IBM-speak or an
: exception in Motorola-speak :).
:
: The point is that MSR.FP=0 doesn't disable floating-point exceptions.
: If MSR.FE0/1 != 00 and the FPSCR has both the condition and enable
: bits set for some exception, the cpu will take a trap.  Therefore, if
: the FPSCR doesn't belong to the current process and there is any
: possibility that it could have enabled exception conditions being
: signalled in it, you really want to have FE0/1 = 00.

But isn't the problem of the trap/interrupt/exception leaking into
another process only a problem when we are doing lazy save of the
FP regs?  Since our ppc64 kernels are compiled as SMP, we don't do
lazy save and the giveup_fpu() code would seem to force the pending
FP exceptions to complete before the "mffs" in giveup_fpu finishes.
It might be a good idea to clear the fpscr after saving it out to
the thread struct though...


Peter

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2002-08-09  2:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-08 14:01 FP save/restore code in ppc32/ppc64 kernels Mike Corrigan
2002-08-08 22:34 ` Paul Mackerras
2002-08-09  2:09   ` Peter Bergner [this message]
2002-08-12  2:38     ` Paul Mackerras
2002-08-12 14:34       ` Peter Bergner
2002-08-14  2:20         ` Peter Bergner
  -- strict thread matches above, loose matches on Subject: below --
2002-08-07 16:23 Peter Bergner
2002-08-08 11:46 ` Anton Blanchard
2002-08-08 13:18   ` Anton Blanchard

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=20020808210927.A870681@brule.borg.umn.edu \
    --to=bergner@brule.borg.umn.edu \
    --cc=anton@samba.org \
    --cc=bergner@borg.umn.edu \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=mikejc@us.ibm.com \
    --cc=paulus@samba.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).