Lines Matching +full:re +full:- +full:routed
1 .. SPDX-License-Identifier: GPL-2.0
7 --------
17 -----
21 -----
25 specific tree, ``github.com/kvm-x86/linux.git``.
28 main KVM tree, while all development for the next cycle is routed through the
29 KVM x86 tree. In the unlikely event that a fix for the current cycle is routed
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.
54 Changes that target the next release are routed through the KVM x86 tree. Pull
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
262 Note, KVM selftests and KVM-unit-tests do have known failures. If you suspect
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 ---------------