All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Bolognani <abologna@redhat.com>
To: Thomas Huth <thuth@redhat.com>, Eduardo Habkost <ehabkost@redhat.com>
Cc: David Gibson <david@gibson.dropbear.id.au>,
	qemu-ppc@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Bharata B Rao <bharata@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/2] vl: Print CPU help after we've registered the CPU accelerators
Date: Fri, 10 Mar 2017 13:40:36 +0100	[thread overview]
Message-ID: <1489149636.3805.38.camel@redhat.com> (raw)
In-Reply-To: <87e06501-0df6-8c02-e9c4-01ce8d52cd85@redhat.com>

On Tue, 2017-03-07 at 10:02 +0100, Thomas Huth wrote:
> The problem is that on POWER, we've got a "family" of CPUs with
> different sub-types, e.g. for POWER8:
> 
> $ qemu-system-ppc64 -cpu ? | grep POWER8
> PowerPC POWER8E_v2.1     PVR 004b0201
> PowerPC POWER8E          (alias for POWER8E_v2.1)
> PowerPC POWER8NVL_v1.0   PVR 004c0100
> PowerPC POWER8NVL        (alias for POWER8NVL_v1.0)
> PowerPC POWER8_v2.0      PVR 004d0200
> PowerPC POWER8           (alias for POWER8_v2.0)
> 
> Most of the users don't know about the current subtype that they are
> using, and just want to use "-cpu POWER8" - and for example we've also
> got an agreement with the libvirt folks that they can always use "-cpu
> POWER8" for any kind of POWER8 system, no matter whether the host is
> using a POWER8E or POWER8NVL chip.

Yup, thanks for bringing that up and keeping an eye out
to make sure it keeps working :)

> So the "POWER8" alias now gets updated internally in QEMU to the correct
> host CPU type ... but the output of "-cpu help" is then still wrong.
> I agree that it's kind of ugly to have different help texts depending on
> whether "accel=kvm" has been used or not, but that sounds still better
> to me than printing wrong information here.
> Thinking about this again ... maybe it would be better if we'd rework
> the help text to print out something like this instead:
> 
> PowerPC POWER8           (alias for any POWER8 chip)
> 
> ... so that we simply get rid of the version/subtype information here
> completely?

I was initially concerned about this, because I remembered
libvirt parsing the string after "(alias for ", but I
checked and it looks like we do so only for machine types,
not for CPU models.

So the change should be safe, and since we're using QMP to
fetch CPU definitions these days, I don't expect we'll need
to worry about this change even in the future.

Still, did you try changing the description and using the
resulting QEMU binary along with libvirt?

-- 
Andrea Bolognani / Red Hat / Virtualization

  parent reply	other threads:[~2017-03-10 12:40 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-31 13:11 [Qemu-devel] [PATCH 0/2] ppc: Fix problems with duplicated CPU family types Thomas Huth
2017-01-31 13:11 ` [Qemu-devel] [PATCH 1/2] ppc/kvm: Handle the "family" CPU via alias instead of registering new types Thomas Huth
2017-02-01  0:10   ` David Gibson
2017-02-01  7:39     ` Thomas Huth
2017-02-01 22:27       ` David Gibson
2017-01-31 13:11 ` [Qemu-devel] [PATCH 2/2] vl: Print CPU help after we've registered the CPU accelerators Thomas Huth
2017-02-01  0:08   ` David Gibson
2017-02-02  1:11     ` Paolo Bonzini
2017-03-03 14:58   ` Eduardo Habkost
2017-03-05 23:06     ` David Gibson
2017-03-06 11:47       ` Eduardo Habkost
2017-03-07  3:31         ` David Gibson
2017-03-07 12:02           ` Eduardo Habkost
2017-03-08  2:33             ` David Gibson
2017-03-08 12:08               ` Eduardo Habkost
2017-03-09  1:29                 ` David Gibson
2017-03-07  9:02     ` Thomas Huth
2017-03-07 12:07       ` Eduardo Habkost
2017-03-10 12:40       ` Andrea Bolognani [this message]
2017-03-08 14:31     ` Peter Maydell
2017-03-08 14:50       ` Eduardo Habkost
2017-03-08 15:50         ` Thomas Huth

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=1489149636.3805.38.camel@redhat.com \
    --to=abologna@redhat.com \
    --cc=agraf@suse.de \
    --cc=armbru@redhat.com \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=ehabkost@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=thuth@redhat.com \
    /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.