Read the fucking source code!
--By 鲁迅A picture is worth a thousand words.
--By 高尔基说明:
https://www.cnblogs.com/LoyenWang/
source code
的系列分析了;KVM
作为内核模块,可以认为是一个中间层,向上对接用户的控制,向下对接不同架构的硬件虚拟化支持;module_init(arm_init)
开始,代码路径:arch/arm64/kvm/arm.c
;老规矩,先来一张图(图片中涉及到的红色框函数,都是会展开描述的
):
kvm
的初始化,在kvm_init
中完成,既包含了体系结构相关的初始化设置,也包含了各类回调函数的设置,资源分配,以及设备注册等,只有当初始化完成后,才能响应各类请求,比如创建虚拟机等;
cpuhp_setup_state_nocall
与CPU的热插拔相关,register_reboot_notifer
与系统的重启相关,register_syscore_ops
与系统的休眠唤醒相关,而这几个模块的回调函数,最终都会去调用体系结构相关的函数去打开或关闭Hypervisor
;kmem_cache_create_usercopy
与kvm_async_pf_init
都是创建slab缓存
,用于内核对象的分配;kvm_vfio_ops_init
:VFIO
是一个可以安全将设备I/O
、中断、DMA导出到用户空间的框架,后续在将IO虚拟化时再深入分析;kvm_arch_init
与前文ARMv8
硬件虚拟化支持紧密相关,而misc_register
与上层操作紧密相关;kvm_arch_init
It‘s a big topic, I‘ll try to put it in a nutshell.
《Linux虚拟化KVM-Qemu分析(二)之ARMv8虚拟化》
;is_hyp_mode_available
用于判断ARMv8的Hyp
模式是否可用,实际是通过判断__boot_cpu_mode
的值来完成,该值是在arch/arm64/kernel/head.S
中定义,在启动阶段会设置该值:is_kernel_in_hyp_mode
,通过读取ARMv8的CurrentEL
,判断是否为CurrentEL_EL2
;SVE
的实现要求VHE
也要实现,这个可以从arch/arm64/Kconfig
中看到,SVE
的模块编译:depends on !KVM || ARM64_VHE
。SVE(scalable vector extension)
,是AArch64
下一代的SIMD(single instruction multiple data)
指令集,用于加速高性能计算。其中SIMD
如下:init_common_resources
,用于设置IPA
的地址范围,将其限制在系统能支持的物理地址范围之内。stage 2
页表依赖于stage 1
页表代码,需要遵循一个条件:Stage 1
的页表级数 >= Stage 2
的页表级数;init_hyp_mode
init_hyp_mode
解决的问题就是各种映射,最终都会调用到__create_hyp_mappings
,先来解决这个映射问题:pgd
开始逐级往下去建立映射。ARMv8架构在实际映射过程中,P4D
这一级页表并没有使用。让我们继续回到init_hyp_mode
的正题上来,这个函数完成了PGD
页表的分配,完成了IDMAP代码段
的映射,完成了其他各种段的映射,完成了异常向量表的映射,等等。此外,再补充几点内容:
ARMv8异常向量表
Synchronous,IRQ,FIQ,SError
。以系统启动时设置hypervisor的异常向量表__hyp_stub_vectors
为例:Exception Level
触发异常时,根据执行状态,去选择对应的handler
处理,比如上图中只有el1_sync
有效,也就是在EL1
状态触发EL2
时跳转到该函数;pushsection/popsection
init_hyp_mode
函数中,完成各种段的映射,段的定义放置在vmlinux.lds.S
中,比如hyp.idmap.text
:pushsection/popsection
来在目标文件中来添加一个段,并指定段的属性,比如"ax"代表可分配和可执行,这个在汇编代码中经常用到,比如hyp-init.S
中,会将代码都放置在hyp.idmap.text
中:pushsection/popsection
外,通过#define __hyp_text __section(.hyp.text) notrace __noscs
的形式也能将代码放置在指定的段中;Hypervisor相关寄存器
sctlr_el2(System Control Register)
:可以用于控制EL2的MMU和Cache相关操作;ttbr0_el2(Translation Table Base Register 0)
:用于存放页表的基地址,上文中提到分配的hyp_pgd
就需要设置到该寄存器中;vbar_el2(Vector Base Address Register)
:用于存放异常向量表的基地址;我们需要先明确几点:
Hyp
模式下要执行的代码,需要先建立起映射;IDMAP代码段
和其他代码段,明确这些段中都有哪些函数,这个可以通过pushsection/popsection
以及__hyp_text
宏可以看出来;貌似内容比较零碎,最终的串联与谜题留在下一小节来解答。
init_subsystems
先看一下函数的调用流程:
VGIC
,timer
,以及电源管理相关模块在本文中暂且不深入分析了,本节主要关心cpu_hyp_reinit
的功能;EL2
进行执行;看图中有好几次异常向量表的设置,此外,还有页表基地址、栈页的获取与设置等,结合上一小节的各类映射,是不是已经有点迷糊了,下边这张图会将这些内容串联起来:
__hyp_stub_vectors
,__kvm_hyp_init
, __kvm_call_hyp
,这些代码都是汇编实现;arch/arm64/kernel/head.S
),调用到el2_setup
函数,在该函数中设置了一个临时的异常向量表,也就是先打一个桩,这个从名字也可以看出来,该异常向量表中仅实现了el2_sync
的handler
处理函数,可以应对两种异常:1)设置新的异常向量表;2)重置异常向量表,也就是设置回__hyp_stub_vectors
;kvm
初始化时,调用了__hyp_set_vectors
来设置新的异常向量表:__kvm_hyp_init
。这个向量表中只实现了__do_hyp_init
的处理函数,也就是只能用来对Hyp模式
进行初始化。上文提到过idmap段
,这个代码就放置在idmap段
,以前分析内存管理子系统时也提到过idmap
,为什么需要这个呢?idmap: identity map
,也就是物理地址和虚拟地址是一一映射的,防止MMU在使能前后代码不能执行;__kvm_call_hyp
函数,用于在Hyp模式
下执行指定的函数,在cpu_hyp_reinit
函数中调用了该函数,传递的参数包括了新的异常向量表地址,页表基地址,Hyp
的栈地址,per-CPU
偏移等,最终会调用__do_hyp_init
函数完成相应的设置。到此,页表和异常向量表的设置算是完成了。
misc_register
misc_register
用于注册字符设备驱动,在kvm_init
函数中调用此函数完成注册,以便上层应用程序来使用kvm模块
:
kvm
, vm
, vcpu
,上层最终使用底层的服务都是通过ioctl
函数来操作;kvm
:代表kvm内核模块,可以通过kvm_dev_ioctl
来管理kvm版本信息,以及vm的创建等;vm
:虚拟机实例,可以通过kvm_vm_ioctl
函数来创建vcpu
,设置内存区间,分配中断等;vcpu
:代表虚拟的CPU,可以通过kvm_vcpu_ioctl
来启动或暂停CPU的运行,设置vcpu的寄存器等;以Qemu
的使用为例:
/dev/kvm
设备文件;ioctl(xx, KVM_CREATE_VM, xx)
创建虚拟机对象;ioctl(xx, KVM_CREATE_VCPU, xx)
为虚拟机创建vcpu对象;ioctl(xx, KVM_RUN, xx)
让vcpu运行起来;本文主要从两个方向来介绍了kvm_init
:
EL2
的相关设置,比如各个段的映射,异常向量表的安装,页表基地址的设置等,当把这些准备工作做完后,才能在硬件上去支持虚拟化的服务请求;ioctl
的函数,上层应用程序可以通过字符设备文件,来操作底层的kvm模块。这部分内容深入的分析,留到后续的文章再展开了;实际在看代码过程中,一度为很多细节绞尽乳汁,对不起,是绞尽脑汁,每有会意,便欣然忘食,一文也无法覆盖所有内容,草率了。
欢迎关注个人公众号,不定期更新技术文章。
【原创】Linux虚拟化KVM-Qemu分析(三)之KVM源码(1)
原文:https://www.cnblogs.com/LoyenWang/p/13659024.html