From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55569) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TlP5Q-0007ke-SG for qemu-devel@nongnu.org; Wed, 19 Dec 2012 14:13:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TlP5P-00081s-KD for qemu-devel@nongnu.org; Wed, 19 Dec 2012 14:13:48 -0500 Received: from cantor2.suse.de ([195.135.220.15]:44612 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TlP5P-00081d-B0 for qemu-devel@nongnu.org; Wed, 19 Dec 2012 14:13:47 -0500 Message-ID: <50D211E2.3040809@suse.de> Date: Wed, 19 Dec 2012 20:13:38 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1355760092-18755-1-git-send-email-imammedo@redhat.com> <1355760092-18755-12-git-send-email-imammedo@redhat.com> <20121219173809.GO5334@otherpad.lan.raisama.net> In-Reply-To: <20121219173809.GO5334@otherpad.lan.raisama.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 11/20] target-i386: do not set vendor_override in x86_cpuid_set_vendor() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Igor Mammedov , Don@CloudSwitch.com, qemu-devel@nongnu.org Am 19.12.2012 18:38, schrieb Eduardo Habkost: > On Mon, Dec 17, 2012 at 05:01:23PM +0100, Igor Mammedov wrote: >> commit d480e1af which introduced vendor property was setting >> env->cpuid_vendor_override =3D 1, which prevents using vendor property >> on its own without triggering vendor override. >> Fix it by removing setting cpuid_vendor_override in x86_cpuid_set_vend= or() >> to allow to use vendor property in other places that doesn't require >> cpuid_vendor_override to be set to 1. >=20 > By making "vendor" not force override, you are making "-cpu vendor=3Dxx= x" > behave differently from setting "vendor" using all other interfaces > (e.g. -device, -global, QMP commands). >=20 > What about taking the opposite approach? Setting "vendor" could always > force vendor override, but the code that initialize the defaults would > take care of not overriding the vendor ID if unsafe. e.g.: it could jus= t > do this: >=20 > if (!kvm_enabled() || def->vendor_override) { > object_property_set_str(OBJECT(cpu), def->vendor, "vendor", errp); > } /* else, leave the "vendor" property untouched" */ >=20 > (something equivalent could be done inside class_init() when we > introduce subclasses) >=20 > On all I cases I can think of somebody setting the "vendor" property > (e.g. using -cpu, QMP, -device, or -global), it means they want vendor > override (otherwise, what's the point of setting the property?). Settin= g > vendor in no-override mode is the special case, not the other way > around. +1 I was thinking it might be possible to just reset vendor_override to false when set internally via property - I didn't get to trying out whether there is a second place affected though. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg