On Wed, Oct 25, 2000 at 02:46:19PM -0400, Doug Ledford wrote:
> I've made a few correctness changes to this code. Items that needed to be
> corrected for include the facts that the XMM feature bit is an Intel specific
> bit that other vendors may use for other things, so you need to test vendor ==
^^^
Note that they shouldn't do that! I would consider a very bad thing if they
goes out of sync on those bits.
> INTEL as well as the feature bit before enabling XMM and FXSR features (AMD
> also has fxsr, but we currently don't do anything with it). I moved the
FXSR is supported and it just works fine on Athlon too with the PIII patch.
About XMM that bit is honoured by AMD specs too and it's mentioned explicitly
that when that bit is enabled stremaming SIMD instructions (SSE) are supported
by the CPU (that should be the case of an x86-64 when booted with an IA32
kernel). So I'd trust that bit too all over the x86 implementations as we
_just_ do with PSE/PGE and friends since a long time ago.
So in short I'd vote not to limit the honouring of FXSR and XMM features
to Intel CPUs. If you have any reason to think that this is going to
break in the future let me know. I personally think it won't break and
it looks the right thing to do to me.
> mmu_cr4_features into the boot_cpu_data struct instead of as a global variable
> of type initdata because it is easier to test mmu_cr4_features for a specific
> bit (such as XMMEXCEPT) to detect presence of XMM instructions than it is to
> test the three items (vendor == INTEL && capabilities & FEATURE_XMM &&
> !nofxsr) to determine things such as XMM allowed. This works since cr4 is
> currently Intel only and the presence of XMMEXCEPT implies all of the above
I agree. I like it mainly because it allows to handle the nofxsr case
more correctly: it will avoid us to clear fxsr/xmm features in the
x86_capability field (such clear of fxsr/xmm was causing /proc/cpuinfo not to
report fxsr/xmm anymore and that could be considered a minor bug given
/proc/cpuinfo should tell about the hardware features of the CPU and it should
remain unrelated to the CPU features that the OS is supporting at runtime).
> things. Since there are PII CPUs that have FXSR support but not mxcsr
> registers, I rekeyed the mxcsr routines to check for XMM instead of FXSR. I
Note that load_mxcsr is also checking for XMM (I mean it's not buggy,
also I have one of those PII with fxsr and w/o xmm). See the implementation:
#define load_mxcsr( val ) do { \
if ( cpu_has_xmm ) { \
unsigned long __mxcsr = ((unsigned long)(val) & 0xffff); \
asm volatile( "ldmxcsr %0" : : "m" (__mxcsr) ); \
} \
} while (0)
I agree we can skip the FXSR check there because a CPU can't support XMM and
not support FXSR. But after your below change we can as well remove the
cpu_has_xmm check from load_mxcsr :).
> also added Gabriel Paubert's more correct tag word conversion routines.
Ok.
> of the work in this patch. Andrea, if you could, please integrate this into
> your own stuff so that we can keep a unified direction on this stuff.
Of course I will integrate them. I will skip the FXSR/XMM-Intel-only part
unless somebody raises some relevant issue.
Thanks Doug.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:17 EST