From: Paolo Bonzini <pbonzini@redhat.com>
To: Ani Sinha <anisinha@redhat.com>, Sergio Lopez <slp@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>,
Zhao Liu <zhao1.liu@intel.com>
Cc: imammedo@redhat.com, qemu-devel@nongnu.org
Subject: Re: [PATCH v2] microvm: do not use the lastest cpu version
Date: Tue, 18 Mar 2025 12:01:44 +0100 [thread overview]
Message-ID: <004396c0-8370-4015-b746-3c800f45984f@redhat.com> (raw)
In-Reply-To: <20250220065326.312596-1-anisinha@redhat.com>
On 2/20/25 07:53, Ani Sinha wrote:
> 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.
Personally I believe this is a problem and I'd rather use
CPU_VERSION_LATEST for the unversioned pc and q35 models, just like
microvm does.
Unversioned models change the hardware properties and there's no reason
for CPU properties to be treated differently. Unversioned models are
exactly for when you are okay with a moving target.
And independent of this, microvm could start having versioned variants,
so that pc and q35 work the same way.
Paolo
next prev parent reply other threads:[~2025-03-18 11:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-20 6:53 [PATCH v2] microvm: do not use the lastest cpu version Ani Sinha
2025-02-20 7:25 ` Zhao Liu
2025-03-01 15:34 ` Ani Sinha
2025-03-05 7:54 ` Ani Sinha
2025-03-05 13:42 ` Stefan Hajnoczi
2025-03-05 14:26 ` Ani Sinha
2025-03-18 5:13 ` Ani Sinha
2025-03-18 11:01 ` Paolo Bonzini [this message]
2025-03-18 13:33 ` Michael S. Tsirkin
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=004396c0-8370-4015-b746-3c800f45984f@redhat.com \
--to=pbonzini@redhat.com \
--cc=anisinha@redhat.com \
--cc=eduardo@habkost.net \
--cc=imammedo@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=slp@redhat.com \
--cc=zhao1.liu@intel.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).