Re: [Qemu-devel] [PATCH v3 1/3] target-i386: add pkeys support for cpuid handling

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

 



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���)ߣ�

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux