From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOAEb-0000SK-Ce for qemu-devel@nongnu.org; Thu, 13 Mar 2014 14:20:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WOAEU-00029m-9w for qemu-devel@nongnu.org; Thu, 13 Mar 2014 14:20:01 -0400 Received: from cantor2.suse.de ([195.135.220.15]:36490 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOAEU-00028W-3Z for qemu-devel@nongnu.org; Thu, 13 Mar 2014 14:19:54 -0400 Message-ID: <5321F6C5.3030301@suse.de> Date: Thu, 13 Mar 2014 19:19:49 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1394722501-32326-1-git-send-email-afaerber@suse.de> <1394722501-32326-20-git-send-email-afaerber@suse.de> In-Reply-To: <1394722501-32326-20-git-send-email-afaerber@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PULL for-2.0-rc0 19/58] target-i386: X86CPU model subclasses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, Eduardo Habkost , Peter Maydell Cc: Igor Mammedov Am 13.03.2014 15:54, schrieb Andreas F=C3=A4rber: > From: Eduardo Habkost >=20 > Register separate QOM types for each x86 CPU model. >=20 > This will allow management code to more easily probe what each CPU mode= l > provides, by simply creating objects using the appropriate class name, > without having to restart QEMU. >=20 > This also allows us to eliminate the qdev_prop_set_globals_for_type() > hack to set CPU-model-specific global properties. >=20 > Instead of creating separate class_init functions for each class, I jus= t > used class_data to store a pointer to the X86CPUDefinition struct for > each CPU model. This should make the patch shorter and easier to review= . > Later we can gradually convert each X86CPUDefinition field to lists of > per-class property defaults. >=20 > The "host" CPU model is special, as the feature flags depend on KVM > being initialized. So it has its own class_init and instance_init > function, and feature flags are set on instance_init instead of > class_init. >=20 > Signed-off-by: Andreas F=C3=A4rber > Signed-off-by: Igor Mammedov > Signed-off-by: Eduardo Habkost > Reviewed-by: Eduardo Habkost > Tested-by: Eduardo Habkost > Signed-off-by: Andreas F=C3=A4rber Breaks mingw32 build with undefined kvm_arch_get_supported_cpuid() references. Limiting the host CPU type to CONFIG_KVM, as inquired on my v10, resolves this. diff --git a/target-i386/cpu.c b/target-i386/cpu.c index 8070c97..0e69383 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -1151,6 +1151,8 @@ void x86_cpu_compat_set_features(const char *cpu_model, Fe atureWord w, } } +#ifdef CONFIG_KVM + static int cpu_x86_fill_model_id(char *str) { uint32_t eax =3D 0, ebx =3D 0, ecx =3D 0, edx =3D 0; @@ -1226,6 +1228,8 @@ static const TypeInfo host_x86_cpu_type_info =3D { .class_init =3D host_x86_cpu_class_init, }; +#endif + static int unavailable_host_feature(FeatureWordInfo *f, uint32_t mask) { int i; @@ -2830,7 +2834,9 @@ static void x86_cpu_register_types(void) for (i =3D 0; i < ARRAY_SIZE(builtin_x86_defs); i++) { x86_register_cpudef_type(&builtin_x86_defs[i]); } +#ifdef CONFIG_KVM type_register_static(&host_x86_cpu_type_info); +#endif } type_init(x86_cpu_register_types) Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg