On 03/30/2011 03:01 PM, Andre Przywara wrote:
If KVM cannot find an exact match for a requested CPUID leaf, the
code will try to find the closest match instead of simply confessing
it's failure. The heuristic is on one hand wrong nowadays,
since it does not take the KVM CPUID leaves (0x400000xx) into
account. On the other hand the callers of this function can all deal
with the no-match situation. So lets remove this code, as it serves
no purpose.
This fixes a crash of newer Linux kernels as KVM guests on
AMD Bulldozer CPUs, where bogus values were returned in response to
a CPUID intercept.
@@ -4959,12 +4959,6 @@ struct kvm_cpuid_entry2 *kvm_find_cpuid_entry(struct kvm_vcpu *vcpu,
best = e;
break;
}
- /*
- * Both basic or both extended?
- */
- if (((e->function ^ function)& 0x80000000) == 0)
- if (!best || e->function> best->function)
- best = e;
}
return best;
}
This behaviour is mandated by the spec (looking at the Intel one),
though it is implemented incorrectly - should always return largest
basic leaf, and ignore the kvm leaves.
I think the correct behaviour is:
if (e->function < 10000 && (!best || e->function > best->function))
best = e;
We probably need a find_exact_cpuid_entry() that returns NULL if it
doesn't find a match, for internal use.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
