lkml.org 
[lkml]   [2003]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Mask mxcsr according to cpu features.
On Fri, May 09, 2003 at 04:33:37PM +0000, Philippe Elie wrote:
> paubert wrote:
> >On Fri, May 09, 2003 at 06:32:00AM +0000, Philippe Elie wrote:
> >
>
>
> >>>+/* 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 doc I have state in several places:
> >"The denormals-are-zeros mode was introduced in the Pentium 4 processor
> >with the SSE2 extensions."
> >
> >Maybe I should download a newer doc from Intel. The one I have states
> >that DAZ is associated with sse2, and does not speak at _all_ of the
> >MXCSR_MASK field (I have seen it in my x86_64 doc though).
>
> the doc is not very clear, I see this in 11.6.3
>
> "The denormal-are-zeo flag in MXCSR was introduced in later Pentium
> 4 processor and in the Intel Xeon processor"

Indeed, I have downloaded fresher docs and I have found the following:
"In earlier IA-32 processors and in some models of the Pentium 4
processor, this flag (bit 6) is reserved." (10.2.2)

Of course other sentences would imply that DAZ is associated
with SSE2 capability, but all Pentium 4 have SSE2, I believe.

Well, what a mess for a single bit!

> Not for intel at least since they advocate to use the mask as
> a "is this feature present" and use mask 0xFFBF if mask == 0
> and since this bits was required to be zero I think it's safe.

AMD says more or less the same.

> The only problem we can get is an old processor which write non
> zero but random bits in the 16 upper bits.

I don't believe that there is any, but that maybe some which don't
write anything, hence the requirement for clearing the area in the
DAZ detection algorithm.

>
>
> >It's simply a matter of rewriting the MXCSR_MASK macro, but to avoid
> >a conditional, I'd rather have a global mxcsr_mask variable somewhere
> >with the cpu feature flags.
>
>
> my documentation says to fxsave and get the features mask from
> the mxcsr mask but to fall back to 0xffbf if mask == 0, quoting
> docs 11.6.6:
>
> 1 setup a fxsave area
> 2 clear this area
> 3 fxsave in this area
> 4 if mxcsr == 0 use mask 0xffbf else use mxcsr mask

Too expensive unless the mask is computed at boot time once and for
all (thrashing half a kB for a single 32 bit constant, sigh). I did
not want to touch too many files in my patch, but it seems unavoidable.

Now a last question, are there SMP systems in which one processor
supports DAZ and the other does not, just to complicate matters a
little more?

Regards,
Gabriel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:35    [W:0.061 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site