From: Cornelia Huck <cohuck@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: qemu-s390x@nongnu.org, qemu-devel@nongnu.org,
"Richard Henderson" <rth@twiddle.net>,
"Alexander Graf" <agraf@suse.de>,
"Christian Borntraeger" <borntraeger@de.ibm.com>,
"Thomas Huth" <thuth@redhat.com>,
"Chris Venteicher" <cventeic@redhat.com>,
"Collin Walling" <walling@linux.ibm.com>,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v1] s390x/cpu_models: Add "-cpu max" support
Date: Wed, 25 Jul 2018 13:36:40 +0200 [thread overview]
Message-ID: <20180725133640.3ea78c59.cohuck@redhat.com> (raw)
In-Reply-To: <20180725091233.3300-1-david@redhat.com>
On Wed, 25 Jul 2018 11:12:33 +0200
David Hildenbrand <david@redhat.com> wrote:
> The "max" CPU model behaves like "-cpu host" when KVM is enabled, and like
> a CPU with the maximum possible feature set when TCG is enabled.
>
> While the "host" model can not be used under TCG ("kvm_required"), the
> "max" model can and "Enables all features supported by the accelerator in
> the current host".
>
> So we can treat "host" just as a special case of "max" (like x86 does).
> It differs to the "qemu" CPU model under TCG such that compatibility
> handling will not be performed and that some experimental CPU features
> not yet part of the "qemu" model might be indicated.
>
> These are right now under TCG (see "qemu_MAX"):
> - stfle53
That's a z13 feature, so I think it's fine as we don't care about
machine generations for the max mode anyway, correct?
> - msa5-base
That's just the warning, but as things are continuing to work, it's
fine as well.
> - zpci
That one theoretically has a dependency on CONFIG_PCI, but as that is
always set, I think it's fine as well.
>
> This will result right now in the following warning when starting QEMU TCG
> with the "max" model:
> "qemu-system-s390x: warning: 'msa5-base' requires 'kimd-sha-512'."
>
> The "qemu" model (used as default in QEMU under TCG) will continue to
> work without such warnings. The "max" mdel in the current form
s/mdel/model/
> might be interesting for kvm-unit-tests (where we would e.g. now also
> test "msa5-base").
>
> The "max" model is neither static nor migration safe (like the "host"
> model). It is independent of the machine but dependends on the accelerator.
> It can be used to detect the maximum CPU model also under TCG from upper
> layers without having to care about CPU model names for CPU model
> expansion.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> target/s390x/cpu_models.c | 81 +++++++++++++++++++++++++++------------
> 1 file changed, 56 insertions(+), 25 deletions(-)
>
> +static void s390_max_cpu_model_initfn(Object *obj)
> +{
> + const S390CPUModel *max_model;
> + S390CPU *cpu = S390_CPU(obj);
> + Error *local_err = NULL;
> +
> + if (kvm_enabled() && !kvm_s390_cpu_models_supported()) {
> + /* "max" and "host" always work, even without CPU model support */
> + return;
> + }
> +
> + max_model = get_max_cpu_model(&local_err);
> + if (local_err) {
> + g_assert(kvm_enabled());
Maybe add a comment that for kvm we try the host model, and only that
can fail (i.e., for tcg this will always work)?
> + error_report_err(local_err);
> + /* fallback to unsupported CPU models */
> + return;
> + }
> +
> + cpu->model = g_new(S390CPUModel, 1);
> + /* copy the CPU model so we can modify it */
> + memcpy(cpu->model, max_model, sizeof(*cpu->model));
> +}
> +
> static void s390_cpu_model_finalize(Object *obj)
> {
> S390CPU *cpu = S390_CPU(obj);
Looks sane to me.
next prev parent reply other threads:[~2018-07-25 11:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-25 9:12 [Qemu-devel] [PATCH v1] s390x/cpu_models: Add "-cpu max" support David Hildenbrand
2018-07-25 11:36 ` Cornelia Huck [this message]
2018-07-25 11:58 ` David Hildenbrand
2018-07-25 12:06 ` Cornelia Huck
2018-07-25 12:49 ` David Hildenbrand
2018-07-25 13:16 ` Cornelia Huck
2018-07-25 17:09 ` Eduardo Habkost
2018-07-25 17:50 ` David Hildenbrand
2018-07-25 20:14 ` Eduardo Habkost
2018-07-26 7:29 ` David Hildenbrand
2018-07-26 15:07 ` Eduardo Habkost
2018-07-27 14:57 ` [Qemu-devel] [qemu-s390x] " David Hildenbrand
2018-07-27 12:55 ` [Qemu-devel] " Cornelia Huck
2018-07-30 9:16 ` [Qemu-devel] [qemu-s390x] " David Hildenbrand
2018-07-30 20:13 ` Eduardo Habkost
2018-08-02 15:13 ` [Qemu-devel] " Cornelia Huck
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=20180725133640.3ea78c59.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=agraf@suse.de \
--cc=berrange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cventeic@redhat.com \
--cc=david@redhat.com \
--cc=ehabkost@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
--cc=thuth@redhat.com \
--cc=walling@linux.ibm.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.