| Avi Kivity | cf3e3d3 | 2010-06-24 14:10:09 +0300 | [diff] [blame] | 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. |