From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45594) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqGKv-0004Oy-CV for qemu-devel@nongnu.org; Thu, 07 May 2015 03:35:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YqGKr-0004Dm-AM for qemu-devel@nongnu.org; Thu, 07 May 2015 03:35:13 -0400 Received: from e06smtp17.uk.ibm.com ([195.75.94.113]:42347) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqGKr-0004CL-2T for qemu-devel@nongnu.org; Thu, 07 May 2015 03:35:09 -0400 Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 7 May 2015 08:35:06 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id A25AD219004D for ; Thu, 7 May 2015 08:34:46 +0100 (BST) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t477Z4xw3473696 for ; Thu, 7 May 2015 07:35:04 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t477Z3xF020200 for ; Thu, 7 May 2015 01:35:04 -0600 Date: Thu, 7 May 2015 09:35:01 +0200 From: Michael Mueller Message-ID: <20150507093501.1ac2f993@bee> In-Reply-To: <20150506170616.GF17796@thinpad.lan.raisama.net> References: <1430146411-34632-1-git-send-email-mimu@linux.vnet.ibm.com> <1430146411-34632-2-git-send-email-mimu@linux.vnet.ibm.com> <20150505135547.GR17796@thinpad.lan.raisama.net> <20150505181216.5b754d24@bee> <20150505174101.GV17796@thinpad.lan.raisama.net> <20150506111720.46e93edd@bee> <20150506112332.GZ17796@thinpad.lan.raisama.net> <20150506182305.0f533cf9@bee> <20150506170616.GF17796@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6 01/17] Introduce stub routine cpu_desc_avail List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Cornelia Huck , Gleb Natapov , qemu-devel@nongnu.org, Alexander Graf , Christian Borntraeger , "Jason J. Herne" , Daniel Hansel , Paolo Bonzini , Andreas Faerber , Richard Henderson On Wed, 6 May 2015 14:06:16 -0300 Eduardo Habkost wrote: > On Wed, May 06, 2015 at 06:23:05PM +0200, Michael Mueller wrote: > > On Wed, 6 May 2015 08:23:32 -0300 > > Eduardo Habkost wrote: > [...] > > > > > > cpudef_init(); > > > > > > > > > > > > if (cpu_model && cpu_desc_avail() && is_help_option(cpu_model)) { > > > > > > list_cpus(stdout, &fprintf, cpu_model); > > > > > > exit(0); > > > > > > } > > > > > > > > > > > > That is because the output does not solely depend on static definitions > > > > > > but also on runtime context. Here the host machine type this instance of > > > > > > QEMU is running on, at least for the KVM case. > > > > > > > > > > Is this a required feature? I would prefer to have the main() code > > > > > simple even if it means not having runnable information in "-cpu ?" by > > > > > now (about possible ways to implement this without cpu_desc_avail(), see > > > > > below). > > > > > > > > I think it is more than a desired feature because one might end up with a failed > > > > CPU object instantiation although the help screen claims to CPU model to be valid. > > > > > > I think you are more likely to confuse users by not showing information > > > on "-cpu ?" when -machine is not present. I believe most people use > > > "-cpu ?" with no other arguments, to see what the QEMU binary is capable > > > of. > > > > I don't disagree with that, both cases are to some extend confusing... > > But the accelerator makes a big difference and a tended user should really be aware > > of that. > > > > Also that TCG is the default: > > > > $ ./s390x-softmmu/qemu-system-s390x -cpu ? > > s390 host > > > > And I don't see a way to make a user belief that all the defined CPU models are available to > > a TCG user in the S390 case where most of the CPU facilities are not implemented. > > Well, we could simply add a "KVM required" note (maybe just an asterisk beside > the CPU model description). But maybe we have a reasonable alternative below: > > > > > > > > > Anyway, whatever we decide to do, I believe we should start with > > > something simple to get things working, and after that we can look for > > > ways improve the help output with "runnable" info. > > > > I don't see how to solve this without cpu_desc_avail() or some other comparable mechanism, the > > aliases e.g. are also dynamic... > > What bothers me in cpu_desc_avail() is that it depends on global state that is > non-trivial (one needs to follow the whole KVM initialization path to find out > if cpu_desc_avail() will be true or false). > > We could instead simply skip the cpu_list() call unconditionally on s390. e.g.: > > target-s390x/cpu.h: > /* Delete the existing cpu_list macro */ > > cpus.c: > int list_cpus(FILE *f, fprintf_function cpu_fprintf, const char *optarg) > { > #if defined(cpu_list) > cpu_list(f, cpu_fprintf); > return 1; > #else > return 0; > #endif > } > > vl.c: > if (cpu_model && is_help_option(cpu_model)) { > /* zero list_cpus() return value means "-cpu ?" will be > * handled later by machine initialization code */ > if (list_cpus(stdout, &fprintf, cpu_model)) { > exit(0); > } > } That approach is will do the job as well. I will prepare a patch for the next version. Thanks! > > [...] > > > > > > About "-cpu ?": do we really want it to depend on -machine processing? > > > Today, help output shows what the QEMU binary is capable of, not just > > > what the host system and -machine option are capable of. > > > > I think we have to take it into account because the available CPU models might > > deviate substantially as in the case for S390 for KVM and TCG. > > That's true, on s390 the set of available CPU models is very different on both > cases. It breaks assumptions in the existing "-cpu ?" handling code in main(). > > > > > > > > > If we decide to change that assumption, let's do it in a generic way and > > > not as a arch-specific hack. The options I see are: > > > > welcome > > > > > > > > 1) Continue with the current policy where "-cpu ?" does not depend on > > > -machine arguments, and show all CPU models on "-cpu ?". > > > 2) Deciding that, yes, it is OK to make "-cpu ?" depend on -machine > > > arguments, and move the list_cpus() call after machine initialization > > > inside generic main() code for all arches. > > > 2.1) We could delay the list_cpus() call inside main() on all cases. > > > 2.2) We could delay the list_cpus() call inside main() only if > > > an explicit -machine option is present. > > > > > > I prefer (1) and my second choice would be (2.2), but the main point is > > > that none of the options above require making s390 special and > > > introducing cpu_desc_avail(). > > > > My take here is 2.1 because omitting option -machine is a decision to some > > defaults for machine type and accelerator type already. > > The problem with 2.1 is that some machine init functions require that > additional command-line parameters are set and will abort (e.g. mips machines). > So we can't do that unconditionally for all architectures. > > The proposal above is like 2.1, but conditional: it will delay "-cpu ?" > handling only on architectures that don't define cpu_list(). perfect. Michael >