All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Igor Mammedov <imammedo@redhat.com>
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
	"Anthony Liguori" <aliguori@us.ibm.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Andreas Färber" <afaerber@suse.de>, kvm <kvm@vger.kernel.org>
Subject: Re: [PATCH] target-i386: Improve x86_cpu_list output
Date: Wed, 27 Feb 2013 08:52:50 +0100	[thread overview]
Message-ID: <512DBB52.8040006@web.de> (raw)
In-Reply-To: <20130227083721.720ee6a3@thinkpad.mammed.net>

[-- Attachment #1: Type: text/plain, Size: 3034 bytes --]

On 2013-02-27 08:37, Igor Mammedov wrote:
> 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.

Actually, requiring "-enable-kvm -cpu ?" to list the host type would be
counterproductive - hardly any user will find this out, at best by
chance. However ...

> 
>>
>>>
>>>>  - 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.

...I will add "(only available in KVM mode)" here and wrap these lines
in #ifdef CONFIG_KVM. That should be more acceptable, no?

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  reply	other threads:[~2013-02-27  7:53 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
2013-02-27  7:52       ` Jan Kiszka [this message]
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=512DBB52.8040006@web.de \
    --to=jan.kiszka@web.de \
    --cc=afaerber@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --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.