All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@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>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"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>
Subject: Re: [Qemu-devel] [PATCH v1] s390x/cpu_models: Add "-cpu max" support
Date: Wed, 25 Jul 2018 14:09:25 -0300	[thread overview]
Message-ID: <20180725170925.GE12380@localhost.localdomain> (raw)
In-Reply-To: <20180725091233.3300-1-david@redhat.com>

On Wed, Jul 25, 2018 at 11:12:33AM +0200, David Hildenbrand 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
> - msa5-base
> - zpci
> 
> 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
> 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(-)
> 
> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> index 604898a882..708bf0e3ba 100644
> --- a/target/s390x/cpu_models.c
> +++ b/target/s390x/cpu_models.c
> @@ -307,7 +307,10 @@ static gint s390_cpu_list_compare(gconstpointer a, gconstpointer b)
>      const char *name_a = object_class_get_name((ObjectClass *)a);
>      const char *name_b = object_class_get_name((ObjectClass *)b);
>  
> -    /* move qemu and host to the top of the list, qemu first, host second */
> +    /*
> +     * Move qemu, host and max to the top of the list, qemu first, host second,
> +     * max third.
> +     */
>      if (name_a[0] == 'q') {
>          return -1;
>      } else if (name_b[0] == 'q') {
> @@ -316,6 +319,10 @@ static gint s390_cpu_list_compare(gconstpointer a, gconstpointer b)
>          return -1;
>      } else if (name_b[0] == 'h') {
>          return 1;
> +    } else if (name_a[0] == 'm') {
> +        return -1;
> +    } else if (name_b[0] == 'm') {
> +        return 1;
>      }

Isn't it simpler to add a S390CPUClass::ordering field?  See
x86_cpu_list_compare() for an example.


>  
>      /* keep the same order we have in our table (sorted by release date) */
> @@ -1077,27 +1084,6 @@ static void s390_cpu_model_initfn(Object *obj)
>      }
>  }
>  
> -#ifdef CONFIG_KVM
> -static void s390_host_cpu_model_initfn(Object *obj)
> -{
> -    S390CPU *cpu = S390_CPU(obj);
> -    Error *err = NULL;
> -
> -    if (!kvm_enabled() || !kvm_s390_cpu_models_supported()) {
> -        return;
> -    }
> -
> -    cpu->model = g_malloc0(sizeof(*cpu->model));
> -    kvm_s390_get_host_cpu_model(cpu->model, &err);
> -    if (err) {
> -        error_report_err(err);
> -        g_free(cpu->model);
> -        /* fallback to unsupported cpu models */
> -        cpu->model = NULL;
> -    }
> -}
> -#endif
> -
>  static S390CPUDef s390_qemu_cpu_def;
>  static S390CPUModel s390_qemu_cpu_model;
>  
> @@ -1136,6 +1122,30 @@ static void s390_qemu_cpu_model_initfn(Object *obj)
>      memcpy(cpu->model, &s390_qemu_cpu_model, sizeof(*cpu->model));
>  }
>  
> +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;
> +    }

What's the use case that requires this check to be here?

What do you expect 'query-cpu-model-expansion model=max' to
return if !kvm_s390_cpu_models_supported()?


> +
> +    max_model = get_max_cpu_model(&local_err);

I've just confirmed that get_max_cpu_model() is already ready to
work with TCG.

> +    if (local_err) {
> +        g_assert(kvm_enabled());
> +        error_report_err(local_err);
> +        /* fallback to unsupported CPU models */
> +        return;

What about moving this outside instance_init?

On x86 we have a x86_cpu_expand_features() function to allow us
to handle CPU model expansion errors more gracefully.

None of my comments are about new code, but existing code from
"host", so:

Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>

> +    }
> +
> +    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);
> @@ -1209,6 +1219,20 @@ static void s390_qemu_cpu_model_class_init(ObjectClass *oc, void *data)
>                                  qemu_hw_version());
>  }
>  
> +static void s390_max_cpu_model_class_init(ObjectClass *oc, void *data)
> +{
> +    S390CPUClass *xcc = S390_CPU_CLASS(oc);
> +
> +    /*
> +     * The "max" model is neither static nor migration safe. Under KVM
> +     * it represents the "host" model. Under TCG it represents some kind of
> +     * "qemu" CPU model without compat handling and maybe with some additional
> +     * CPU features that are not yet unlocked in the "qemu" model.
> +     */
> +    xcc->desc =
> +        "Enables all features supported by the accelerator in the current host";
> +}
> +
>  /* Generate type name for a cpu model. Caller has to free the string. */
>  static char *s390_cpu_type_name(const char *model_name)
>  {
> @@ -1239,12 +1263,18 @@ static const TypeInfo qemu_s390_cpu_type_info = {
>      .class_init = s390_qemu_cpu_model_class_init,
>  };
>  
> +static const TypeInfo max_s390_cpu_type_info = {
> +    .name = S390_CPU_TYPE_NAME("max"),
> +    .parent = TYPE_S390_CPU,
> +    .instance_init = s390_max_cpu_model_initfn,
> +    .instance_finalize = s390_cpu_model_finalize,
> +    .class_init = s390_max_cpu_model_class_init,
> +};
> +
>  #ifdef CONFIG_KVM
>  static const TypeInfo host_s390_cpu_type_info = {
>      .name = S390_CPU_TYPE_NAME("host"),
> -    .parent = TYPE_S390_CPU,
> -    .instance_init = s390_host_cpu_model_initfn,
> -    .instance_finalize = s390_cpu_model_finalize,
> +    .parent = S390_CPU_TYPE_NAME("max"),
>      .class_init = s390_host_cpu_model_class_init,
>  };
>  #endif
> @@ -1326,6 +1356,7 @@ static void register_types(void)
>      }
>  
>      type_register_static(&qemu_s390_cpu_type_info);
> +    type_register_static(&max_s390_cpu_type_info);
>  #ifdef CONFIG_KVM
>      type_register_static(&host_s390_cpu_type_info);
>  #endif
> -- 
> 2.17.1
> 

-- 
Eduardo

  parent reply	other threads:[~2018-07-25 17:09 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
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 [this message]
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=20180725170925.GE12380@localhost.localdomain \
    --to=ehabkost@redhat.com \
    --cc=agraf@suse.de \
    --cc=berrange@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=cventeic@redhat.com \
    --cc=david@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.