Review checklist for kvm patches
- The patch must follow Linux kernel coding style and
Submitting patches: the essential guide to getting your code into the kernel.
- Patches should be against kvm.git master branch.
- If the patch introduces or modifies a new userspace API:
- the API must be documented in The Definitive KVM (Kernel-based Virtual Machine) API Documentation
- the API must be discoverable using KVM_CHECK_EXTENSION
- New state must include support for save/restore.
- New features must default to off (userspace should explicitly request them).
Performance improvements can and should default to on.
- New cpu features should be exposed via KVM_GET_SUPPORTED_CPUID2
- Emulator changes should be accompanied by unit tests for qemu-kvm.git
kvm/test directory.
- Changes should be vendor neutral when possible. Changes to common code
are better than duplicating changes to vendor code.
- Similarly, prefer changes to arch independent code than to arch dependent
code.
- 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).
- New guest visible features must either be documented in a hardware manual
or be accompanied by documentation.
- Features must be robust against reset and kexec - for example, shared
host/guest memory must be unshared to prevent the host from writing to
guest memory that the guest has not reserved for this purpose.