From: Eduardo Habkost <ehabkost@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"David Hildenbrand" <david@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Halil Pasic" <pasic@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@de.ibm.com>,
"Aleksandar Markovic" <aleksandar.qemu.devel@gmail.com>,
"Richard Henderson" <rth@twiddle.net>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Aleksandar Rikalo" <aleksandar.rikalo@syrmia.com>,
"Eduardo Habkost" <ehabkost@redhat.com>,
qemu-s390x@nongnu.org, qemu-arm@nongnu.org,
"Cleber Rosa" <crosa@redhat.com>,
"Jiri Denemark" <jdenemar@redhat.com>,
"David Gibson" <david@gibson.dropbear.id.au>,
"Daniel P. Berrange" <berrange@redhat.com>,
"Cornelia Huck" <cohuck@redhat.com>,
qemu-ppc@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
"Aurelien Jarno" <aurelien@aurel32.net>
Subject: [PATCH v2 0/7] i386: Add `machine` parameter to query-cpu-definitions
Date: Tue, 13 Oct 2020 19:04:50 -0400 [thread overview]
Message-ID: <20201013230457.150630-1-ehabkost@redhat.com> (raw)
Changes v1 -> v2:
* Rewrite documentation, with suggestions from Markus
* Try to reduce churn and keep the existing default_cpu_version
static variable
* Replace x86_cpu_class_get_alias_of() with x86_cpu_model_resolve_alias()
Link to v1:
https://lore.kernel.org/qemu-devel/20191025022553.25298-1-ehabkost@redhat.com
We had introduced versioned CPU models in QEMU 4.1, including a
method for querying for CPU model versions using
query-cpu-definitions. This solution had 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.
About CPU model versioning vs query-cpu-model-expansion
-------------------------------------------------------
There had been some discussion[1] about using a mechanism for
this similar to what's done in s390x, based on
query-cpu-model-expansion. I had considered that approach in the
beginning, but this would require
query-cpu-model-expansion type=static
to resolve to a useful base CPU model that is static.
Unfortunately, we have no useful static CPU model in x86 yet,
except for "base", because of the complex accelerator-dependent
rules that affect expansion of CPU models. Maybe in the future
we'll be able to define static versions of each CPU model, and
unify the CPU model versioning approaches in all architectures.
While we don't have this, we need to work with what we have.
What we have today in x86 are CPU models that are not static and
not accelerator-independent.
[1] https://lore.kernel.org/qemu-devel/dbf9e4c1-0acf-9469-84f9-f80c41e2cae0@redhat.com/
Eduardo Habkost (7):
machine: machine_find_class() function
i386: Add X86CPUModel.alias_of field
i386: Replace x86_cpu_class_get_alias_of() with
x86_cpu_model_resolve_alias()
i386: Add default_version parameter to CPU version functions
i386: Wrap QMP code in !CONFIG_USER_ONLY
i386: Don't use default_cpu_version inside x86_cpu_definition_entry()
cpu: Add `machine` parameter to query-cpu-definitions
qapi/machine-target.json | 14 ++-
include/hw/boards.h | 2 +
hw/core/machine.c | 16 ++++
softmmu/vl.c | 17 +---
target/arm/helper.c | 4 +-
target/i386/cpu.c | 105 +++++++++++++++------
target/mips/helper.c | 4 +-
target/s390x/cpu_models.c | 4 +-
target/ppc/translate_init.c.inc | 4 +-
tests/acceptance/x86_cpu_model_versions.py | 48 ++++++++++
10 files changed, 167 insertions(+), 51 deletions(-)
--
2.28.0
next reply other threads:[~2020-10-13 23:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-13 23:04 Eduardo Habkost [this message]
2020-10-13 23:04 ` [PATCH v2 1/7] machine: machine_find_class() function Eduardo Habkost
2020-10-13 23:04 ` [PATCH v2 2/7] i386: Add X86CPUModel.alias_of field Eduardo Habkost
2020-10-13 23:04 ` [PATCH v2 3/7] i386: Replace x86_cpu_class_get_alias_of() with x86_cpu_model_resolve_alias() Eduardo Habkost
2020-10-13 23:04 ` [PATCH v2 4/7] i386: Add default_version parameter to CPU version functions Eduardo Habkost
2020-10-13 23:04 ` [PATCH v2 5/7] i386: Wrap QMP code in !CONFIG_USER_ONLY Eduardo Habkost
2020-10-13 23:04 ` [PATCH v2 6/7] i386: Don't use default_cpu_version inside x86_cpu_definition_entry() Eduardo Habkost
2020-10-13 23:04 ` [PATCH v2 7/7] cpu: Add `machine` parameter to query-cpu-definitions Eduardo Habkost
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=20201013230457.150630-1-ehabkost@redhat.com \
--to=ehabkost@redhat.com \
--cc=aleksandar.qemu.devel@gmail.com \
--cc=aleksandar.rikalo@syrmia.com \
--cc=armbru@redhat.com \
--cc=aurelien@aurel32.net \
--cc=berrange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=crosa@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=jdenemar@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
--cc=thuth@redhat.com \
--cc=wainersm@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).