From: Igor Mammedov <imammedo@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Anthony Liguori" <aliguori@us.ibm.com>,
"Jan Kiszka" <jan.kiszka@web.de>,
qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>,
"Andreas Färber" <afaerber@suse.de>
Subject: Re: [PATCH] target-i386: Improve x86_cpu_list output
Date: Wed, 27 Feb 2013 08:37:21 +0100 [thread overview]
Message-ID: <20130227083721.720ee6a3@thinkpad.mammed.net> (raw)
In-Reply-To: <20130227032638.GJ8494@otherpad.lan.raisama.net>
On Wed, 27 Feb 2013 00:26:38 -0300
Eduardo Habkost <ehabkost@redhat.com> wrote:
> On Tue, Feb 26, 2013 at 10:57:56PM +0100, Igor Mammedov wrote:
> > On Sat, 23 Feb 2013 16:45:00 +0100
> > Jan Kiszka <jan.kiszka@web.de> wrote:
> >
> > > From: Jan Kiszka <jan.kiszka@siemens.com>
> > >
> > > Several issues fixed:
> > > - We were missing a bunch of feature lists. Fix this by simply dumping
> > > the meta list feature_word_info.
> > > - kvm_enabled() cannot be true at this point because accelerators are
> > > initialized much later during init. Simply dump unconditionally.
> > Why not to move list_cpu after accelerators are initialized?
>
> Because help output is simply documentation and shouldn't depend on any
> other config option parsing or accelerator initialization at all?
Don't see reason why it shouldn't.
It's not a man page but a program and can do pretty much everything.
>
> >
> > > - Add explanation for "host" CPU type.
> > >
> > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> > > ---
> > > target-i386/cpu.c | 20 +++++++++-----------
> > > 1 files changed, 9 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> > > index dfcf86e..6e742f0 100644
> > > --- a/target-i386/cpu.c
> > > +++ b/target-i386/cpu.c
> > > @@ -1453,18 +1453,16 @@ void x86_cpu_list(FILE *f, fprintf_function cpu_fprintf)
> > > snprintf(buf, sizeof(buf), "%s", def->name);
> > > (*cpu_fprintf)(f, "x86 %16s %-48s\n", buf, def->model_id);
> > > }
> > > - if (kvm_enabled()) {
> > > - (*cpu_fprintf)(f, "x86 %16s\n", "[host]");
> > > - }
> > > + (*cpu_fprintf)(f, "x86 %16s %-48s\n", "host",
> > > + "KVM processor with all supported host features");
> > > +
> > that would make 'host' visible to users even if QEMU compiled without KVM
> > support. No big harm, but autotest could get confused when it gets 'host' CPU
> > but QEMU doesn't run because it's not really supported.
>
> Then we have to fix the autotest test code to not try it without KVM.
> :-)
>
> Help output is not a probing mechanism (although we often misuse it as
> if it were), and I expect help output to be static and not depend on any
> subsystem initialization.
Then fix help output and add to "host" line something like " is available with
-enable-kvm on command line and if your build was compiled --enable-kvm
configure option", otherwise 'host' is misleading.
Now even without 'host' in output of -cpu 'help', question why 'host' is not
found periodically pops up on IRC. This change will just increase frequency of
it.
>
> For example: an user without permission to open /dev/kvm should be still
> able to see help text explaining that "-cpu host" is available when KVM
> is enabled and working.
which is not correct, since it isn't available.
>
>
> >
> > > (*cpu_fprintf)(f, "\nRecognized CPUID flags:\n");
> > > - listflags(buf, sizeof(buf), (uint32_t)~0, feature_name, 1);
> > > - (*cpu_fprintf)(f, " %s\n", buf);
> > > - listflags(buf, sizeof(buf), (uint32_t)~0, ext_feature_name, 1);
> > > - (*cpu_fprintf)(f, " %s\n", buf);
> > > - listflags(buf, sizeof(buf), (uint32_t)~0, ext2_feature_name, 1);
> > > - (*cpu_fprintf)(f, " %s\n", buf);
> > > - listflags(buf, sizeof(buf), (uint32_t)~0, ext3_feature_name, 1);
> > > - (*cpu_fprintf)(f, " %s\n", buf);
> > > + for (i = 0; i < ARRAY_SIZE(feature_word_info); i++) {
> > > + FeatureWordInfo *fw = &feature_word_info[i];
> > > +
> > > + listflags(buf, sizeof(buf), (uint32_t)~0, fw->feat_names, 1);
> > > + (*cpu_fprintf)(f, " %s\n", buf);
> > > + }
> > > }
> > >
> > > CpuDefinitionInfoList *arch_query_cpu_definitions(Error **errp)
> > > --
> > > 1.7.3.4
> > >
> >
> >
> > --
> > Regards,
> > Igor
>
> --
> Eduardo
--
Regards,
Igor
next prev parent reply other threads:[~2013-02-27 7:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-23 15:45 [PATCH] target-i386: Improve x86_cpu_list output Jan Kiszka
2013-02-26 20:14 ` Eduardo Habkost
2013-02-26 21:57 ` Igor Mammedov
2013-02-27 3:26 ` Eduardo Habkost
2013-02-27 7:37 ` Igor Mammedov [this message]
2013-02-27 7:52 ` Jan Kiszka
2013-02-27 7:59 ` Andreas Färber
2013-02-27 8:35 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130227083721.720ee6a3@thinkpad.mammed.net \
--to=imammedo@redhat.com \
--cc=afaerber@suse.de \
--cc=aliguori@us.ibm.com \
--cc=ehabkost@redhat.com \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.