On Tue, Feb 21, 2023 at 04:25:42PM -0800, Sean Christopherson wrote: > 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. Sure. No reason to push out this doc. > > > > +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. Thanks. Let's try. > > 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). Got it. The pain is still tolerable. B.R. Yu
