Documentation/virt/kvm/review-checklist.rst

Source file repositories/reference/linux-study-clean/Documentation/virt/kvm/review-checklist.rst

File Facts

System
Linux kernel
Corpus path
Documentation/virt/kvm/review-checklist.rst
Extension
.rst
Size
5746 bytes
Lines
123
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

================================
Review checklist for kvm patches
================================

1.  The patch must follow Documentation/process/coding-style.rst and
    Documentation/process/submitting-patches.rst.

2.  Patches should be against kvm.git master or next branches.

3.  If the patch introduces or modifies a new userspace API:
    - the API must be documented in Documentation/virt/kvm/api.rst
    - the API must be discoverable using KVM_CHECK_EXTENSION

4.  New state must include support for save/restore.

5.  New features must default to off (userspace should explicitly request them).
    Performance improvements can and should default to on.

6.  New cpu features should be exposed via KVM_GET_SUPPORTED_CPUID2,
    or its equivalent for non-x86 architectures

7.  The feature should be testable (see below).

8.  Changes should be vendor neutral when possible.  Changes to common code
    are better than duplicating changes to vendor code.

9.  Similarly, prefer changes to arch independent code than to arch dependent
    code.

10. User/kernel interfaces and guest/host interfaces must be 64-bit clean
    (all variables and sizes naturally aligned on 64-bit; use specific types
    only - u64 rather than ulong).

11. New guest visible features must either be documented in a hardware manual
    or be accompanied by documentation.

Testing of KVM code
-------------------

All features contributed to KVM, and in many cases bugfixes too, should be
accompanied by some kind of tests and/or enablement in open source guests
and VMMs.  KVM is covered by multiple test suites:

*Selftests*
  These are low level tests that allow granular testing of kernel APIs.
  This includes API failure scenarios, invoking APIs after specific
  guest instructions, and testing multiple calls to ``KVM_CREATE_VM``
  within a single test.  They are included in the kernel tree at
  ``tools/testing/selftests/kvm``.

``kvm-unit-tests``
  A collection of small guests that test CPU and emulated device features
  from a guest's perspective.  They run under QEMU or ``kvmtool``, and
  are generally not KVM-specific: they can be run with any accelerator
  that QEMU support or even on bare metal, making it possible to compare
  behavior across hypervisors and processor families.

Functional test suites
  Various sets of functional tests exist, such as QEMU's ``tests/functional``
  suite and `avocado-vt <https://avocado-vt.readthedocs.io/en/latest/>`__.
  These typically involve running a full operating system in a virtual
  machine.

The best testing approach depends on the feature's complexity and
operation. Here are some examples and guidelines:

New instructions (no new registers or APIs)
  The corresponding CPU features (if applicable) should be made available

Annotation

Implementation Notes