Messages in this thread | | | Date | Fri, 9 May 2003 16:50:51 +0000 | From | paubert <> | Subject | Re: [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/
| |