[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>