From: Sean Christopherson <seanjc@google.com>
To: paul@xen.org
Cc: David Woodhouse <dwmw2@infradead.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Paul Durrant <pdurrant@amazon.com>,
"H. Peter Anvin" <hpa@zytor.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
x86@kernel.org
Subject: Re: [PATCH v3 00/13] KVM: xen: update shared_info and vcpu_info handling
Date: Tue, 19 Sep 2023 08:37:27 -0700 [thread overview]
Message-ID: <ZQnAN9TC6b8mSJ/t@google.com> (raw)
In-Reply-To: <196a645c-f41d-8f35-d854-f30b66aff2a6@xen.org>
On Tue, Sep 19, 2023, Paul Durrant wrote:
> On 18/09/2023 18:12, Sean Christopherson wrote:
> [snip]
> >
> > Tag them RFC, explain your expectations, goals, and intent in the cover letter,
> > don't copy+paste cover letters verbatim between versions, and summarize the RFC(s)
> > when you get to a point where you're ready for others to jump in. The cover
> > letter is *identical* from v1=>v2=>v3, how is anyone supposed to understand what
> > on earth is going on unless they happened to be in the same room as ya'll on
> > Friday?
>
> The cover letter is indeed identical because the purpose of the series has
> not changed.
For anything out of the ordinary, e.g. posting v3 just a few hours after v2 is
definitely not normal, use the cover letter to call out why you're posting a
particular version of the series, not just the purpose of the series.
> > In other words, use tags and the cover letter to communicate, don't just view the
> > cover letter as a necessary evil to get people to care about your patches.
>
> That was not the intention at all; I put all the detailed explanation in the
> commit comments because I thought that would make review *easier*.
Per-patch comments *might* make individual patches easier to review, but (for me
at least) they are waaay less helpful for reviewing series as a whole, and all
but usless for initial triage. E.g. for a situation like this where a series
has reached v4 before I've so much as glanced at the patches, having the history
in the cover letter allows me to catch up and get a feel for how the series got
to v4 in ~20 seconds. With per-patch comments, I have to go find each comment
and then piece together the bigger picture.
Per-patch comments also don't work well if a version makes minor changes to a
large series (hunting through a 10+ patch series to figure out that only one patch
changed is not exactly efficient), if a patch is dropped, if there are changes to
the overall approach, etc.
prev parent reply other threads:[~2023-09-19 15:37 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-18 14:40 [PATCH v3 00/13] KVM: xen: update shared_info and vcpu_info handling Paul Durrant
2023-09-18 14:40 ` [PATCH v3 01/13] KVM: pfncache: add a map helper function Paul Durrant
2023-09-18 14:41 ` [PATCH v3 02/13] KVM: pfncache: add a mark-dirty helper Paul Durrant
2023-09-18 14:41 ` [PATCH v3 03/13] KVM: pfncache: add a helper to get the gpa Paul Durrant
2023-09-18 14:41 ` [PATCH v3 04/13] KVM: pfncache: base offset check on khva rather than gpa Paul Durrant
2023-09-18 14:41 ` [PATCH v3 05/13] KVM: pfncache: allow a cache to be activated with a fixed (userspace) HVA Paul Durrant
2023-09-18 14:41 ` [PATCH v3 06/13] KVM: xen: allow shared_info to be mapped by fixed HVA Paul Durrant
2023-09-18 14:41 ` [PATCH v3 07/13] KVM: xen: prepare for using 'default' vcpu_info Paul Durrant
2023-09-18 14:41 ` [PATCH v3 08/13] KVM: xen: prevent vcpu_id from changing whilst shared_info is valid Paul Durrant
2023-09-18 15:59 ` David Woodhouse
2023-09-18 14:41 ` [PATCH v3 09/13] KVM: xen: automatically use the vcpu_info embedded in shared_info Paul Durrant
2023-09-18 16:07 ` David Woodhouse
2023-09-18 16:15 ` Paul Durrant
2023-09-18 16:20 ` David Woodhouse
2023-09-18 14:41 ` [PATCH v3 10/13] KVM: selftests / xen: set KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID Paul Durrant
2023-09-18 14:41 ` [PATCH v3 11/13] KVM: selftests / xen: map shared_info using HVA rather than GFN Paul Durrant
2023-09-18 16:16 ` David Woodhouse
2023-09-18 14:41 ` [PATCH v3 12/13] KVM: selftests / xen: don't explicitly set the vcpu_info address Paul Durrant
2023-09-18 16:10 ` David Woodhouse
2023-09-18 14:41 ` [PATCH v3 13/13] KVM: xen: advertize the KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA capability Paul Durrant
2023-09-18 16:18 ` [PATCH v3 00/13] KVM: xen: update shared_info and vcpu_info handling Sean Christopherson
2023-09-18 16:34 ` David Woodhouse
2023-09-18 17:12 ` Sean Christopherson
2023-09-19 8:48 ` Paul Durrant
2023-09-19 15:37 ` 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=ZQnAN9TC6b8mSJ/t@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=pdurrant@amazon.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