[lkml]   [2000]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: missing mxcsr initialization
    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.


    > 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:45    [W:0.027 / U:9.868 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site