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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.