Documentation/process/maintainer-kvm-x86.rst

Source file repositories/reference/linux-study-clean/Documentation/process/maintainer-kvm-x86.rst

File Facts

System
Linux kernel
Corpus path
Documentation/process/maintainer-kvm-x86.rst
Extension
.rst
Size
18961 bytes
Lines
391
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

KVM x86
=======

Foreword
--------
KVM strives to be a welcoming community; contributions from newcomers are
valued and encouraged.  Please do not be discouraged or intimidated by the
length of this document and the many rules/guidelines it contains.  Everyone
makes mistakes, and everyone was a newbie at some point.  So long as you make
an honest effort to follow KVM x86's guidelines, are receptive to feedback,
and learn from any mistakes you make, you will be welcomed with open arms, not
torches and pitchforks.

TL;DR
-----
Testing is mandatory.  Be consistent with established styles and patterns.

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``.

Generally speaking, fixes for the current cycle are applied directly to the
main KVM tree, while all development for the next cycle is routed through the
KVM x86 tree.  In the unlikely event that a fix for the current cycle is routed
through the KVM x86 tree, it will be applied to the ``fixes`` branch before
making its way to the main KVM tree.

Note, this transition period is expected to last quite some time, i.e. will be
the status quo for the foreseeable future.

Branches
~~~~~~~~
The KVM x86 tree is organized into multiple topic branches.  The purpose of
using finer-grained topic branches is to make it easier to keep tabs on an area
of development, and to limit the collateral damage of human errors and/or buggy
commits, e.g. dropping the HEAD commit of a topic branch has no impact on other
in-flight commits' SHA1 hashes, and having to reject a pull request due to bugs
delays only that topic branch.

All topic branches, except for ``next`` and ``fixes``, are rolled into ``next``
via a Cthulhu merge on an as-needed basis, i.e. when a topic branch is updated.
As a result, force pushes to ``next`` are common.

Lifecycle
~~~~~~~~~
Fixes that target the current release, a.k.a. mainline, are typically applied
directly to the main KVM tree, i.e. do not route through the KVM x86 tree.

Changes that target the next release are routed through the KVM x86 tree.  Pull
requests (from KVM x86 to main KVM) are sent for each KVM x86 topic branch,
typically the week before Linus' opening of the merge window, e.g. the week
following rc7 for "normal" releases.  If all goes well, the topic branches are
rolled into the main KVM pull request sent during Linus' merge window.

The KVM x86 tree doesn't have its own official merge window, but there's a soft
close around rc5 for new features, and a soft close around rc6 for fixes (for
the next release; see above for fixes that target the current release).

Timeline
~~~~~~~~
Submissions are typically reviewed and applied in FIFO order, with some wiggle
room for the size of a series, patches that are "cache hot", etc.  Fixes,
especially for the current release and or stable trees, get to jump the queue.
Patches that will be taken through a non-KVM tree (most often through the tip
tree) and/or have other acks/reviews also jump the queue to some extent.

Annotation

Implementation Notes