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/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:16 EST