新程序圆

4.之后是分页初始化、IRQ中断初始化、调度程序初始化、异常处理程序表初始化、时间设置、安全机制设置等初始化工作，并且Xen会初始化一个空闲虚拟域(Idle Domain)，当没有合适的虚拟域可以运行的时候，Xen会选择空闲虚拟域来运行，这很类似于Linux中的init进程。然后就是x86_32.S文件。可以使用readelf命令来查看编译后生成的Xen的内核，它表明文件类型为可执行文件，并且程序的入口点是Oxl0000(原本这是Linux内核的位置)，这表明Xen被引导程序放在了物理内存1M的位置上。

由于Xen的自定义I/O模型使用虚拟机中的hypercall进行ARM上的设备模拟，因此Xen并不能运行guest操作系统，除非它们被配置为包含Xen的hypercall层并包含对XenBus半虚拟化驱动程序的支持。相比之下，KVM/ARM使用标准Linux组件支持更快的开发，完全支持SMP，以及可运行未经修改的操作系统的能力。与此相反，我们首次评估了使用真实硬件的ARM虚拟化扩展，提供了与x86的直接比较，并介绍了使用ARM虚拟化扩展(包括SMP支持)的完整hypervisor的设计和实现。

在没有VGIC和虚拟时钟的ARM平台上，测量时不包括保存和恢复VGIC状态的开销，结果表明，该操作在ARM的两个world切换时VGIC状态的恢复和保存占用了一半的开销。总的来说，在多核的情况下，在KVM/ARM上的所有应用程序的工作负载比直接在硬件上运行的情况多执行10%的任务量。尽管ARM的world切换开销较高，但是ARM比x86更快，因为x86上的底层硬件IPI比较占据开销，x86上的APIC MMIO操作需要KVM x86执行ARM上不需要的指令解码，而在x86上完成中断的开销较大。

我们已经成功地将我们的工作集成到Linux内核中，KVM/ARM现在是Linux平台上的标准ARM hypervisor，因为从39内核开始，每个内核都包含了它。它相对简单且能快速完成虚拟化的需求，这得益于特定的设计，这些设计选择允许它利用Linux内核现有的基础，尽管底层硬件存在一些差异化。我们分享了一些从我们的经验中学到的教训，希望他们可以帮助其他人获得开源社区广泛采用的研究思路。代码可维护性是关键：一个常见的误解是，提供潜在改进或有趣的新特性的研究软件实现可以简单地开源，从而被开源社区快速集成。经常没

KVM/ARM是利用LInux内核中现有的基础来实现的，如果重新设计和实现hypervisor复杂的核心功能，这将可能引入一些知名的bug。虽然单独的hypervisor设计方式具有更好的性能和更小的TCB，但是该种方式并不适合ARM架构。ARM硬件在很多方面都比x86更加多样化。不同的设备制造商通常以非标准的方式将硬件组件集成到ARM设备中。ARM硬件缺乏用于硬件探测的功能，例如标准BIOS或APCI总线，并且没有为安装低级软件建立相关机制。但是巨虎所有的ARM平台都支持Linux,通过将KVM/ARM与

ARM架构的CPU在移动设备和服务器中使用得越来越普遍，为基于ARM架构的设备提供虚拟化的新需求也越来越大。我们介绍了构建Linux ARM hypervisor KVM/ARM的经验，这是第一个完整的ARM虚拟化系统解决方案，可以在ARM多核硬件上运行未经修改的guest操作系统。KVM/ARM引入了分裂模式虚拟化，运行hypervisor跨CPU模式分割执行，并将其集成到Linux内核中。

虚拟化，qemu、kvm，type1、type2、嵌套虚拟化

本文会将ARM GICv2中断虚拟化的总体框架和流程讲清楚，这个曾经困扰我好几天的问题在被捋清的那一刻，让我有点每有会意，欣然忘食的感觉。中断是处理器用于异步处理外围设备请求的一种机制；外设通过硬件管脚连接在中断控制器上，并通过电信号向中断控制器发送请求；中断控制器将外设的中断请求路由到CPU上；

前边系列将Virtio Device和Virtio Driver都已经讲完，本文将分析virtqueue；virtqueue用于前后端之间的数据交换，一看到这种数据队列，首先想到的就是ring-buffer，实际的实现会是怎么样的呢？

