The recent fix for the AMD FXSAVE information leak had a problematic side effect. It
introduced an entry in the x86 features vector which is a bug, not a feature.
The problem with this is that the features vector is designed so that it can be ANDed
between CPUs to find out the common feature set. However, bugs aren't features, and bugs
should be ORd, not ANDed. In that sense, the *absence* of a bug is a feature.
There are two possible ways of dealing with this:
a) put bugs in the features vector, but sense-inversed, i.e. 1 = bug absent; 0 = bug present.
b) add a separate bugs vector.
When I originally wrote the code I always meant to do (b), but never got around to it.
It's clear, though, that whatever way we go about this, it should also incorporate the
fdiv, hlt, f00f, and coma bugs.
-hpa
"H. Peter Anvin" <[email protected]> writes:
> The recent fix for the AMD FXSAVE information leak had a problematic
> side effect. It introduced an entry in the x86 features vector which
> is a bug, not a feature.
It's a non issue because it affects all AMD CPUs (except K5/K6).
You'll never find a system where only some CPUs have this problem.
-Andi
Andi Kleen wrote:
> "H. Peter Anvin" <[email protected]> writes:
>
>> The recent fix for the AMD FXSAVE information leak had a problematic
>> side effect. It introduced an entry in the x86 features vector which
>> is a bug, not a feature.
>
> It's a non issue because it affects all AMD CPUs (except K5/K6).
> You'll never find a system where only some CPUs have this problem.
>
It's still wrong architecturally, and we should have a sane way to deal with this as well
as other bugs. This isn't the only bug -- we're getting a decent-size collection of them
already -- and not all of them is going to have that particular property.
-hpa
On Friday 05 May 2006 20:18, H. Peter Anvin wrote:
> Andi Kleen wrote:
> > "H. Peter Anvin" <[email protected]> writes:
> >
> >> The recent fix for the AMD FXSAVE information leak had a problematic
> >> side effect. It introduced an entry in the x86 features vector which
> >> is a bug, not a feature.
> >
> > It's a non issue because it affects all AMD CPUs (except K5/K6).
> > You'll never find a system where only some CPUs have this problem.
> >
>
> It's still wrong architecturally, and we should have a sane way to deal with this as well
> as other bugs. This isn't the only bug -- we're getting a decent-size collection of them
> already -- and not all of them is going to have that particular property.
I'm not very worried because mixing steppings is generally unsupported anyways
and in Linux also doesn't work well with it.
(e.g. my old rig with one CPU FXSAVE capable, one CPU not never worked without
kernel hacks)
It's probably not worth the effort anyways. The people who build such strange
systems can tweak their kernels for it too.
-Andi
Andi Kleen <[email protected]> writes:
> "H. Peter Anvin" <[email protected]> writes:
>
> > The recent fix for the AMD FXSAVE information leak had a problematic
> > side effect. It introduced an entry in the x86 features vector which
> > is a bug, not a feature.
>
> It's a non issue because it affects all AMD CPUs (except K5/K6).
> You'll never find a system where only some CPUs have this problem.
I have a dual CPU system (Tyan Tomcat 1564D) where only one CPU is
reported to have the F00F bug (iirc). So yes, there can be
SMP-systems where the CPU's have different bugs.
/Christer
--
"Just how much can I get away with and still go to heaven?"
Freelance consultant specializing in device driver programming for Linux
Christer Weinigel <[email protected]> http://www.weinigel.se
Christer Weinigel wrote:
> Andi Kleen <[email protected]> writes:
>
>> "H. Peter Anvin" <[email protected]> writes:
>>
>>> The recent fix for the AMD FXSAVE information leak had a problematic
>>> side effect. It introduced an entry in the x86 features vector which
>>> is a bug, not a feature.
>> It's a non issue because it affects all AMD CPUs (except K5/K6).
>> You'll never find a system where only some CPUs have this problem.
>
> I have a dual CPU system (Tyan Tomcat 1564D) where only one CPU is
> reported to have the F00F bug (iirc). So yes, there can be
> SMP-systems where the CPU's have different bugs.
Point being, not this bug..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Followup to: <[email protected]>
By author: Robert Hancock <[email protected]>
In newsgroup: linux.dev.kernel
> >
> > I have a dual CPU system (Tyan Tomcat 1564D) where only one CPU is
> > reported to have the F00F bug (iirc). So yes, there can be
> > SMP-systems where the CPU's have different bugs.
>
> Point being, not this bug..
>
However, *MY* point is that we should have a uniform infrastructure
for bugs, just like we now have for features.
-hpa
Andi Kleen wrote:
> "H. Peter Anvin" <[email protected]> writes:
>
>> The recent fix for the AMD FXSAVE information leak had a problematic
>> side effect. It introduced an entry in the x86 features vector which
>> is a bug, not a feature.
>
> It's a non issue because it affects all AMD CPUs (except K5/K6).
> You'll never find a system where only some CPUs have this problem.
>
The initial argument is dead on, bugs should be either presented as a
"fixed" feature, or there could (should?) be a bugs vector which could
be or'd. It's at least possible that AMD might fix this some time.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me