Messages in this thread | | | From | "H. Peter Anvin" <> | Subject | Re: missing mxcsr initialization | Date | 25 Oct 2000 12:24:49 -0700 |
| |
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/
| |