前篇文章讲完了Qemu中如何来创建Virtio Device，本文将围绕Guest OS中的Virtio Driver来展开；核心模块为virtio和virtqueue，其他高层的驱动都是基于核心模块之上构建的；显然，本文会延续这个系列，继续分析virtio-net驱动，重心在整体流程和框架上，细节不表；virtio-net，又是一个virtio设备，又是一个PCI设备，那么驱动会怎么组织呢？带着问题上路吧。

图中罗列了四个关键模块：Virtio Device、Virtio Driver、Virtqueue、Notification（eventfd/irqfd）；Virtio Driver：前端部分，处理用户请求，并将I/O请求转移到后端；Virtio Device：后端部分，由Qemu来实现，接收前端的I/O请求，并通过物理设备进行I/O操作；Virtqueue：中间层部分，用于数据的传输；Notification：交互方式，用于异步事件的通知；

从本文开始将研究一下virtio；本文会从一个网卡虚拟化的例子来引入virtio，并从大体架构上进行介绍，有个宏观的认识；细节的阐述后续的文章再跟进；

先从操作系统的角度来看一下timer的作用吧：定时器的维护，包括用户态和内核态，当指定时间段过去后触发事件操作，比如IO操作注册的超时定时器等；更新系统的运行时间、wall time等，此外还保存当前的时间和日期，以便能通过time()等接口返回给用户程序，内核中也可以利用其作为文件和网络包的时间戳；调度器在调度任务分配给CPU时，也会去对task的运行时间进行统计计算，比如CFS调度，Round-Robin调度等；资源使用统计，比如系统负载的记录等，此外用户使用top命令也能进行查看；

非虚拟化下的内存的访问CPU访问物理内存前，需要先建立页表映射（虚拟地址到物理地址的映射），最终通过查表的方式来完成访问。在ARMv8中，内核页表基地址存放在TTBR1_EL1中，用户空间页表基地址存放在TTBR0_EL0中；虚拟化下的内存访问虚拟化情况下，内存的访问会分为两个Stage，Hypervisor通过Stage 2来控制虚拟机的内存视图，控制虚拟机是否可以访问某块物理内存，进而达到隔离的目的；

本文围绕ARMv8 CPU的虚拟化展开；本文会结合Qemu + KVM的代码分析，捋清楚上层到底层的脉络；本文会提供一个Sample Code，用于类比Qemu和KVM的关系，总而言之，大同小异，大题小做，大道至简，大功告成，大恩不言谢；先来两段前戏。

从本文开始将开始source code的系列分析了；KVM作为内核模块，可以认为是一个中间层，向上对接用户的控制，向- - 下对接不同架构的硬件虚拟化支持；本文主要介绍体系架构初始化部分，以及向上的框架；底层的体系结构相关的初始化，主要涉及的就是EL2的相关设置，比如各个段的映射，异常向量表的安装，页表基地址的设置等，当把这些准备工作做完后，才能在硬件上去支持虚拟化的服务请求；字符设备注册，设置好各类ioctl的函数，上层应用程序可以通过字符设备文件，来操作底层的kvm模块。

KVM虚拟化离不开底层硬件的支持，本文将介绍ARMv8架构处理器对虚拟化的支持，包括内存虚拟化、中断虚拟化、I/O虚拟化等内容；ARM处理器主要用于移动终端领域，近年也逐渐往服务器领域靠拢，对虚拟化也有了较为完善的支持；Hypervisor软件，涵盖的功能包括：内存管理、设备模拟、设备分配、异常处理、指令捕获、虚拟异常管理、中断控制器管理、调度、上下文切换、内存转换、多个虚拟地址空间管理等；

从这篇文章开始，将开始虚拟化的系列研究了，大概会涉及到ARM64虚拟化支持、KVM、QEMU等分析；虚拟化相关的实践与操作有且仅有：VMware/VirtualBox等虚拟机使用、QEMU使用、QEMU源码修改模拟IO设备；，一切从源代码出发；本文作为开篇，从宏观方面来进行介绍，有个初步认识，不涉及到具体原理分析。

KVM的全称是Kernel-based Virtual Machine，其是一种基于linux内核的采用硬件辅助虚拟化技术的全虚拟化解决方案。它最初由以色列的初创公司Qumranet开发，并在linux-2.6.20中开始被纳入在linux内核，成为内核源码的一部分。KVM自诞生之初就定位于基于硬件辅助的虚拟化来提供全虚拟化的支持，其以内核模块的形式被加载。加载KVM模块的linux内核相当于变成了一个Hypervisor，同时依赖linux内核提供的各种功能来实现硬件管理，拥有极高的兼容性及可扩展性。