On 09/11/2010 05:20 PM, Joerg Roedel wrote:
On Sat, Sep 11, 2010 at 03:43:02PM +0200, Alexander Graf wrote:
@@ -305,6 +322,8 @@ static x86_def_t builtin_x86_defs[] = {
CPUID_EXT3_OSVW, CPUID_EXT3_IBS */
.ext3_features = CPUID_EXT3_LAHF_LM | CPUID_EXT3_SVM |
CPUID_EXT3_ABM | CPUID_EXT3_SSE4A,
+ .svm_features = CPUID_SVM_NPT | CPUID_SVM_LBRV | CPUID_SVM_NRIPSAVE |
+ CPUID_SVM_VMCBCLEAN,
Does that phenom already do all those? It does NPT, but I'm not sure
about NRIPSAVE for example.
Depends on which Phenom you have. A Phenom II has NRIPSAVE but the old
Phenoms don't have it. For the SVM features it is not that important
what the host hardware supports but what KVM can emulate. VMCBCLEAN can
be emulated without supporting it in the host for example.
Well, let's have a phenom2 type for those new features (and any other
features the phenom 2 has). What's the point of using the name of
existing hardware if it doesn't match that hardware?
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
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
