On 10/27/2025 7:18 PM, Zhao Liu wrote:
On Mon, Oct 27, 2025 at 06:19:40PM +0800, Zhao Liu wrote:
Date: Mon, 27 Oct 2025 18:19:40 +0800
From: Zhao Liu <[email protected]>
Subject: Re: [PATCH v3 10/20] i386/cpu: Add missing migratable xsave
features
Though the feature expansion in x86_cpu_expand_features() under
if (xcc->max_features) {
...
}
only enables migratable features when cpu->migratable is true,
x86_cpu_enable_xsave_components() overwrite the value later.
I have not changed the related logic, and this was intentional...too,
which is planed to be cleaned up after CET.
There's only 1 use case of migratable_flags, so I would try to drop
it directly.
The xsave-managed/enabled feature is not suitable as the configurable
feature. Therefore, it is best to keep it non-configurable as it is
currently.
At least with this fix, the support for the new xsave feature —
including APX next — will not be broken,
can you elaborate what will be broken without the patch?
As I see, we can drop the .migratable_flags directly.
migrable_flags is only used in x86_cpu_get_migratable_flags(), which is
only called by x86_cpu_get_supported_feature_word() when passed @cpu is
not null and cpu->migratable is true. So it only affects the case of
x86_cpu_expand_features()
-> x86_cpu_get_supported_feature_word()
And only FEAT_XSAVE_XCR0_LO defines .migratable_flags
As I commented earlier, though the .migrable_flags determines the return
value of x86_cpu_get_supported_feature_word() for
features[FEAT_XSAVE_XCR0_LO] in x86_cpu_expand_features(), eventually
the x86_cpu_enable_xsave_components() overwrites
features[FEAT_XSAVE_XCR0_LO]. So even we set the migratable_flags to 0
for FEAT_XSAVE_XCR0_LO, it doesn't have any issue.
So I think we can remove migratable_flags totally.
and the migratable flag
refactoring will become a separate RFC.
Regards,
Zhao
