All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhao Liu <zhao1.liu@intel.com>
To: Ani Sinha <anisinha@redhat.com>
Cc: Sergio Lopez <slp@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Eduardo Habkost <eduardo@habkost.net>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	imammedo@redhat.com, qemu-devel@nongnu.org
Subject: Re: [PATCH v3] hw/i386/cpu: remove default_cpu_version and simplify
Date: Tue, 21 Jan 2025 19:48:02 +0800	[thread overview]
Message-ID: <Z4+Jct1P0Tj4tobY@intel.com> (raw)
In-Reply-To: <20250116033418.226051-1-anisinha@redhat.com>

Hi Ani,

Sorry for late reply.

On Thu, Jan 16, 2025 at 09:04:18AM +0530, Ani Sinha wrote:
> Date: Thu, 16 Jan 2025 09:04:18 +0530
> From: Ani Sinha <anisinha@redhat.com>
> Subject: [PATCH v3] hw/i386/cpu: remove default_cpu_version and simplify
> X-Mailer: git-send-email 2.45.2
> 
> commit 0788a56bd1ae3 ("i386: Make unversioned CPU models be aliases")
> introduced 'default_cpu_version' for PCMachineClass. This created three
> categories of CPU models:
>  - Most unversioned CPU models would use version 1 by default.
>  - For machines 4.0.1 and older that do not support cpu model aliases, a
>    special default_cpu_version value of CPU_VERSION_LEGACY is used.
>  - It was thought that future machines would use the latest value of cpu
>    versions corresponding to default_cpu_version value of
>    CPU_VERSION_LATEST [1].
> 
> All pc machines still use the default cpu version of 1 for
> unversioned cpu models. CPU_VERSION_LATEST is a moving target and
> changes with time. Therefore, if machines use CPU_VERSION_LATEST, it would
> mean that over a period of time, for the same machine type, the cpu version
> would be different depending on what is latest at that time. This would
> break guests even when they use a constant machine type. Therefore, for
> pc machines, use of CPU_VERSION_LATEST is not possible. Currently, only
> microvms use CPU_VERSION_LATEST.
> 
> This change cleans up the complicated logic around default_cpu_version
> including getting rid of default_cpu_version property itself. A couple of new
> flags are introduced, one for the legacy model for machines 4.0.1 and older
> and other for microvms. For older machines, a new pc machine property is
> introduced that separates pc machine versions 4.0.1 and older from the newer
> machines. 4.0.1 and older machines are scheduled to be deleted towards
> end of 2025 since they would be 6 years old by then. At that time, we can
> remove all logic around legacy cpus. Microvms are the only machines that
> continue to use the latest cpu version. If this changes later, we can
> remove all logic around x86_cpu_model_last_version(). Default cpu version
> for unversioned cpu models is hardcoded to the value 1 and applies
> unconditionally for all pc machine types of version 4.1 and above.
> 
> This change also removes all complications around CPU_VERSION_AUTO
> including removal of the value itself.

I like the idea to remove CPU_VERSION_AUTO. Though this patch introduces
2 more new static variables ("use_legacy_cpu" and "use_last_cpu_version"),
as you said, once 4.0.1 and older machines are removed, it's easy to
clean up "use_legacy_cpu".

> 1) See commit dcafd1ef0af227 ("i386: Register versioned CPU models")
> 
> CC: imammedo@redhat.com
> Signed-off-by: Ani Sinha <anisinha@redhat.com>
> ---

[snip]

> -void x86_cpus_init(X86MachineState *x86ms, int default_cpu_version)
> +void x86_legacy_cpus_init(X86MachineState *x86ms)
> +{
> +    machine_uses_legacy_cpu();
> +    x86_cpus_init(x86ms);
> +}
> +
> +void x86_cpus_init_with_latest_cpu_version(X86MachineState *x86ms)
> +{
> +    x86_cpu_uses_lastest_version();
> +    x86_cpus_init(x86ms);
> +}

Could we simplify it even further, i.e., omit these two new helpers and
just add x86_cpu_uses_lastest_version() and machine_uses_legacy_cpu() to
the initialization of the PC & microvm, e.g.,

--- a/hw/i386/microvm.c
+++ b/hw/i386/microvm.c
@@ -458,7 +458,8 @@ static void microvm_machine_state_init(MachineState *machine)

     microvm_memory_init(mms);

-    x86_cpus_init_with_latest_cpu_version(x86ms);
+    x86_cpu_uses_lastest_version();
+    x86_cpus_init(x86ms);

     microvm_devices_init(mms);
 }

and

--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -138,11 +138,10 @@ static inline void pc_init_cpus(MachineState *ms)

     if (pcmc->no_versioned_cpu_model) {
         /* use legacy cpu as it does not support versions */
-        x86_legacy_cpus_init(x86ms);
-    } else {
-        /* use non-legacy cpus */
-        x86_cpus_init(x86ms);
+        machine_uses_legacy_cpu();
     }
+
+    x86_cpus_init(x86ms);
 }

 /* ioapic.c */

[snip]

> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index a558705cb9..ad43a233d8 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -92,9 +92,6 @@ struct PCMachineClass {
>  
>      /* Compat options: */
>  
> -    /* Default CPU model version.  See x86_cpu_set_default_version(). */
> -    int default_cpu_version;
> -
>      /* ACPI compat: */
>      bool has_acpi_build;
>      int pci_root_uid;
> @@ -125,11 +122,29 @@ struct PCMachineClass {
>       * check for memory.
>       */
>      bool broken_32bit_mem_addr_check;
> +
> +    /* whether the machine supports versioned cpu models */
> +    bool no_versioned_cpu_model;
>  };
>  
>  #define TYPE_PC_MACHINE "generic-pc-machine"
>  OBJECT_DECLARE_TYPE(PCMachineState, PCMachineClass, PC_MACHINE)
>  
> +static inline void pc_init_cpus(MachineState *ms)

I think there's no need to declare as `inline`.

> +{
> +    X86MachineState *x86ms = X86_MACHINE(ms);
> +    PCMachineState *pcms = PC_MACHINE(ms);
> +    PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
> +
> +    if (pcmc->no_versioned_cpu_model) {
> +        /* use legacy cpu as it does not support versions */
> +        x86_legacy_cpus_init(x86ms);
> +    } else {
> +        /* use non-legacy cpus */
> +        x86_cpus_init(x86ms);
> +    }
> +}
> +
>  /* ioapic.c */

As my comment above, we can just call machine_uses_legacy_cpu()
if pcmc->no_versioned_cpu_model is true.

[snip]

> -/*
> - * We resolve CPU model aliases using -v1 when using "-machine
> - * none", but this is just for compatibility while libvirt isn't
> - * adapted to resolve CPU model versions before creating VMs.
> - * See "Runnability guarantee of CPU models" at
> - * docs/about/deprecated.rst.
> - */
> -X86CPUVersion default_cpu_version = 1;
> +static bool use_legacy_cpu;
> +void machine_uses_legacy_cpu(void)

What about this name, "x86_cpu_set_legacy_version"?

> +{
> +    use_legacy_cpu = true;
> +}
>  
> -void x86_cpu_set_default_version(X86CPUVersion version)
> +static bool use_last_cpu_version;

Maybe "use_lastest_cpu"? Keep it in the same style as "use_legacy_cpu".

> +void x86_cpu_uses_lastest_version(void)

Similarly, What about "x86_cpu_set_latest_version"?

>  {
> -    /* Translating CPU_VERSION_AUTO to CPU_VERSION_AUTO doesn't make sense */
> -    assert(version != CPU_VERSION_AUTO);
> -    default_cpu_version = version;
> +    use_last_cpu_version = true;
>  }
>  
>  static X86CPUVersion x86_cpu_model_last_version(const X86CPUModel *model)
> @@ -5376,14 +5375,11 @@ static X86CPUVersion x86_cpu_model_last_version(const X86CPUModel *model)
>  /* Return the actual version being used for a specific CPU model */
>  static X86CPUVersion x86_cpu_model_resolve_version(const X86CPUModel *model)
>  {
> -    X86CPUVersion v = model->version;
> -    if (v == CPU_VERSION_AUTO) {
> -        v = default_cpu_version;
> -    }
> -    if (v == CPU_VERSION_LATEST) {
> +    if (use_last_cpu_version) {
>          return x86_cpu_model_last_version(model);
>      }
> -    return v;
> +
> +    return model->version;
>  }
>  
>  static const Property max_x86_cpu_properties[] = {
> @@ -5987,6 +5983,12 @@ static char *x86_cpu_class_get_alias_of(X86CPUClass *cc)
>      if (!cc->model || !cc->model->is_alias) {
>          return NULL;
>      }
> +
> +    if (use_legacy_cpu) {
> +        /* legacy cpu models do not support cpu aliases */
> +        return NULL;
> +    }
> +
>      version = x86_cpu_model_resolve_version(cc->model);
>      if (version <= 0) {

I understand this non-NULL check is origianl for legacy CPU version.
So it's also necessary to remove it, or convert it to "assert(version)"?

>          return NULL;
> @@ -6004,11 +6006,7 @@ static void x86_cpu_list_entry(gpointer data, gpointer user_data)
>      g_autofree char *model_id = x86_cpu_class_get_model_id(cc);
>  
>      if (!desc && alias_of) {
> -        if (cc->model && cc->model->version == CPU_VERSION_AUTO) {
> -            desc = g_strdup("(alias configured by machine type)");
> -        } else {
>              desc = g_strdup_printf("(alias of %s)", alias_of);
> -        }
>      }
>      if (!desc && cc->model && cc->model->note) {
>          desc = g_strdup_printf("%s [%s]", model_id, cc->model->note);
> @@ -6115,7 +6113,7 @@ static void x86_cpu_definition_entry(gpointer data, gpointer user_data)
>       * Old machine types won't report aliases, so that alias translation
>       * doesn't break compatibility with previous QEMU versions.
>       */
> -    if (default_cpu_version != CPU_VERSION_LEGACY) {
> +    if (!use_legacy_cpu) {
>          info->alias_of = x86_cpu_class_get_alias_of(cc);
>      }

Do we need the check of "!use_legacy_cpu"?

x86_cpu_class_get_alias_of() returns NULL if use_legacy_cpu is true.

Thanks,
Zhao



  parent reply	other threads:[~2025-01-21 11:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-16  3:34 [PATCH v3] hw/i386/cpu: remove default_cpu_version and simplify Ani Sinha
2025-01-21  3:29 ` Ani Sinha
2025-01-21 11:48 ` Zhao Liu [this message]
2025-01-22 12:09   ` Ani Sinha

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=Z4+Jct1P0Tj4tobY@intel.com \
    --to=zhao1.liu@intel.com \
    --cc=anisinha@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=imammedo@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=slp@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.