From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sbb6P-0005Xf-Tp for qemu-devel@nongnu.org; Mon, 04 Jun 2012 13:30:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sbb6K-0002VA-Mf for qemu-devel@nongnu.org; Mon, 04 Jun 2012 13:30:01 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33166 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sbb6K-0002Ux-D5 for qemu-devel@nongnu.org; Mon, 04 Jun 2012 13:29:56 -0400 Message-ID: <4FCCF08A.4050404@suse.de> Date: Mon, 04 Jun 2012 19:29:46 +0200 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1338329426-28118-1-git-send-email-imammedo@redhat.com> <1338329426-28118-9-git-send-email-imammedo@redhat.com> <4FC63B30.5040206@suse.de> <4FCCCCB2.9090103@redhat.com> In-Reply-To: <4FCCCCB2.9090103@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH qom-next 08/12] target-i386: introduce cpu-model property for x86_cpu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: peter.maydell@linaro.org, aliguori@us.ibm.com, Eduardo Habkost , stefano.stabellini@eu.citrix.com, sw@weilnetz.de, mtosatti@redhat.com, qemu-devel@nongnu.org, agraf@suse.de, blauwirbel@gmail.com, jcmvbkbc@gmail.com, avi@redhat.com, jan.kiszka@siemens.com, anthony.perard@citrix.com, pbonzini@redhat.com, rth@twiddle.net Am 04.06.2012 16:56, schrieb Igor Mammedov: > On 05/30/2012 05:22 PM, Andreas F=E4rber wrote: >> Am 30.05.2012 00:10, schrieb Igor Mammedov: >>> it's probably intermidiate step till cpu modeled as >>> sub-classes. After then we probably could drop it. >>> >>> However it still could be used for overiding default >>> cpu subclasses definition, and probably renamed to >>> something like 'features'. >> >> * As you rightly point out, we are heading towards sub-classes and tha= t >> contradicts this two-step initialization. I don't see how this is an >> intermediate step? > It's not clear to me how sub-classes contradict with two-step > initialization, > , could you elaborate more on this? CPU subclasses mean to me that for -cpu qemu64 we would have a QOM type "qemu64" (or so). initfn would then take care of initializing all default values, and from cpu_x86_init() we would parse the remaining cpu_model parameters and set QOM properties on the CPU instance. Original attempt: https://github.com/afaerber/qemu-cpu/commit/a27feda42712606ca2303faeb6c7e= 8478660a1c1 Now, the contradiction is that once we have done object_new("qemu64") we cannot change its type "qemu64" to anything else. Therefore I dislike sticking cpu_model into a "cpu-model" property. What I was talking about wrt features was doing in pseudocode: object_new("qemu64") object_property_set_int("family", 42) object_property_set_string("vendor", "Me, myself and I") object_property_set_bool("x2apic", true) ... I.e. decoupling the back part of the cpu_model string from the model. My patches in master that you and others have reviewed did this for the mostly numeric CPUID parts (-cpu foo,x=3D42), with a view to code sharing= . What's missing is properties to set CPU features (-cpu foo,+x,-y). There the question is how granular do we want to go and which types do we want to use. The example above shows using a bool property for a specific feature (without having checked that for correctness). Other possibilities would be to have a feature string with all those space-separated acronyms or an int that is a bitfield. One doesn't rule out the other. Jan's requirement, I think, was to be able to set them from global properties for pc-1.x backwards compatibility. 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