Documentation/process/maintainer-kvm-x86.rst

1 .. SPDX-License-Identifier: GPL-2.0
7 --------
17 -----
21 -----
25 specific tree, ``github.com/kvm-x86/linux.git``.
39 using finer-grained topic branches is to make it easier to keep tabs on an area
42 in-flight commits' SHA1 hashes, and having to reject a pull request due to bugs
46 via a Cthulhu merge on an as-needed basis, i.e. when a topic branch is updated.
69 Patches that will be taken through a non-KVM tree (most often through the tip
83 -----------
93 Everything else should be based on ``kvm-x86/next``, i.e. there is no need to
98 The only exception to using ``kvm-x86/next`` as the base is if a patch/series
99 is a multi-arch series, i.e. has non-trivial modifications to common KVM code
100 and/or has more than superficial changes to other architectures' code.  Multi-
102 history, e.g. the release candidate upon which ``kvm-x86 next`` is based.  If
103 you're unsure whether a patch/series is truly multi-arch, err on the side of
104 caution and treat it as multi-arch, i.e. use a common base.
112 :ref:`maintainer-tip-coding-style`, as patches/series often touch both KVM and
113 non-KVM x86 files, i.e. draw the attention of KVM *and* tip tree maintainers.
118 Except for a handful of special snowflakes, do not use kernel-doc comments for
120 they are intended only for KVM-internal consumption (there are plans to
135 "APM", without additional context is a-ok.
138 not in comments.  Instead, if necessary (see below), copy-paste the relevant
142 Generally speaking, do not explicitly reference or copy-paste from the SDM or
152   - x86
153   - x86/mmu
154   - x86/pmu
155   - x86/xen
156   - selftests
157   - SVM
158   - nSVM
159   - VMX
160   - nVMX
162 **DO NOT use x86/kvm!**  ``x86/kvm`` is used exclusively for Linux-as-a-KVM-guest
184 New topics do occasionally pop up, but please start an on-list discussion if
188 do not treat the 70-75 character limit as an absolute, hard limit.  Instead,
189 use 75 characters as a firm-but-not-hard limit, and use 80 characters as a hard
206 find. Changelogs that bury the "what's actually changing" in a one-liner after
234 KVM x86 opts out of backporting Fixes: by default.  Some auto-selected patches
244 -------
250 Running KVM selftests and KVM-unit-tests is also mandatory (and stating the
256 For changes that touch KVM's shadow paging code, running with TDP (EPT/NPT)
262 Note, KVM selftests and KVM-unit-tests do have known failures.  If you suspect
266 Changes that touch reStructured Text documentation, i.e. .rst files, must build
286 that can't be well validated using existing KVM selftests and/or KVM-unit-tests
292 the RFC process; RFCs will typically not receive in-depth review.
296 Except for "obvious" found-by-inspection bugs, fixes must be accompanied by a
300 bugs that are found via non-public workloads/tests, but providing regression
306 one-in-a-million type race condition.
308 Note, KVM bugs are rarely urgent *and* non-trivial to reproduce.  Ask yourself
313 -------
318 via ``In-Reply-To:`` headers.  Using ``In-Reply-To:`` becomes an unholy mess
319 for large series and/or when the version count gets high, and ``In-Reply-To:``
334 use ``git format-patch`` with the ``--base`` flag to automatically include the
337 Note, ``--base=auto`` works as expected if and only if a branch's upstream is
341 KVM x86 topic, and feed that into ``--base``.  E.g. ``x86/pmu/my_branch_name``,
343 to yield ``--base=x/pmu``, where ``x`` is whatever name your repository uses to
346 Co-Posting Tests
354 KVM-unit-tests should *always* be posted separately.  Tools, e.g. b4 am, don't
355 know that KVM-unit-tests is a separate repository and get confused when patches
356 in a series apply on different trees.  To tie KVM-unit-tests patches back to
358 KVM patch/series in the KVM-unit-tests patch(es).
361 -------------
363 in reply to the original posting (cover letter for multi-patch series).  The
385 ---------------