From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjXSS-0005Fd-Se for qemu-devel@nongnu.org; Fri, 14 Dec 2012 10:45:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TjXSP-0004ME-Q4 for qemu-devel@nongnu.org; Fri, 14 Dec 2012 10:45:52 -0500 Received: from cantor2.suse.de ([195.135.220.15]:45117 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjWeH-0000Es-7s for qemu-devel@nongnu.org; Fri, 14 Dec 2012 09:54:01 -0500 Message-ID: <50CB3D86.1090105@suse.de> Date: Fri, 14 Dec 2012 15:53:58 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1355350946-28010-1-git-send-email-ehabkost@redhat.com> <1355350946-28010-4-git-send-email-ehabkost@redhat.com> <20121214103850.53dda479@thinkpad.mammed.net> <20121214122734.GR3236@otherpad.lan.raisama.net> In-Reply-To: <20121214122734.GR3236@otherpad.lan.raisama.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 3/3] target-i386: replace cpuid_*features fields with a feature word array List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Igor Mammedov , qemu-devel@nongnu.org Am 14.12.2012 13:27, schrieb Eduardo Habkost: > On Fri, Dec 14, 2012 at 10:38:50AM +0100, Igor Mammedov wrote: >> On Wed, 12 Dec 2012 20:22:26 -0200 >> Eduardo Habkost wrote: >> >>> This replaces the feature-bit fields on both X86CPU and x86_def_t >>> structs with an array. >>> >>> With this, we will be able to simplify code that simply does the same >>> operation on all feature words (e.g. kvm_check_features_against_host(= ), >>> filter_features_for_kvm(), add_flagname_to_bitmaps(), and CPU >>> feature-bit property lookup/registration). >>> >> >> do you have a patch that simplifies kvm_check_features_against_host() = using >> this? >=20 > I have a very old one, based on an older (and more complex) version of > this series: > https://github.com/ehabkost/qemu-hacks/commit/eb01d374baecf6df26fd6f0d0= bb23f2e1547f499 >=20 > It's in the work/cpuid-refactor-v0.22-2012-08-31 branch in my git > repository. >=20 > That branch also has some patches to merge kvm_check_features_against_h= ost() > and filter_features_for_kvm() (because the purpose of > kvm_check_features_against_host() is simply to check if anything is > going to be filtered out by filter_features_for_kvm()). >=20 > If people are happy with the approach in this series, I plan to write > and submit cleanups for kvm_cpu_fill_host(), > kvm_check_features_against_host(), filter_features_for_kvm(), > add_flagname_to_bitmaps(), and the cpudef -> CPU feature copying code. >=20 > There's so much code that could be cleaned up using the array, that I a= m > afraid that it would cause too much conflicts in the CPU properties > work. So I can wait until the CPU properties series are submitted befor= e > making the cleanups, if necessary. As stated elsewhere, for me a proper way to define new CPU models has higher priority than feature properties, especially now that we're headed for a class_init based approach where properties cannot be used for original initialization. As suggested with my RFC I would like to take a quick, simplistic route to subclasses where no major refactoring of data fields happens. If we prepend a couple coding style and function movement patches, that's fine with me. But if we do large functional refactorings > 10 patches that change history will be clobbered by the touch-all conversion and we need to do intensive functional testing, for which I don't see sufficient time before the Soft Freeze, given the holidays. When the feature bits are stored in the classes, setting them via properties in instance_init seems like overkill (visitor overhead); we no longer dump them in -cpu ?foo; only +feature/-feature would benefit. Thus I assume them to mainly conflict where function signatures change and trivially where def changes to env, making them rather orthogonal to each other. Regards, 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