On Wed, 2015-11-18 at 13:58 -0200, Eduardo Habkost wrote:
> On Wed, Nov 18, 2015 at 10:20:15AM +0800, Huaitong Han wrote:
> [...]
> > @@ -408,6 +420,13 @@ static FeatureWordInfo
> > feature_word_info[FEATURE_WORDS] = {
> > .cpuid_reg = R_EBX,
> > .tcg_features = TCG_7_0_EBX_FEATURES,
> > },
> > + [FEAT_7_0_ECX] = {
> > + .feat_names = cpuid_7_0_ecx_feature_name,
> > + .cpuid_eax = 7,
> > + .cpuid_needs_ecx = true, .cpuid_ecx = 0,
> > + .cpuid_reg = R_ECX,
> > + .tcg_features = TCG_7_0_ECX_FEATURES,
> > + },
>
> The patch looks good, but when we add the feature names to
> cpuid_7_0_ecx_feature_name, QEMU will consider them as
> migratable, but they are truly migratable only after we add the
> ext_save_areas entry.
> We can fix this by moving cpuid_7_0_ecx_feature_name to patch 2/3
> (or to a separate patch, to be applied after 2/3).
I understand it has always been that QEMU considers the feature of
cpuid_7_0_ecx_feature_name as migratable. If the feature is
unmigratable, it will been added to unmigratable_flags.
A series of patches do complete a full function, moving
cpuid_7_0_ecx_feature_name to 2/3 patch may make 2/3 patch look
better, but make 1/3 patch look somewhat incomplete.
Maybe it is a solution that adding the feature to unmigratable_flags in
1/3 patch, and deleting unmigratable_flags in 2/3 patch, but I think it
is pointless.
��.n��������+%������w��{.n�����o�^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
