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>
Subject: Re: [PATCH REBASED] KVM: x86: SVM: Fix one redefine issue about VMCB_AVIC_APIC_BAR_MASK
Date: Wed, 5 Apr 2023 19:31:55 -0700 [thread overview]
Message-ID: <ZC4vG09or7AfUA7L@google.com> (raw)
In-Reply-To: <CAEm4hYV-M1sbboOon_O=eRsk6LEgwog+oUKBpdnAkchs=KMWEw@mail.gmail.com>
On Thu, Apr 06, 2023, Xinghui Li wrote:
> On Wed, Apr 5, 2023 at 7:44 AM 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 new
> > 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 isn'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 between
> > versions should be captured.
> >
> > And in this case, there really was no need to send a new version, the original
> > patch still applies cleanly. I suspect that the REBASED version was sent 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 sending new
> > versions means more patches to sort through, i.e. makes maintainers lives 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 for 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 avoid
similar mistakes in the future.
Thanks!
prev parent reply other threads:[~2023-04-06 2:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-03 9:52 [PATCH REBASED] KVM: x86: SVM: Fix one redefine issue about VMCB_AVIC_APIC_BAR_MASK korantwork
2023-04-04 8:40 ` Like Xu
2023-04-04 10:38 ` Xinghui Li
2023-04-04 23:43 ` Sean Christopherson
2023-04-06 2:21 ` Xinghui Li
2023-04-06 2:31 ` Sean Christopherson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZC4vG09or7AfUA7L@google.com \
--to=seanjc@google.com \
--cc=korantli@tencent.com \
--cc=korantwork@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox