From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33737) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkiKI-0006RI-Do for qemu-devel@nongnu.org; Mon, 17 Dec 2012 16:34:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TkiKH-0002tk-Aj for qemu-devel@nongnu.org; Mon, 17 Dec 2012 16:34:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29400) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkiKH-0002td-1m for qemu-devel@nongnu.org; Mon, 17 Dec 2012 16:34:17 -0500 Date: Mon, 17 Dec 2012 22:34:11 +0100 From: Igor Mammedov Message-ID: <20121217223411.083b2991@thinkpad.mammed.net> In-Reply-To: <50CF83F5.10200@suse.de> References: <1355760092-18755-1-git-send-email-imammedo@redhat.com> <50CF83F5.10200@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 00/20 v2] x86 CPU cleanup (wave 2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?UTF-8?B?RsOkcmJlcg==?= Cc: Don@CloudSwitch.com, qemu-devel@nongnu.org, ehabkost@redhat.com On Mon, 17 Dec 2012 21:43:33 +0100 Andreas F=C3=A4rber wrote: > Am 17.12.2012 17:01, schrieb Igor Mammedov: > > This series is several cleanups, moved out from CPU properties series, > > since they do not really depend on CPU properties re-factoring and could > > simplify CPU subclasses work as well. >=20 > The initial cleanups (most of which I had already reviewed) look > promising. But some others are working around issues that subclasses > solve. And I would like to keep functional changes visible. Could you be more specific, please? This series is aimed to separate as much as possible (without converting everything to properties first) initial CPU initialization from a found cpu-model /will become classes/ and user supplied values for features which will be gradually transformed to canonical form of key,value pairs and appl= ied through properties. Following on cpu properties series is going property-fy remaining features that are not properties yet and convert current dynamic properties into=20 static properties. It's practically complete, I've just haven't completed patch-wise testing yet, you can see it here: https://github.com/imammedo/qemu/tree/x86-cpu-properties.WIP > If we go and explicitly set the vendor everywhere as you suggest, do we > even still need the vendor override flag at all? vendor_override is used on kvm only when user wishes to force custom vendor value on the guest, built-in models don't do it now, otherwise guest always gets host's vendor value (see get_cpuid_vendor()). >=20 > Andreas >=20 > --=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= =BCrnberg >=20 --=20 Regards, Igor