On Fri, 28 Dec 2012 16:37:33 -0200 Eduardo Habkost <ehabkost@xxxxxxxxxx> wrote: > The existing -cpu host code simply set every bit inside svm_features > (initializing it to -1), and that makes it impossible to make the > enforce/check options work properly when the user asks for SVM features > explicitly in the command-line. > > So, instead of initializing svm_features to -1, use GET_SUPPORTED_CPUID > to fill only the bits that are supported by the host (just like we do > for all other CPUID feature words inside kvm_cpu_fill_host()). > > This will keep the existing behavior (as filter_features_for_kvm() > already uses GET_SUPPORTED_CPUID to filter svm_features), but will allow > us to properly check for KVM features inside > kvm_check_features_against_host() later. > > For example, we will be able to make this: > > $ qemu-system-x86_64 -cpu ...,+pfthreshold,enforce > > refuse to start if the SVM "pfthreshold" feature is not supported by the > host (after we fix kvm_check_features_against_host() to check SVM flags > as well). > > Signed-off-by: Eduardo Habkost <ehabkost@xxxxxxxxxx> Reviewed-By: Igor Mammedov <imammedo@xxxxxxxxxx> > --- > target-i386/cpu.c | 11 ++++------- > 1 file changed, 4 insertions(+), 7 deletions(-) > > diff --git a/target-i386/cpu.c b/target-i386/cpu.c > index 3cd1cee..6e2d32d 100644 > --- a/target-i386/cpu.c > +++ b/target-i386/cpu.c > @@ -897,13 +897,10 @@ static void kvm_cpu_fill_host(x86_def_t *x86_cpu_def) > } > } > > - /* > - * Every SVM feature requires emulation support in KVM - so we can't > just > - * read the host features here. KVM might even support SVM features not > - * available on the host hardware. Just set all bits and mask out the > - * unsupported ones later. > - */ > - x86_cpu_def->svm_features = -1; > + /* Other KVM-specific feature fields: */ > + x86_cpu_def->svm_features = > + kvm_arch_get_supported_cpuid(s, 0x8000000A, 0, R_EDX); > + > #endif /* CONFIG_KVM */ > } > -- 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