qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>, qemu-devel@nongnu.org
Cc: Thomas Huth <thuth@redhat.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Jiri Denemark <jdenemar@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH 0/7] i386: Add `machine` parameter to query-cpu-definitions
Date: Fri, 25 Oct 2019 09:17:46 +0200	[thread overview]
Message-ID: <dbf9e4c1-0acf-9469-84f9-f80c41e2cae0@redhat.com> (raw)
In-Reply-To: <20191025022553.25298-1-ehabkost@redhat.com>

On 25.10.19 04:25, Eduardo Habkost wrote:
> We had introduced versioned CPU models in QEMU 4.1, including a
> method for querying for CPU model versions using

Interesting, I was not aware of that.

On s390x, we somewhat have versioned CPU models, but we decided against 
giving them explicit names (e.g., z13-v1 or z13-4.1.0), because it 
didn't really seem to be necessary. (and we often implement/add features 
for older CPU models, there is a lot of fluctuation) Actually, you would 
have had to add "z13-z/VM-x.x.x" or "z13-LPAR-x.x.x" or "z13-KVM-x.x.x" 
to model the features you actually see in all the different virtual 
environments ("what a CPU looks like"). Not to talk about QEMU versions 
in addition to that. So we decided to always model what you would see 
under LPAR and are able to specify for a KVM guest. So you can use "z13" 
in an up-to-date LPAR environment, but not in a z/VM environment (you 
would have to disable features).

Each (!base) CPU model has a specific feature set per machine. Libvirt 
uses query-cpu-model-expansion() to convert this model+machine to a 
machine-independent representation. That representation is sufficient 
for all use cases we were aware of (esp. "virsh domcapabilities", the 
host CPU model, migration).

While s390x has versioned CPU models, we have no explicit way of 
specifying them for older machines, besides going over 
query-cpu-model-expansion and using expanded "base model + features".

I can see that this might make sense on x86-64, where you only have 
maybe 3 versions of a CPU (e.g., the one Intel messed up first - 
Haswell, the one Intel messed up next - Haswell-noTSX, and the one that 
Intel eventually did right - Haswell-noTSX-IBRS) and you might want to 
specify "Haswell" vs. "Haswell-IBRS" vs. "Haswell-noTSX-IBRS". But 
actually, you will always want to go for "Haswell-noTSX-IBRS", because 
you can expect to run in updated environments if I am not wrong, 
everything else are corner cases.

Of course, versioned CPU model are neat to avoid "base model + list of 
features", but at least for expanding the host model on s390x, it is not 
really helpful. When migrating, the model expansion does the trick.

I haven't looked into details of "how to specify or model versions". 
Maybe IBM wants to look into creating versions for all the old models we 
had. But again, not sure if that is of any help for s390x. CCing IBM.

> query-cpu-definitions.  This only has one problem: fetching CPU
> alias information for multiple machine types required restarting
> QEMU for each machine being queried.
> 
> This series adds a new `machine` parameter to
> query-cpu-definitions, that can be used to query CPU model alias
> information for multiple machines without restarting QEMU.
> 
> Eduardo Habkost (7):
>    i386: Use g_autofree at x86_cpu_list_entry()
>    i386: Add default_version parameter to CPU version functions
>    i386: Don't use default_cpu_version at "-cpu help"
>    machine: machine_find_class() function
>    i386: Remove x86_cpu_set_default_version() function
>    i386: Don't use default_cpu_version() inside query-cpu-definitions
>    cpu: Add `machine` parameter to query-cpu-definitions
> 
>   qapi/machine-target.json                   | 14 +++-
>   include/hw/boards.h                        |  1 +
>   include/hw/i386/pc.h                       |  5 +-
>   target/i386/cpu.h                          |  6 --
>   hw/core/machine.c                          | 16 ++++
>   hw/i386/pc.c                               |  3 -
>   target/arm/helper.c                        |  4 +-
>   target/i386/cpu.c                          | 93 +++++++++++++++-------
>   target/mips/helper.c                       |  4 +-
>   target/ppc/translate_init.inc.c            |  4 +-
>   target/s390x/cpu_models.c                  |  4 +-
>   vl.c                                       | 17 +---
>   tests/acceptance/x86_cpu_model_versions.py | 42 ++++++++++
>   13 files changed, 154 insertions(+), 59 deletions(-)
> 


-- 

Thanks,

David / dhildenb



  parent reply	other threads:[~2019-10-25  7:31 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-25  2:25 [PATCH 0/7] i386: Add `machine` parameter to query-cpu-definitions Eduardo Habkost
2019-10-25  2:25 ` [PATCH 1/7] i386: Use g_autofree at x86_cpu_list_entry() Eduardo Habkost
2019-10-25  2:25 ` [PATCH 2/7] i386: Add default_version parameter to CPU version functions Eduardo Habkost
2019-10-25  2:25 ` [PATCH 3/7] i386: Don't use default_cpu_version at "-cpu help" Eduardo Habkost
2019-10-25  2:25 ` [PATCH 4/7] machine: machine_find_class() function Eduardo Habkost
2019-10-25  2:25 ` [PATCH 5/7] i386: Remove x86_cpu_set_default_version() function Eduardo Habkost
2019-10-25  2:25 ` [PATCH 6/7] i386: Don't use default_cpu_version() inside query-cpu-definitions Eduardo Habkost
2019-10-25  2:25 ` [PATCH 7/7] cpu: Add `machine` parameter to query-cpu-definitions Eduardo Habkost
2019-10-25  6:36   ` Markus Armbruster
2019-10-25 13:22     ` Eduardo Habkost
2019-10-25  7:17 ` David Hildenbrand [this message]
2019-10-25  7:55   ` [PATCH 0/7] i386: " Christian Borntraeger
2019-10-25  8:02     ` David Hildenbrand
2019-10-25 13:49       ` Eduardo Habkost
2019-10-25 14:03       ` Daniel P. Berrangé
2019-10-25 14:23         ` David Hildenbrand
2019-10-25 15:00           ` Daniel P. Berrangé
2019-10-25 17:19             ` David Hildenbrand
2019-10-25 13:38   ` Eduardo Habkost
2019-10-25 14:10     ` David Hildenbrand
2019-10-25 19:02 ` no-reply

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=dbf9e4c1-0acf-9469-84f9-f80c41e2cae0@redhat.com \
    --to=david@redhat.com \
    --cc=armbru@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=imammedo@redhat.com \
    --cc=jdenemar@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).