qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] hw/i386/cpu: remove default_cpu_version and simplify


From: Ani Sinha
Subject: Re: [PATCH] hw/i386/cpu: remove default_cpu_version and simplify
Date: Tue, 10 Dec 2024 20:13:38 +0530


> On 9 Dec 2024, at 9:08 PM, Ani Sinha <anisinha@redhat.com> wrote:
> 
> 
> 
>> On 9 Dec 2024, at 8:40 PM, Zhao Liu <zhao1.liu@intel.com> wrote:
>> 
>> +Daniel,
>> 
>> On Sun, Dec 08, 2024 at 12:18:10PM +0530, Ani Sinha wrote:
>>> Date: Sun,  8 Dec 2024 12:18:10 +0530
>>> From: Ani Sinha <anisinha@redhat.com>
>>> Subject: [PATCH] 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].
>>> 
>>> Unfortunately, all pc machines still use the default cpu version of 1 for
>>> unversioned cpu models. Only microvms use CPU_VERSION_LATEST.
>> 
>> Hi Ani,
>> 
>> So could we use CPU_VERSION_LATEST for other machines now?
>> 
>> Mapping unversioned cpu models to the latest version sounds like more
>> user friendly.
> 
> Note that even though that was the intention when default_cpu_version was 
> introduced, it was never done that way. We have been using cpu version 1 for 
> a long time.

Had a conversation with Igor offline. CPU_VERSION_LATEST does not work since 
it’s a moving target. Therefore for a specific machine, what version of cpu 
model will be chosen will depend on what is latest and this will change with 
time. It can break guests that stick to a single cpu model.

One way to fix this would be to keep a fixed mapping between cpu model and 
machine versions. However, it will be a nightmare to maintain such mappings.

> 
>> 
>> Regards,
>> Zhao
>> 
>>> 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.
>>> 
>>> 1) See commit dcafd1ef0af227 ("i386: Register versioned CPU models")
>>> 
>>> CC: imammedo@redhat.com
>>> Signed-off-by: Ani Sinha <anisinha@redhat.com>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]