lkml.org 
[lkml]   [2000]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: missing mxcsr initialization
Date
Followup to:  <39F72A7B.71B2343C@redhat.com>
By author: Doug Ledford <dledford@redhat.com>
In newsgroup: linux.dev.kernel
>
> 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 ==
> 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
> 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
> 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
> also added Gabriel Paubert's more correct tag word conversion routines.
> That's all the changes I made here, but it's the list of changes needed for me
> to be able to put my P4 patch on top of this instead of having it undo a lot
> 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.
>

Please don't do this! First of all, expect other CPU vendors to come
out with this. Hardcoding vendor == INTEL all over the place is an
EXTREMELY bad idea, especially for a feature such as FXSR and XMM,
which are inevitable going to be used elsewhere.

Unfortunately, especially AMD has in the past made the mistake of
reassigning Intel-defined bits (in 0x00000001) for their own use;
these should be treated as AMD-specific bugs and handled as such;
rather than saying "everything that isn't Intel is buggy." Similarly,
Intel CPUID errors such as the early P6 SEP bugs should be treated as
Intel-specific, of course.

I would really like to see the current 1:1 mapping between CPUID
00000001:EDX and the x86 feature flags Linux uses to go away, to be
replaced with a Linux-defined structure that is filled by the
CPU-detection code. However, I *FIRMLY* believe that *UNLESS
OTHERWISE KNOWN* (due to vendor-specific bugs/quirks/whatever), the
default is that feature flags in 00000001:EDX, if present, should be
as defined by Intel, feature flags in 80000001:EDX, if present, should
be as defined by AMD, and feature flags in 80860001:EDX, if present,
should be as defined by Transmeta; this should *NOT* be
conditionalized on the VendorID.

We probably need more than 32 bits worth of feature test bits to cover
all current x86 processors; and definitely for the future. I'd like
to suggest making the feature flag set an array of longs, with the
appropriate defines.

-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.089 / U:1.504 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site