[net-next-2.6.git] / Documentation / kvm / review-checklist.txt

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

1.  The patch must follow Documentation/CodingStyle and
    Documentation/SubmittingPatches.

2.  Patches should be against kvm.git master branch.

3.  If the patch introduces or modifies a new userspace API:
    - the API must be documented in Documentation/kvm/api.txt
    - 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

7.  Emulator changes should be accompanied by unit tests for qemu-kvm.git
    kvm/test directory.

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.

12. 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.
Commit	Line	Data
cf3e3d3e AK	1	Review checklist for kvm patches
	2	================================
	3
	4	1. The patch must follow Documentation/CodingStyle and
	5	Documentation/SubmittingPatches.
	6
	7	2. Patches should be against kvm.git master branch.
	8
	9	3. If the patch introduces or modifies a new userspace API:
	10	- the API must be documented in Documentation/kvm/api.txt
	11	- the API must be discoverable using KVM_CHECK_EXTENSION
	12
	13	4. New state must include support for save/restore.
	14
	15	5. New features must default to off (userspace should explicitly request them).
	16	Performance improvements can and should default to on.
	17
	18	6. New cpu features should be exposed via KVM_GET_SUPPORTED_CPUID2
	19
	20	7. Emulator changes should be accompanied by unit tests for qemu-kvm.git
	21	kvm/test directory.
	22
	23	8. Changes should be vendor neutral when possible. Changes to common code
	24	are better than duplicating changes to vendor code.
	25
	26	9. Similarly, prefer changes to arch independent code than to arch dependent
	27	code.
	28
	29	10. User/kernel interfaces and guest/host interfaces must be 64-bit clean
	30	(all variables and sizes naturally aligned on 64-bit; use specific types
	31	only - u64 rather than ulong).
	32
	33	11. New guest visible features must either be documented in a hardware manual
	34	or be accompanied by documentation.
	35
	36	12. Features must be robust against reset and kexec - for example, shared
	37	host/guest memory must be unshared to prevent the host from writing to
	38	guest memory that the guest has not reserved for this purpose.