《KVM虚拟化技术实战和原理解析》读书笔记之第九章参与KVM开源社区

第9章 参与KVM开源社区

开源社区介绍

查看Linux Kernel的维护者，就查看Kernel代码中“MAINTAINERS”文件。

QEMU项目的官方网站为：

qemu.org 和 qemu-project.org

在QEMU的1.3.0版本之前，KVM社区专门维护了一个qemu-kvm.git的代码仓库，那时KVM虚拟化的一小部分功能还没有融入QEMU社区最普通的qemu.git代码仓库，所以使用KVM时最好专门使用qemu-kvm而不是普通的QEMU. 不过，从2012年12月发布的QEMU 1.3.0版本开始，KVM相关的全部代码都已经合并到QEMU社区的qemu.git主干中，所以使用KVM时只需普通的QEMU即可，而不需要专门定制的qemu-kvm. 从qemu-kvm.git仓库（http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git）可以看到，qemu-kvm就没有单独的版本发布了。

QEMU社区的代码仓库在 http://git.qemu.org/ ，其中qemu.git就是QEMU upstream的主干代码树。

使用git工具，通过2个URL(git://git.qemu.org/qemu.git 和 http://git.qemu.org/git/qemu.git)中的任意一个下载QEMU的最新源代码。

QEMU/KVM社区的开发方式是：与KVM相关的新功能代码或者bug fix代码需要发到KVM邮件组，经审核后，加入qemu-kvm.git代码仓库的uq/master分支中，再定期推送到qemu.git主干代码仓库。

代码结构简介

KVM 代码

KVM开发者的代码一般先进入KVM社区的kvm.git代码仓库，再由KVM维护者定期地将代码提供给Linux内核维护者（Linus Torvalds），由其添加到Linux内核代码仓库中。

可以查看以下2个网页来了解最新的KVM开发和Linux内核代码仓库的状态：

- https://git.kernel.org/cgit/virt/kvm/kvm.git

- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git

KVM 内核部分的代码主要分3个部分：

- KVM框架的核心代码

- 与硬件架构相关的代码

- KVM相关的头文件

KVM框架的核心代码

位于 virt/kvm/ 目录

kvm_main.c是KVM代码的核心文件，其中的kvm_init()函数是与硬件架构无关的KVM初始化入口

与硬件架构相关的代码

不同的处理器架构有对应的KVM代码，位于 arch/$ARCH/kvm/ 目录中。KVM目前支持的架构包括：x86、ARM、PowerPC、S390、IA64、MIPS等。

KVM相关的头文件

头文件位于 arch/$ARCH/include/asm/ 目录中

另外，在Linux内核代码仓库中还有一些关于KVM的文档，位于 Documentation/virtual/kvm/* 和 Documentation//kvm.txt

QEMU 代码

QEMU 1.3.0 已经将qemu-kvm中的代码全部合并到纯QEMU中，此后使用KVM只需普通QEMU即可，不需要专门为KVM来改动qemu-kvm.

普通的QEMU代码仓库如下：

http://git.qemu.org/?p=qemu.git;a=summary

QEMU通过ioctl函数使用/dev/kvm 设备来调用KVM内核模块提供的API，从而与KVM内核模块进行交互。提供的API包括：KVM_CREATE_VM, KVM_CREATE_VCPU, KVM_RUN, KVM_GET_API_VERSION, KVM_CHECK_EXTENSION等。

QEMU中将这一系列ioctl函数调用分为了3个类别：kvm_ioctl(), kvm_vm_ioctl(), 和kvm_vcpu_ioctl(). 这3个函数都是在kvm-all.c文件中定义的，分别用于表示对KVM内核模块本身、对虚拟客户机和对客户机的vCPU进行交互。

QEMU配合KVM来启动一个客户机，首先打开/dev/kvm设备，通过名为 KVM_CREATE_VM的ioctl调用来创建一个虚机对象，然后通过KVM_CREATE_VCPU来为虚机创建vCPU对象，最后通过KVM_RUN让vCPU运行起来。

KVM单元测试基本原理：

将编译好的轻量级测试内核镜像（*.flat文件）作为支持多重启动的QEMU客户机内核镜像来启动，测试使用一个通过客户机BIOS来调用的基础结构，该基础结构将会主要初始化客户机系统（包括CPU），然后切换到长模式(x86_64CPU架构的一种运行模式)并调用各个具体测试用例的主函数来执行测试，在测试结束后QEMU进程自动退出。

向开源社区贡献代码

KVM开发者邮件列表是：kvm@vger.kernel.org

KVM内核部分以及QEMU中与KVM相关部分的讨论都会在这里讨论。

订阅方法：向majordomo@vger.kernel.org发送一封以”subscribe kvm”为正文的邮件。

QEMU开发者邮件列表是：qemu-devel@nongnu.org

QEMU普通用户讨论的邮件列表是：qemu-discuss@nongnu.org

KVM的IRC频道：在irc.freenode.net服务器上的#kvm频道

QEMU的IRC频道：在irc.oftc.net服务器上的#qemu频道

Linux代码风格：内核代码仓库的 Documentation/CodeStyle 文件中有说明

在目前的KVM社区中，生成的KVM内核部分的patch，要基于kvm.git代码仓库的next分支来进行开发的；

而QEMU部分的patch，是要基于qemu-kvm.git代码仓库的 uq/master 分支来开发的。

diffstat这个工具可以生成patch引起的变化的统计信息，包括：修改的文件位置、被改动的文件个数、增加或删除的行数。

在往邮件列表发送patch时，最好能够将diffstat工具统计的信息附加在patch之前。

使用git生成patch：

先git commit，再git format-patch -N

git format-patch -N 命令表示计算最新N次提交信息而得到的patch.

git format-patch origin 命令表示生成所有的本地提交所对应的patch文件。

Linux内核和QEMU都分别提供了检查patch的脚本，位置分别是：

内核：scripts/checkpatch.pl

QEMU：scripts/checkpatch.pl

如果是使用 git format-patch 命令来生成的patch，可以在生成patch的时候就添加 -s 或 –signoff 参数，以便在生成patch文件时就添加 “Signed-off-by:” 信息行。

提交patch

KVM和QEMU的patch提交，都是通过发送到邮件列表来实现的。

一般收件人或抄送人中还包含该项目或子模块的维护者。可以根据源代码中的 MAINTAINERS 文件来查看维护者信息以及他们负责的模块。另外，Linux内核和QEMU的代码仓库中都提供了一个根据patch查看维护者的脚本，其位置是：scripts/get_maintainer.pl

如果实现某个功能的patch的代码量较大，尽量将其拆成多个相对独立的小patch. 比如，拆分成m个patch，当发送第n个的时候，一般邮件的主题标注为”[PATCH n/m]”表示当前patch在这一系列patch中的位置。一般还会发一个[PATCH 0/m]作为第一个patch，这个数字编号为0的patch通常用于书写本系列patch的概括信息。

根据社区意见修改patch后，需加上当前patch的版本号，比如”[PATCH v6 05/12]”.

RFC(Request For Comments) patch邮件，多用于提交一个不太成熟的patch，请大家对该patch提出改进意见。

可以使用git-email安装包中的git send-email 命令行工具来发送patch.

提交KVM相关的bug

KVM的bug管理系统：

https://bugzilla.kernel.org

QEMU的bug管理系统：

https://bugs.launchpad.net/qemu

可以使用 git bisect 命令来通过二分法查找引入bug的代码修改。

git bisect 的原理：

先告诉Git一个有bug的版本和一个正常的版本，然后Git会自动切换当前代码库到二者中间的一个版本，接着经过测试来表明当前版本是正常的还是有bug的，Git根据该信息再次切换到一个中间版本，如此循环，直至Git发现两个相邻的版本，一个是good，一个是bad，进而再比较它们的代码差异就可以了。

名词解释：

upstream：一些开源项目中最主干且一直向前发展的代码树。upstream中包含了最新的代码，一些新增的功能特性和修复的bug一般都会先进入到upstream中，然后才会到某一个具体的发行版本中。Linux upstream就是指最新的Linux内核代码树，而一些Linux发行版的内核则是基于upstream的某一个版本再加上一些patch来制作的。