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 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.