From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9xTN-0000E9-Jl for qemu-devel@nongnu.org; Fri, 18 Dec 2015 11:01:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9xTH-0000zq-Ku for qemu-devel@nongnu.org; Fri, 18 Dec 2015 11:01:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9xTH-0000zm-D6 for qemu-devel@nongnu.org; Fri, 18 Dec 2015 11:01:31 -0500 Date: Fri, 18 Dec 2015 17:01:27 +0100 From: Igor Mammedov Message-ID: <20151218170127.67a9e20c@nial.brq.redhat.com> In-Reply-To: <20151218155149.GU3774@thinpad.lan.raisama.net> References: <1449728144-6223-1-git-send-email-bharata@linux.vnet.ibm.com> <1449728144-6223-3-git-send-email-bharata@linux.vnet.ibm.com> <20151214172949.GC3774@thinpad.lan.raisama.net> <20151215083809.GI18759@in.ibm.com> <20151216175425.7541d545@igors-macbook-pro.local> <20151216193902.GM3774@thinpad.lan.raisama.net> <20151216232620.5e1e014b@igors-macbook-pro.local> <20151217180923.GT3774@thinpad.lan.raisama.net> <20151218114605.3175f659@nial.brq.redhat.com> <20151218155149.GU3774@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com, Bharata B Rao , pbonzini@redhat.com, afaerber@suse.de, david@gibson.dropbear.id.au On Fri, 18 Dec 2015 13:51:49 -0200 Eduardo Habkost wrote: > On Fri, Dec 18, 2015 at 11:46:05AM +0100, Igor Mammedov wrote: > > On Thu, 17 Dec 2015 16:09:23 -0200 > > Eduardo Habkost wrote: > > > > > On Wed, Dec 16, 2015 at 11:26:20PM +0100, Igor Mammedov wrote: > > > > On Wed, 16 Dec 2015 17:39:02 -0200 > > > > Eduardo Habkost wrote: > > > > > > > > > On Wed, Dec 16, 2015 at 05:54:25PM +0100, Igor Mammedov wrote: > > > > > > On Tue, 15 Dec 2015 14:08:09 +0530 > > > > > > Bharata B Rao wrote: > > > > > > > > > > > > > On Mon, Dec 14, 2015 at 03:29:49PM -0200, Eduardo Habkost wrote: > > > > > > > > On Thu, Dec 10, 2015 at 11:45:37AM +0530, Bharata B Rao wrote: > > > > > > > > > Storing CPU typename in MachineState lets us to create CPU > > > > > > > > > threads for all architectures in uniform manner from > > > > > > > > > arch-neutral code. > > > > > > > > > > > > > > > > > > TODO: Touching only i386 and spapr targets for now > > > > > > > > > > > > > > > > > > Signed-off-by: Bharata B Rao > > > > > > > > > > > > > > > > Suggestions: > > > > > > > > > > > > > > > > * Name the field "cpu_base_type" to indicate it is the base CPU > > > > > > > > class name, not the actual CPU class name used when creating > > > > > > > > CPUs. > > > > > > > > * Put it in MachineClass, as it may be useful for code that > > > > > > > > runs before machine->init(), in the future. > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > * Maybe make it a CPUClass* field instead of a string? > > > > > > > > > > > > > > In the current use case, this base cpu type string is being passed > > > > > > > to cpu_generic_init(const char *typename, const char *cpu_model) > > > > > > > to create boot time CPUs with given typename and cpu_mode. So for > > > > > > > now the string makes sense for use case. > > > > > > > > > > > > > > Making it CPUClass* would necessiate more changes to > > > > > > > cpu_generic_init(). > > > > > > how about actually leaving it as "cpu_type" and putting in it > > > > > > actual cpu type that could be used with device_add(). > > > > > > > > > > > > that would get rid of keeping and passing around intermediate > > > > > > cpu_model. > > > > > > > > > > Makes sense. We only need to save both typename and cpu_model > > > > > today because cpu_generic_init() currently encapsulates three > > > > > steps: CPU class lookup + CPU creation + CPU feature parsing. But > > > > > we shouldn't need to redo CPU class lookup every time. > > > > BTW: Eduardo do you know if QEMU could somehow provide a list of > > > > supported CPU types (i.e. not cpumodels) to libvirt? > > > > > > Not sure I understand the question. Could you clarify what you > > > mean by "supported CPU types", and what's the problem it would > > > solve? > > device_add TYPE, takes only type name so I'd like to kep it that way > > and make sure that libvirt/user can list cpu types that hi would > > be able to use with device_add/-device. > > > > for PC they are generated from cpu_model with help of x86_cpu_type_name() > > What about adding a "qom-type" field to query-cpu-definitions? Sounds like good idea to me. > > > > > > > > > > > > > > > > > We could just split cpu_model once, and save the resulting > > > > > CPUClass* + featurestr, instead of saving the full cpu_model > > > > > string and parsing it again every time. > > > > isn't featurestr as x86/sparc specific? > > > > > > > > Could we have field in x86_cpu_class/sparc_cpu_class for it and set it > > > > when cpu_model is parsed? > > > > That way generic cpu_model parser would handle only cpu names and > > > > target specific overrides would handle both. > > > > > > I always assumed we want to have a generic CPU model + featurestr > > > mechanism that could be reused by multiple architectures. > > > > I've thought the opposite way, that we wanted to faze out featurestr > > in favor of generic option parsing of generic device, i.e. > > -device TYPE,option=X,... > > but we would have to keep compatibility with old CLI > > that supplies cpu definition via -cpu cpu_model,featurestr > > so cpu_model translated into "cpu_type" field make sense for every > > target but featurestr is x86/sparc specific and I'd prefer to > > keep it that way and do not introduce it to other targets. > > I see, and it may make sense long term. But do you really think > we will be able to deprecate "-cpu" and "-smp" soon? > > We already have CPUClass::parse_features, and cpu_generic_init() > already makes the model/featurestr split. Do you propose we > remove that generic code and move it back to x86/sparc? > > Also, are you sure no other architectures support options in > "-cpu"? cpu_common_parse_features() already supports setting QOM > properties, and it is already available on every architecture > that calls CPUClass::parse_features or uses cpu_generic_init(). I > see that both ARM and PPC have properties available in their CPU > classes, and call parse_features() too. Well if generic handlers already exist and spread to other targets then there isn't much point in pushing it into arch specific code, sorry for noise.