生活需要深度

通过QEMU的用户模式，您可以在主机操作系统上运行不同架构的应用程序，无需真实的目标硬件，极大的节省了开发成本，提升了开发效率。需要注意的是，虽然 VMware Workstation 支持多种 CPU 架构的模拟，但在模拟性能和兼容性方面可能会有一定差异，特别是对于需要较高计算资源的场景。总的来说，Windows VirtualBox 是一个功能丰富、易于使用的虚拟化软件，适用于个人用户、开发者和企业用户在 Windows 环境下搭建虚拟化环境，进行开发、测试和运行多个操作系统。

SSR-IOV是Single Root I/O Virtualization的缩写。在虚拟机中，一切皆虚拟。比如网卡，虚拟机看来好像有一个真实网卡，但是这个网卡是宿主机虚拟出来的硬件，也就是一堆软件代码而已，没有真实硬件。虚拟虽然万能，但是很显然，这一堆代码是需要CPU去执行的！所以，虚拟设备的性能会随着宿主机的性能而改变，另外宿主机由于需要进行数据处理，时延等也产生了。我们之前也提到过，VT-D这个功能可以将物理的PCI-e设备直接分配给虚拟机，让虚拟机直接控制硬件，那么就可以避开上述的.

硬件架构的核心是PF（全功能）和VF（轻量级功能），其中VF的BAR空间如同桥梁，将系统内存与虚拟设备连接起来。在Linux环境中，PF的配置涉及SR-IOV控制开关和VF的数量设定，drivers/pci/iov.c是实现这一切的关键接口。是这样的：在创建虚拟机时，QEMU搭建起GVA（guest虚拟地址）到GPA（全局虚拟地址）再到HPA（主机物理地址）的桥梁。当虚拟设备驱动在虚拟机中执行操作时，GPA通过VFIO和IOMMU的协同，最终精确地定位到物理设备的HPA，确保了数据的高效传输。

汪汪汪，最近忙成狗了，一下子把我更新的节奏打乱了，草率的道个歉。前边系列将Virtio Device和Virtio Driver都已经讲完，本文将分析virtqueue；virtqueue用于前后端之间的数据交换，一看到这种数据队列，首先想到的就是ring-buffer，实际的实现会是怎么样的呢？

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

Virtqueue；：前端部分，处理用户请求，并将I/O请求转移到后端；：后端部分，由Qemu来实现，接收前端的I/O请求，并通过物理设备进行I/O操作；Virtqueue：中间层部分，用于数据的传输；：交互方式，用于异步事件的通知；想在一篇文章中写完这四个模块，有点，所以，看起来又是一个系列文章了。本文先从Qemu侧的virtio device入手，我会选择从一个实际的设备来阐述，没错，还是上篇文章中提到的网络设备。

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

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

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

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

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

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

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

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