Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 5 Apr 2023 19:31:55 -0700
In-Reply-To: <CAEm4hYV-M1sbboOon_O=eRsk6LEgwog+oUKBpdnAkchs=KMWEw@mail.gmail.com>
Mime-Version: 1.0
References: <20230403095200.1391782-1-korantwork@gmail.com>
 <168063175075.174995.217166777153935864.b4-ty@google.com> <CAEm4hYV-M1sbboOon_O=eRsk6LEgwog+oUKBpdnAkchs=KMWEw@mail.gmail.com>
Message-ID: <ZC4vG09or7AfUA7L@google.com>
Subject: Re: [PATCH REBASED] KVM: x86: SVM: Fix one redefine issue about VMCB_AVIC_APIC_BAR_MASK
From:   Sean Christopherson <seanjc@google.com>
To:     Xinghui Li <korantwork@gmail.com>
Cc:     pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com,
        mlevitsk@redhat.com, linux-kernel@vger.kernel.org, x86@kernel.org,
        kvm@vger.kernel.org, Xinghui Li <korantli@tencent.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Apr 06, 2023, Xinghui Li wrote:
> On Wed, Apr 5, 2023 at 7:44=E2=80=AFAM Sean Christopherson <seanjc@google=
.com> wrote:
> >
> > On Mon, 03 Apr 2023 17:52:00 +0800, korantwork@gmail.com wrote:
> > > VMCB_AVIC_APIC_BAR_MASK is defined twice with the same value in svm.h=
,
> > > which is meaningless. Delete the duplicate one.
> >
> > Applied to kvm-x86 svm, thanks!
> >
> > In the future, please don't use "PATCH REBASED".  If you're sending a n=
ew
> > version of a patch that's been rebased, then the revision number needs =
to be
> > bumped.  The fact that the only change is that the patch was rebased is=
n't
> > relevant as far as versioning is concerned, it's still a new version.  =
The
> > cover letter and/or ignored part of the patch is where the delta betwee=
n
> > versions should be captured.
> >
> > And in this case, there really was no need to send a new version, the o=
riginal
> > patch still applies cleanly.  I suspect that the REBASED version was se=
nt as a
> > form of a ping, which again is not the right way to ping a patch/series=
.  If you
> > want to ping, please reply to the original patch.  Unnecessarily sendin=
g new
> > versions means more patches to sort through, i.e. makes maintainers liv=
es harder,
> > not easier.
> >
> Firstly, I'm so so SORRY to burden you in this way.
> I found the last patch can't be am directly, so I send a new patch
> with the last rebased code.

Ah, try `git am -3`, i.e. tell git to try a 3-way merge between the patch, =
its
base, and what you're applying on.  I'm sure there are situations where a 3=
-way
merge is unwanted, e.g. maybe if someone needs to be super paranoid?  But f=
or me
personally at least, I pretty much always run am with -3.

> I used to believe that this would alleviate your burden, but
> unfortunately, it had the opposite effect.
> Again, sorry for my wrong operation.

No worries, it's not a big deal.  My lengthy response was purely to help av=
oid
similar mistakes in the future.

Thanks!