Re: [PATCH v2 2/2] Documentation/process: Add a maintainer handbook for KVM x86

[Sean Christopherson]

On Thu, Mar 09, 2023, Bagas Sanjaya wrote:
> On Wed, Mar 08, 2023 at 05:03:36PM -0800, Sean Christopherson wrote:
> > +If a patch touches multiple topics, traverse up the conceptual tree to find the
> > +first common parent (which is often simply ``x86``).  When in doubt,
> > +``git log path/to/file`` should provide a reasonable hint.
> 
> What do you mean by conceptual tree?  Is it Patch subject prefix?

Not really?  I'm struggling to describe it in words.  What I mean is something
like this

                 x86
               /  |  \
             VMX pmu  SVM
            /            \
          nVMX          nSVM

e.g. if a patch touches VMX and SVM, use "x86".  But it's a bit more complex than
that, e.g. a VMX-focused patch that just happens to touch Intel-specific PMU
code should probably be tagged "VMX", not "x86" or "pmu".

Massaging subjects when applying is easy enough, and there will always be some
amount of subjectivity, so unless this is outright confusing (or someone has a
better, succinct, and easy-to-understand description), I'll probably just leave
this section as-is.

> > +KVM selftests that are associated with KVM changes, e.g. regression tests for
> > +bug fixes, should be posted along with the KVM changes as a single series.  The
> > +standard kernel rules for bisection apply, i.e. KVM changes that result in test
> > +failures should be ordered after the selftests updates, and vice versa, new
> > +tests that fail due to KVM bugs should be ordered after the KVM fixes.
> 
> Did you mean that in a patch series, selftest patches are placed after
> their corresponding KVM changes?

No, I meant what I wrote.  If a KVM change will break a test (uncommon, but it
does happen), then the selftest should be patched first so that there are no
unnecessary test failures in the git history.  But when adding a regression test,
the KVM bug fix should come first so that again, there are no unnecessary failures
if someone tests an arbitrary commit, e.g. during bisection.