kvm パッチのレビューチェックリスト
パッチは Documentation/process/coding-style.rst と Documentation/process/submitting-patches.rst に従わなければならない。
パッチは kvm.git の master または next ブランチに対して作るべきである。
パッチが新しいユーザ空間 API を導入または変更する場合: - その API は Documentation/virt/kvm/api.rst に文書化しなければならない - その API は KVM_CHECK_EXTENSION で見つけられなければならない
新しい状態には、保存／復元への対応を含めなければならない。
新しい機能はデフォルトで無効にしなければならない（ユーザ空間が明示的に 要求するべきである）。性能改善は、デフォルトで有効にでき、また有効に するべきである。
新しい CPU 機能は、KVM_GET_SUPPORTED_CPUID2、あるいは x86 以外の アーキテクチャにおける同等の仕組みを通して公開するべきである
その機能はテスト可能であるべきである（後述）。
変更は、可能な限りベンダー中立であるべきである。共通コードへの変更は、 ベンダー固有のコードへの変更を重複させるよりよい。
同様に、アーキテクチャ依存のコードより、アーキテクチャ非依存のコードへの 変更を優先する。
ユーザ／カーネルインターフェースとゲスト／ホストインターフェースは、 64 ビットクリーンでなければならない（すべての変数とサイズが 64 ビットで 自然に整列し、具体的な型だけを使う。ulong ではなく u64）。
ゲストから見える新しい機能は、ハードウェアマニュアルに文書化されているか、 ドキュメントを伴っていなければならない。
KVM コードのテスト
KVM に貢献するすべての機能は、多くの場合バグ修正も含めて、何らかのテストや、 オープンソースのゲストと VMM での有効化を伴うべきである。KVM を対象とする テストスイートには次のものがある:
- Selftests
低レベルのテストで、カーネル API を細かくテストできる。API の失敗シナリオ、 特定のゲスト命令の後に API を呼び出す場合、1 つのテスト内で
KVM_CREATE_VMを複数回呼び出す場合のテストを含む。カーネルツリーのtools/testing/selftests/kvmに含まれている。kvm-unit-testsゲストの視点で CPU とエミュレートされたデバイスの機能をテストする、小さな ゲストの集まり。QEMU や
kvmtool上で動き、一般に KVM 固有ではない。 QEMU が対応する任意のアクセラレータや、ベアメタルでも動かせるため、 ハイパーバイザやプロセッサファミリをまたいで動作を比較できる。- Functional test suites
QEMU の
tests/functionalスイートや avocado-vt など、さまざまな機能テストの組が存在する。これらは通常、完全な オペレーティングシステムを仮想マシンで動かす。
最適なテスト方法は、機能の複雑さと動作内容によって変わる。以下に例と指針を 示す:
- New instructions (no new registers or APIs)
対応する CPU 機能があれば、QEMU で使えるようにするべきである。命令が KVM でのエミュレーション対応やその他のコードを必要とするなら、
kvm-unit-testsや selftests にテストを追加する価値がある。命令が、 すでに selftests のカバレッジが十分な API に関係するなら、後者のほうが よい選択になりうる。- New hardware features (new registers, no new APIs)
これらは
kvm-unit-testsでテストするべきである。これは多かれ少なかれ、 QEMU やkvmtoolで対応することを意味する。場合によっては、前の例と 同様に selftests を代わりに使える。ゲスト状態の保存／復元のコーナーケースを テストするために使うこともできる。- Bug fixes and performance improvements
これらは通常、新しい API を導入しないが、自分の貢献を検証するベンチマークや テストは共有する価値がある。できれば回帰テストの形がよい。テストと ベンチマークは、変更の内容に応じて
kvm-unit-testsか selftests の どちらかに含められる。selftests は Linux のツリーに直接含まれるため、 回帰テストに特に役立つ。- Large scale internal changes
単一の方針を示すのは難しいが、変更したコードが
kvm-unit-testsか selftests のどちらかでテストされているようにするべきである。影響を受ける コードがどのゲストでも実行される場合は、機能テストで十分なこともある。 カバーレターでテストの手順を説明する。既存のテストスイートの不足を 見つける助けになるためである。- New APIs
自分のユースケースを示すことが重要である。その機能がベアメタルですでに 使われていると説明するだけでもよいし、ユーザ空間での概念実証の実装でもよい。 後者はオープンソースである必要はないが、テストしやすいため当然ながら オープンソースのほうがよい。selftests では API のコーナーケースをテストする べきであり、その機能を使うオープンソースの VMM がなければ、ホストとゲストの 基本的な動作もテストするべきである。
- Bigger features, usually spanning host and guest
これらは Linux ゲストで対応するべきである。例外は限定的で、Windows ゲストで テストできる Hyper-V の機能が該当する。その機能が、QEMU や crosvm の 少なくとも一方など、オープンソースのホスト VMM とゲストファームウェアで 使えることが強く望ましい。selftests では少なくとも API のエラーケースを テストするべきである。ゲストの動作は、selftests か
kvm-unit-testsの どちらかでテストできる（これは準仮想化機能と Windows 専用機能で特に重要）。 十分な selftests のカバレッジは、オープンソースの VMM での実装の代わりにも なりうるが、一般に勧められない。
selftests と kvm-unit-tests でのテストについて以上の提案に従うと、
メンテナがあなたのコードをレビューして受け入れやすくなる。実際のところ、
変更をアップストリームに貢献する前から、KVM 向けの開発がしやすくなる。
もちろん、KVM のメンテナはより多くのテストを要求する権利を留保する。ただし、 要求をその都度免除することもある。