背景

Read the fucking source code! --By 鲁迅

A picture is worth a thousand words. --By 高尔基

说明：

  • KVM版本：5.9.1
  • QEMU版本：5.0.0
  • 工具：Source Insight 3.5， Visio

1. 概述

  • 从这篇文章开始，将开始虚拟化的系列研究了，大概会涉及到ARM64虚拟化支持、KVM、QEMU等分析；
  • 虚拟化相关的实践与操作有且仅有：VMware/VirtualBox等虚拟机使用、QEMU使用、QEMU源码修改模拟IO设备；
  • Show me the code，一切从源代码出发；

本文作为开篇，从宏观方面来进行介绍，有个初步认识，不涉及到具体原理分析。

2. 概念

2.1 虚拟化

android qemu 虚拟化 qemu半虚拟化_ubuntu

什么是虚拟化？

  • 虚拟化是一种资源管理技术，在非虚拟化系统中，单个操作系统管理和使用所有的硬件资源，而在虚拟化系统中，
    硬件资源可以被抽象和分割成多个虚拟的实体用于支持多个操作系统，多个操作系统可以共享所有的实体硬件资源，从而达到物理资源的最大化利用；
  • Virtual Machine Motior(VMM)，虚拟机监控器，也叫Hypervisor，向下管理实际的物理资源，向上给不同的虚拟机提供逻辑资源；
  • Virtual Machine(VM)，虚拟机可以根据自己的选择运行不同的OS（Guest OS），它会认为自己独享硬件；
  • 虚拟化的好处就是能提高资源的利用率，比如当前计算机的配置资源都很高，实际的利用率比较低，如果进行统一管理并进行虚拟化，那就可以支持更多的用户来合理利用了；

2.2 软件虚拟化和硬件虚拟化

2.2.1 软件虚拟化

通过软件模拟来实现VMM层，比如QEMU，还是以图片来举例说明下：

android qemu 虚拟化 qemu半虚拟化_android qemu 虚拟化_02

  • 以典型的场景为例（ARM+Linux的模拟环境）：在PC机Ubuntu系统中使用Qemu来模拟ARM64处理器，并在ARM64中运行Guest OS，假设Guest OS也为Linux；
  • 在没有硬件虚拟化的支持下，QEMU本质上完成的工作是二进制的翻译，这个问题怎么来理解呢？比如Guest OS运行时，APP和OS都认为自己是运行在ARM64中，执行文件也都是交叉编译器生成的，我们都知道不同的处理器架构，指令集都不一样，ARM上运行的程序放置到X86运行是无法执行的，Qemu的出现就可以解决这个问题，硬生生转换翻译过去；
  • Qemu的翻译过程为：将Guest代码指令翻译成TCG(Tiny Code Generator)中间代码，最终翻译成Host架构支持的代码指令；
2.2.2 硬件虚拟化

纯软件行为来翻译指令，显然是一件很低效的事情，硬件虚拟化的支持可以提高整体的性能，硬件虚拟化指处理器本身提供能力来让客户机指令独立运行。

android qemu 虚拟化 qemu半虚拟化_虚拟化_03

  • KVM (Kernel-Based Virtual Machine)，基于内核的虚拟机，实现对CPU和内存的虚拟化，以及硬件I/O虚拟化的拦截，Guest的I/O被KVM拦截后交给Qemu去处理；
  • KVM是内核的一个Module，可以让Linux变成一个Hypervisor；
  • KVM需要Host处理器本身支持虚拟化扩展，比如intel VT，AMD-V等；

2.3 半虚拟化和全虚拟化

android qemu 虚拟化 qemu半虚拟化_linux_04

  • 半虚拟化（Para-Virtualization）：客户机操作系统知道自身运行在虚拟环境里，进行定制化修改，以配合Hypervisor进行工作，优点是半虚拟化的架构更精简，性能上有一定优势，缺点是客户机OS需要修改，用户体验偏差；
  • 典型的半虚拟化技术virtio，需要宿主机/Hypervisor和客户机都安装对应的驱动；
  • 全虚拟化（Full Virtualization）：客户机操作系统不需要任何改动，使用简单，由于全虚拟化需要模拟出完整的，和物理平台一样的平台给客户机，因此也增加了Hypervisor的设计难度；

2.4 Type1虚拟化和Type2虚拟化

android qemu 虚拟化 qemu半虚拟化_android qemu 虚拟化_05

  • 从软件的框架角度，根据Hypervisor是直接在硬件之上，还是在宿主机操作系统之上，可以将虚拟化分成Type1和Type2；
  • Type1虚拟化：native/bare-mental Hypervisor，直接控制硬件资源和客户机，典型的是Xen；
  • Type2虚拟化：Hypervisor运行在宿主机操作系统之上，典型的比如：VMware Workstation, KVM等，Hypervisor只是宿主机操作系统的一个应用程序；

3.kvm-qemu框架

从上文的虚拟化分类来看，我们研究目标KVM+Qemu，是采用硬件虚拟化技术的全虚拟化方案（Type2）。

android qemu 虚拟化 qemu半虚拟化_硬件资源_06

  • Qemu (Quick Emulator)：是虚拟化方案的用户态组成部分，它有两种模式：1）Emulator，模拟器，模拟各种硬件，使用的是二进制翻译技术；2）Virtualiser，虚拟机，通过ioctl与KVM内核模块进行交互，完成虚拟化功能；
  • Qemu为每个VM虚拟机创建一个进程，针对每个vCPU虚拟CPU创建一个线程，Guest的系统和应用运行在vCPU之上；
  • Qemu能模拟I/O功能，而这部分功能KVM可能并不是全部支持，执行流程如下：虚拟机VM中的程序执行I/O操作，VM退出进入KVM，KVM进行判断处理并将控制权交给Qemu，由Qemu来模拟I/O设备来响应程序的I/O请求；
  • KVM内核模块，依赖于底层硬件的虚拟化支持，主要的功能是初始化CPU硬件，打开虚拟化模式，将虚拟化客户机运行在虚拟机模式下，并对虚拟化客户机的运行提供一定的支持；
  • KVM内核模块，实现CPU的虚拟化、内存的虚拟化等，而外设IO的虚拟化，通常不由KVM模块负责，只有对性能要求很高的虚拟设备才需要由KVM内核模块来负责，因此也就有KVM + Qemu的组合方案了；
    本文纯当扫盲贴了，至于具体技术细节的深入分析，后续会进行不定期更新。

4.参考

《KVM实战-原理、进阶与性能调优》