From: Philippe Elie <phil.el@wanadoo.fr>
To: paubert <paubert@iram.es>
Cc: linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@transmeta.com>, Andi Kleen <ak@suse.de>,
David Mosberger <davidm@hpl.hp.com>
Subject: Re: [PATCH] Mask mxcsr according to cpu features.
Date: Fri, 09 May 2003 06:32:00 +0000 [thread overview]
Message-ID: <3EBB4B60.4080905@wanadoo.fr> (raw)
In-Reply-To: 20030509004200.A22795@mrt-lx16.iram.es
paubert wrote:
> [CC'ed to x86_64 and ia64 maintainers because they might have the
> same issues. For existing x86_64 processors, s/0xffbf/0xffff/ in
> arch/x86-64/ia32/{fpu32,ptrace32}.c might be sufficient]
>
> With SSE2, mxcsr bit 6 is defined as controlling whether
> denormals should be treated as zeroes or not. Setting it
> no more causes an exception, but with the current code it
> would be cleared at every signal return which is a bit harsh.
>
> The following patch fixes this (2.5, but easily ported to 2.4).
>
> ===== arch/i386/kernel/i387.c 1.16 vs edited =====
> --- 1.16/arch/i386/kernel/i387.c Wed Apr 9 05:45:37 2003
> +++ edited/arch/i386/kernel/i387.c Thu May 8 23:30:23 2003
> @@ -25,6 +25,12 @@
> #define HAVE_HWFP 1
> #endif
>
> +/* mxcsr bits 31-16 must be zero for security reasons,
> + * bit 6 depends on cpu features.
> + */
> +#define MXCSR_MASK (cpu_has_sse2 ? 0xffff : 0xffbf)
> +
> +
I don't think daz bit depend on sse2, it's a separate features
> /*
> * The _current_ task is using the FPU for the first time
> * so initialize it and set the mxcsr to its default
> @@ -208,7 +214,7 @@
> void set_fpu_mxcsr( struct task_struct *tsk, unsigned short mxcsr )
> {
> if ( cpu_has_xmm ) {
> - tsk->thread.i387.fxsave.mxcsr = (mxcsr & 0xffbf);
> + tsk->thread.i387.fxsave.mxcsr = (mxcsr & MXCSR_MASK);
intel and x64 doc advocate to use
mxcsr &= tsk->thread.i387.fxsave.mxscr_mask
? 0xffbf : tsk->thread.i387.fxsave.mxscr_mask;
tsk->thread.i387.fxsave.mxscr = mxcsr;
with mxscr_mask the 16 upper bits of field currently named
mxscr in fxsave area. This bits was zeroed by previous processor
so this must be backward compatible.
Intel P4 Vol 1 11.6.6 "Guidelines for writing to MXSCR register"
AMD x64 Vol 2 11.4.4 "Saving and restoring Media and x87 processor"
regards,
Philippe Elie
next prev parent reply other threads:[~2003-05-09 4:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-09 0:42 [PATCH] Mask mxcsr according to cpu features paubert
2003-05-09 2:24 ` Andi Kleen
2003-05-09 10:56 ` paubert
2003-05-09 11:41 ` Andi Kleen
2003-05-09 6:32 ` Philippe Elie [this message]
2003-05-09 10:48 ` paubert
2003-05-09 16:33 ` Philippe Elie
2003-05-09 16:50 ` paubert
2003-05-09 21:00 ` Philippe Elie
2003-05-11 23:31 ` [PATCH] [CFT] [RFC] Correct mxcsr handling (was: Mask mxcsr according to cpu features.) Gabriel Paubert
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=3EBB4B60.4080905@wanadoo.fr \
--to=phil.el@wanadoo.fr \
--cc=ak@suse.de \
--cc=davidm@hpl.hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paubert@iram.es \
--cc=torvalds@transmeta.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.