Andrea Arcangeli wrote:
>
> 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.
On that specific bit I haven't seen it go out of sync yet. However, I program
it defensively because I already got bit by the fact that the X86_FEATURE_PN
bit on Intel means something different than on AMD and as a result of getting
it wrong my first time out, AMD CPUs were segfaulting when I tried to disable
their non-existent serial number. So, since these bits vary from vendor to
vendor, I would prefer to see it handled like the PN bit, that is check for
all vendors that *do* use the bit to mean FXSR or XMM, but don't rely on all
vendors to do so. In that case, we could check for vendor == INTEL || vendor
== AMD, but I would still prefer to see *some* check on the vendor before
honoring the 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.
For Intel and AMD, yes. I still wouldn't trust it vendor wide though...my
experience in doing that is not positive...
> > 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 :).
Indeed we can, and it also goes along with what you mentioned above about
being easier to disable the xmm if need be because of testing mmu_cr4_features
instead of x86_capabilities.
I'll have some more stuff out tonight, so if you want to wait for that it will
include the items we've discussed here as well as some other things I've been
working on.
--Doug Ledford <dledford@redhat.com> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - 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