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

[Sean Christopherson]

On Tue, Feb 21, 2023, Yu Zhang wrote:
> Thank you so much, Sean, for such a detailed guidance!
> 
> Some questions below:
> 
> On Fri, Feb 17, 2023 at 02:54:49PM -0800, Sean Christopherson wrote:
> > Add a KVM x86 doc to the subsystem/maintainer handbook section to explain
> > how KVM x86 (currently) operates as a sub-subsystem, and to soapbox on
> > the rules and expectations for contributing to KVM x86.
> 
> It's a fantastic doc! Also, many good requirements can be common in KVM, not
> just KVM x86(e.g. the comment, changelog format, the testing requirement
> etc.). Could we be greedier to ask our KVM maintainers for a generic handbook
> of KVM, and maybe different sections for specific arches, which describe their
> specific requirements(the base trees and branches, the maintaining processes
> etc.)? :)

At some point, yes, but my strong preference is to document the x86 side of things
and then work from there.  For KVM x86, I can mostly just say "these are the rules".
Same goes for the other KVM arch maintainers (for their areas).

Incorporating all of KVM would require a much more collaborative effort, which isn't
a bad thing, but it will take more time and effort.  And IMO, KVM x86 needs this
typ eof documentation a lot more than the other KVM architectures, i.e. pushing out
KVM x86 documentation in order to go for more comprehensive documentation is not a
good tradeoff.

> > +Trees
> > +-----
> > +KVM x86 is currently in a transition period from being part of the main KVM
> > +tree, to being "just another KVM arch".  As such, KVM x86 is split across the
> > +main KVM tree, ``git.kernel.org/pub/scm/virt/kvm/kvm.git``, and a KVM x86
> > +specific tree, ``github.com/kvm-x86/linux.git``.
> 
> Does other arch also have a specific tree?

Yes.

> If a patch series touches multiple archs(though the chance could be very
> low), I guess that patch set should still be based on the main KVM tree? The
> master branch or the next branch?

Hmm, good question.  Using kvm-86/next is likely the best answer in most cases.
kvm/master is usually a bad choice because it won't have _any_ changes for the next
release, i.e. using it as a base is more likely to yield conflicts.  Similarly,
kvm/queue and kvm/next are unlikely to have more relevant changes than kvm-x86/next.

If there are non-trivial conflicts with multiple architectures then coordination
between maintainers will be required no matter what base is used.  And I would
expect people sending those types of series to have enough experience to be able
to make a judgment call and/or engage with maintainers to figure out the best solution.

I'll rework the "Base Tree/Branch" to explicitly state that any series that primarily
targets x86 should be based on kvm-x86/next, but with a "use common sense" qualifier.

> > +Co-Posting Tests
> > +~~~~~~~~~~~~~~~~
> > +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.
> > +
> > +KVM-unit-tests should *always* be posted separately.  Tools, e.g. b4 am, don't
> > +know that KVM-unit-tests is a separate repository and get confused when patches
> > +in a series apply on different trees.  To tie KVM-unit-tests patches back to
> > +KVM patches, first post the KVM changes and then provide a lore Link: to the
> > +KVM patch/series in the KVM-unit-tests patch(es).
> 
> I wonder, for KVM bugzilla to report a bug, or for our QAs to perform regular
> tests using KVM selftests/KVM-unit-tests, which tree/branch is more reasonable
> to be based on?
> 
> E.g., I saw some bugzilla issues earlier, reporting failures of some unit tests,
> did some investigation, yet to find those failures were just because the corresponding
> KVM patches had not been merged yet. 
> 
> Maybe we also should take care of the timings of the merging of KVM patches and
> the test patches?

I really don't want to hold up KVM-unit-test patches waiting for KVM fixes to be
merged.  KUT is already woefully under-maintained, artificially holding up patches
will only make things worse.  And simply waiting for patches to land in KVM doesn't
necessarily solve things either, e.g. if the fixes land in kvm/master mid-cycle
then running against kvm/next will continue to fail.  Waiting also doesn't help
people running KUT against older kernels, e.g. for qualifying stable kernels.

I completely understand the pain, but unfortunately no one has come up with an
elegant, low-maintenance solution (this problem has been discussed multiple times
in the past).

> Two examples(I'm sure there're more :)): 
> 1> https://bugzilla.kernel.org/show_bug.cgi?id=216812
> 2> https://bugzilla.kernel.org/show_bug.cgi?id=216725
> 
> 
> B.R.
> Yu
>