On 10/30/2025 11:56 PM, Zhao Liu wrote:
can you elaborate what will be broken without the patch?
Obviously, the migratable_flags has been broken.
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.
No. this seemingly 'correct' result what you see is just due to
different bugs influencing each other: the flags are wrong, the code
path is wrong, and the impact produced by the flags is also wrong.
So I think we can remove migratable_flags totally.
migratable_flags is used for feature leaves that are non-migratable by
default, while unmigratable_flags is used for feature leaves that are
migratable by default. Simply removing it doesn't need much effort, but
additional clarification is needed - about whether and how it affects
the migratable/unmigratable feature setting. Therefore, it's better to
do such refactor in the separate thread rather than combining it with
CET for now.
I meant we don't need to bother touching .migratable_flags field as this
patch because it doesn't make any difference to the functionality. Just
drop it from the series and feel free to clean it up with a separate series.
Regards,
Zhao
