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