On Thu, 2018-09-20 at 14:22 -0300, Eduardo Habkost wrote:
> On Thu, Sep 20, 2018 at 03:45:42PM +0800, Robert Hoo wrote:
> [...]
> > > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > > > index a252c26..0160e97 100644
> > > > --- a/target/i386/cpu.c
> > > > +++ b/target/i386/cpu.c
> > > > @@ -3670,7 +3670,7 @@ static uint32_t
> > > > x86_cpu_get_supported_feature_word(FeatureWord w,
> > > > bool
> > > > migratable_only)
> > > > {
> > > > FeatureWordInfo *wi = &feature_word_info[w];
> > > > - uint32_t r;
> > > > + uint32_t r = 0;
> > > >
> > > > if (kvm_enabled()) {
> > > > switch (wi->type) {
> > > > @@ -3679,8 +3679,9 @@ static uint32_t
> > > > x86_cpu_get_supported_feature_word(FeatureWord w,
> > > > wi->cpuid.ecx,
> > > > wi-
> > > > >cpuid.reg);
> > > > break;
> > > > - default:
> > > > - r = 0;
> > > > + case MSR_FEATURE_WORD:
> > > > + r = kvm_arch_get_supported_msr_feature(kvm_state,
> > > > + wi->msr.index);
> > >
> > > If you move this patch before patch 1/3, this hunk could be part
> > > of patch 1/3.
> > >
> >
> > I'm afraid that if I moved this hunk, because of the dependency, I
> > would have to move the definition of
> > kvm_arch_get_supported_msr_feature() to patch 1/3, then in turn, it
> > used kvm_feature_msrs, I've to put its definition and
> > initialization
> > function kvm_get_supported_feature_msrs() to patch 1/3 as well.
> > Then
> > actually, this makes patch 1/3 and 2/3 merged into 1. Would you
> > like me
> > to do so?
>
> I don't get it. Why would you need to move the definition of
> kvm_arch_get_supported_cpuid() to patch 1/3, if we change the
> patch order and apply this patch before patch 1/3?
>
OK, so you mean simply switch the 1/3 and 2/3 order, not move some
hunks of 2/3 into 1/3. Am I right?