public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Vipin Sharma <vipinsh@google.com>
Cc: pbonzini@redhat.com, vkuznets@redhat.com, dmatlack@google.com,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
	m Suzuki K Poulose <suzuki.poulose@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Anup Patel <anup@brainfault.org>,
	Atish Patra <atishp@atishpatra.org>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>,
	David Hildenbrand <david@redhat.com>
Subject: Re: [Patch v4 12/13] KVM: selftests: Make vCPU exit reason test assertion common.
Date: Thu, 2 Feb 2023 18:51:47 +0000	[thread overview]
Message-ID: <Y9wGQx89zI3TMU1Y@google.com> (raw)
In-Reply-To: <CAHVum0fEmEAQSxozb1BTTy-d3UGrsvhjt8V5FXQPrX5wOYqpPQ@mail.gmail.com>

On Thu, Feb 02, 2023, Vipin Sharma wrote:
> On Wed, Feb 1, 2023 at 3:24 PM Sean Christopherson <seanjc@google.com> wrote:
> > I love the cleanup, but in the future, please don't squeeze KVM-wide changes in
> > the middle of an otherwise arch-specific series unless it's absolutely necessary.
> > I get why you added the macro before copy-pasting more code into a new test, but
> > the unfortunate side effect is that complicates grabbing the entire series.
> >
> 
> Make sense. So what is preferable:
> 1. Make the big cleanup identified during a series as the last patches
> in that series?
> 2. Have two series and big cleanups rebased on top of the initial series?
> 
> Or, both 1 & 2 are acceptable depending on the cleanup?

  3. Post the cleanup independently, but make a note so that maintainers know
     that there may be conflicts and/or missed cleanup opportunities.

#1 is rarely going to be the best option.  The big cleanup is going to necessitate
Cc'ing a lot of people that don't care about the base arch-specific changes, so
unless the base changes are one or two trivial patches, a lot of people end up
having to wade through a lot of noise.  And aside from annoying people, that also
makes it more likely that someone will overlook the cleanup.

As for #2 vs. #3, #3 is probably a better option in most cases.  For broad cleanups,
odds are very good that there will be other conflicts beyond just the changes _you_
have in-flight.  E.g. in this case, any new tests and/or asserts that are in-flight,
sitting in other trees, etc., will suffer the same fate.  I.e. whoever applies the
cleanup is going to need to resolve conflicts and/or look for other cleanup
opportunities anyways.  For a scenario like this, a way to make life easy for the
maintainer applying the cleanup would be to provide a script, e.g. single grep
command, to look for potential cleanup spots.  That communicates to the maintainer
that there may be silent "conflicts" and makes it easier for them to resolve such
conflicts.

Posting the cleanup separately means the two series/patches can proceed
independently, e.g. respinning one doesn't screw up the other, maintainers can
take the patches in whatever order they prefer, etc.

There are undoubtedly exceptions, e.g. if the resulting conflicts are really nasty,
but those should be few and far between.

  reply	other threads:[~2023-02-02 18:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-12 18:37 [Patch v4 00/13] Add Hyper-v extended hypercall support in KVM Vipin Sharma
2022-12-12 18:37 ` [Patch v4 01/13] x86/hyperv: Add HV_EXPOSE_INVARIANT_TSC define Vipin Sharma
2022-12-12 18:37 ` [Patch v4 02/13] KVM: x86: Add a KVM-only leaf for CPUID_8000_0007_EDX Vipin Sharma
2022-12-27 20:20   ` Aaron Lewis
2022-12-12 18:37 ` [Patch v4 03/13] KVM: x86: Hyper-V invariant TSC control Vipin Sharma
2022-12-12 18:37 ` [Patch v4 04/13] KVM: selftests: Rename 'msr->available' to 'msr->fault_exepected' in hyperv_features test Vipin Sharma
2022-12-12 18:37 ` [Patch v4 05/13] KVM: selftests: Convert hyperv_features test to using KVM_X86_CPU_FEATURE() Vipin Sharma
2022-12-12 18:37 ` [Patch v4 06/13] KVM: selftests: Test that values written to Hyper-V MSRs are preserved Vipin Sharma
2022-12-12 18:37 ` [Patch v4 07/13] KVM: selftests: Test Hyper-V invariant TSC control Vipin Sharma
2022-12-12 18:37 ` [Patch v4 08/13] KVM: x86: hyper-v: Use common code for hypercall userspace exit Vipin Sharma
2022-12-12 18:37 ` [Patch v4 09/13] KVM: x86: hyper-v: Add extended hypercall support in Hyper-v Vipin Sharma
2022-12-12 18:37 ` [Patch v4 10/13] KVM: selftests: Test Hyper-V extended hypercall enablement Vipin Sharma
2022-12-12 18:37 ` [Patch v4 11/13] KVM: selftests: Replace hardcoded Linux OS id with HYPERV_LINUX_OS_ID Vipin Sharma
2022-12-12 18:37 ` [Patch v4 12/13] KVM: selftests: Make vCPU exit reason test assertion common Vipin Sharma
2023-02-01 23:24   ` Sean Christopherson
2023-02-02 18:31     ` Vipin Sharma
2023-02-02 18:51       ` Sean Christopherson [this message]
2023-02-02 18:59         ` Vipin Sharma
2023-02-03 22:08           ` Vipin Sharma
2023-02-03 22:57             ` Sean Christopherson
2022-12-12 18:37 ` [Patch v4 13/13] KVM: selftests: Test Hyper-V extended hypercall exit to userspace Vipin Sharma
2023-01-04  0:33 ` [Patch v4 00/13] Add Hyper-v extended hypercall support in KVM Vipin Sharma
2023-02-01 22:39 ` (subset) " Sean Christopherson

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=Y9wGQx89zI3TMU1Y@google.com \
    --to=seanjc@google.com \
    --cc=anup@brainfault.org \
    --cc=atishp@atishpatra.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=david@redhat.com \
    --cc=dmatlack@google.com \
    --cc=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=james.morse@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=pbonzini@redhat.com \
    --cc=suzuki.poulose@arm.com \
    --cc=vipinsh@google.com \
    --cc=vkuznets@redhat.com \
    --cc=yuzenghui@huawei.com \
    /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