-
自顶向下设计与实现Virtio
什么是Virtio？为什么需要Virtio？ Virtio看字面是由Virt(Virtualization)和IO(Input/Output)两部分组成，含义是虚拟化环境下使用的IO协议/设备。早期在虚拟化技术的实现过程中，为了重用现有的设备驱动，虚拟化设备模拟软件一般都是模拟已有物理设备的行为(遵循物理IO协议)，比如通过模拟IDE硬盘可以在虚拟机中完全重用IDE驱动。但是这里引发一个问题，模拟已有的物理设备行为往往导致虚拟化软件性能较低，比如IDE硬件是通过端口(Port)进行数据输...…
-
CUDA执行模型
编程模型(Programming Model)与执行模型(Execution Model) 前文分析CUDA原理时介绍了CUDA的编程模型，它是对硬件的抽象，作用是便于开发人员将逻辑思维过程转换为计算系统的物理运行过程。CUDA内部实现非常复杂，基础编程模型可以方便地表达并行性，但是在性能上暴露的细节不多，因此有可能无法充分发挥硬件潜能。正因如此，CUDA引出了执行模型的概念，进一步向开发者暴露设备内部执行细节，并提供性能分析工具和API，使得开发者可以调试应用性能。 CUDA执行模型...…
-
CUDA概述
定义(what) CUDA(Compute Unified Device Architecture)，中文叫统一计算设备架构，它是NVIDIA公司基于自身异构计算设备(GPU)提出的一种统一串行计算(CPU完成)和并行计算(GPU完成)的可编程异构融合计算系统。GPU相比CPU而言，面对SIMD并行计算模式有成百上千倍的计算性能提升，且有着更低的功耗优势。因此GUDA也一种是执行串并行混合复杂任务的理想计算系统。串行计算 对于一般性计算任务，总是可以分解成小的计算片段依次执行，这就是通...…
-
【firecracker】系统启动与epoll事件循环
在分析完firecracker虚拟机中各个子系统的运行时原理和初始化流程后，最后我们整体分析一下firecracker的系统启动过程，并重点分析IO线程(fc_vmm)所采用的epoll事件循环框架。 回顾首文中介绍的firecracker进程的线程模型，下图展示了线程间的事件通知关系： firecracker进程的主线程在启动完成后会成为API S...…
-
【firecracker】legacy设备
除了virtio-mmio设备，firecracker还实现了串口、键盘等legacy设备，这些设备可以直接由虚拟机内核自带驱动程序驱动，并为虚拟机提供基本的输入输出功能。X86架构下，legacy设备主要通过IO端口进行控制和操作，因此firecracker采用IO总线来组织和管理所有的legacy设备。运行时原理 和mmio总线类似，legacy设备也以BTree形式组织于devices::Bus下，并且每个设备都需要实现BusDevice trait：firecracker/d...…
-
【firecracker】virtio-mmio设备
外部设备为CPU提供存储、网络等多种服务，是计算机系统中除运算功能之外最为重要的功能载体。CPU与外设之间通过某种协议传递命令和执行结果；virtio协议最初是为虚拟机外设而设计的IO协议，但是随着应用范围逐步扩展到物理机外设，virtio协议正朝着更适合物理机使用的方向而演进。virtio设备运行原理一、抽象原理 对于采用virtio协议进行通信的CPU和外设，其抽象原理如下图所示。CPU与外设可以共同访问内存(例如外设以DMA方式访问内存)；内存中存在一个称为环形队列(IO RI...…
-
【firecracker】时钟与中断
firecracker虚拟机的时钟与中断系统完全是由KVM模块和硬件实现的，这里仅简要说明其原理，更深入的分析需要结合KVM代码和内核代码进行。时钟系统原理 时钟系统包含时间源和时钟事件源两部分： 时间源类似生活中的手表，系统通过它可以获知时间，其本质为一个递增的计数器，计数器数值代表当前时间；firecracker中的时钟源有KVM_CLOCK和TSC两种，默认使用KVM_CLOCK； 时种 事件源类似生活中的闹钟，系统通过它可以获得时间到期通知事件，其本质为一个递...…
-
【firecracker】CPU与内存
运行原理 firecracker虚拟机的CPU与内存功能依赖于硬件辅助虚拟化能力(如intel vt-x特性)： 硬件辅助虚拟化技术为物理CPU增加了一种新的执行模式(Guest Mode/None-Root Mode),在该模式下，CPU中执行的是虚拟机的指令，而非物理机指令。这是一种高效的虚拟指令执行方式，但是在该模式下并不能直接执行所有的虚拟机执令，某些特权指令(如IO指令)的执行会强制将CPU退出到普通模式(Root Mode)交由VMM程序(内核KVM模块/用户态fi...…
-
【firecracker】概述
Ｗhat firecracker（中文名鞭炮，寓意虚拟机的生命可以像鞭炮一样短暂，一闪即逝，但相同时刻却可以有成千上万个虚拟机快速闪现）是一种基于KVM的轻量虚拟化技术，相比普通虚拟机，firecracker虚拟机内存占用更少、启动速度更快；相比容器，firecracker则具有极强的安全隔离性。另外，firecracker采用全新的安全编程语言Rust实现，提供了语言级的内存安全与线程安全保障，使它天生具备了安全基因。Why firecracker为了同时实现虚拟机的隔离性和容器的轻...…
-
【SPDK】七、vhost客户端连接请求处理
vhost客户端连接后，将遵循vhost协议进行一系统复杂的消息传递与处理过程，最终服务端将生成一个可处理IO环中请求并返回响应的处理线程。本篇博文将分析其中最为重要两类消息的处理原理：内存映射消息和IO环信息传递消息。最后将一起来看一下vhost通用消息处理完成后，vhost-blk设备是如何完成最后的初始化动作的(其它类型的vhost设备大家可以自行阅读代码分析)。vhost内存映射 vhost的reactor线程在处理IO请求时，需要访问虚拟机的内存空间。我们知道，虚拟机可见的...…
-
【SPDK】六、vhost子系统
vhost子系统在SPDK中属于应用层或叫协议层，为虚拟机提供vhost-blk、vhost-scsi和vhost-nvme三种虚拟设备。这里我们以vhost-blk为分析对象，来讨论vhost子系统基本原理。vhost子系统初始化 vhost子系统的描述如下：spdk/lib/event/subsystems/vhost/vhost.c:static struct spdk_subsystem g_spdk_subsystem_vhost = { .name = "vhost...…
-
【SPDK】五、bdev子系统
SPDK从功能角度将各个独立的部分划分为“子系统“。例如对各种后端存储的访问属于bdev子系统，又例如对虚拟机呈现各种设备属于vhost子系统。不同场景下，各种工具可以通过组合不同的子系统来实现各种不同的功能。例如虚拟化场景下，vhost主要集成了bdev、vhost、scsi等子系统。这些子系统存在一定依赖关系，例如vhost子系统依赖bdev，这就需要将被依赖的子系统先初始化完成，才能执行其它子系统的初始化。 本篇博文我们先整体介绍一下SPDK子系统的初始化流程，然后再深入分析一...…
-
【SPDK】四、reactor线程
reactor线程是SPDK中负责实际业务处理逻辑的单元，它们在vhsot服务启动时创建，直到服务停止。目前还不支持reactor线程的动态增减。reactor线程总流程 我们顺着vhost进程的代码执行顺序来看看总体流程：spdk/app/vhost/vhost.c:intmain(int argc, char *argv[]){ struct spdk_app_opts opts = {}; int rc; /* 首先进行参数解析，解析后的结果保存于opts中 ...…
-
【SPDK】三、IO流程代码解析
在分析SPDK数据面代码之前，需要我们对qemu中实现的IO环以及virtio前后端驱动的实现有所了解(后续我计划出专门的博文来介绍qemu)。这里我们仍以SPDK前端配置vhost-blk，后端对接NVMe SSD为例(有关NVMe驱动涉及较多规范细节，这里也不作过于深入的讨论，感兴趣的读者可以结合NVMe规范展开阅读)进行分析。总流程 前文在分析SPDK IO栈时已经大致分析了IO处理的调用层次，在此我们进一步打开内部实现细节，更细致地分析一下IO处理流程： 首先，从虚拟机...…
-
【SPDK】二、IO栈对比与线程模型
这里我们以SPDK前端配置成vhost-blk、后端配置成NVMe SSD场景为例，来分析SPDK的IO栈和线程模型。IO栈对比与时延分析 我们先来对比一下qemu使用普通内核NVMe驱动和使用SPDK vhost时IO栈的差别，如下图所示： 无论使用传统内核NVMe驱动，还是使用vhost，虚拟机内部的IO处理流程都是一样的：IO请求下发时需要从用户态应用程序中切换到内核态，并穿过文件系统和virtio-blk驱动后，才能借助IO环(IO Ring)将请求信息传递给虚拟设备进...…
-
【SPDK】一、概述
随着越来越多公有云服务提供商采用SPDK技术作为其高性能云存储的核心技术之一，intel推出的SPDK技术备受业界关注。本篇博文就和大家一起探索SPDK。什么是SPDK？为什么需要它？ SPDK(全称Storage Performance Development Kit)，提供了一整套工具和库，以实现高性能、扩展性强、全用户态的存储应用程序。它是继DPDK之后，intel在存储领域推出的又一项颠覆性技术，旨在大幅缩减存储IO栈的软件开销，从而提升存储性能，可以说它就是为了存储性能而生...…
-
【Rados Block Device】九、Monitor原理分析
Monitors是ceph集群的管理节点，负责维护整个集群的全局信息(如OSDMap)；Client和OSD加入和退出集群时，都需要和Monitors打交道，而且都需要从Monitors中获取最新的全局信息(如OSDMap)进行相关操作(如CRUSH数据映射)。 CatKang的博文对Monitor进行了比较多全的分析，这里我只补充一些自己的理解。Monitor的代码分析大家可以对照原理分析自行开展，略显枯燥，paxos算法相关原理可参考此篇博文，不过注意一点，ceph没有完全按照pa...…
-
【Rados Block Device】八、OSD原理分析－FileStore模块
从前面的博文分析中，我们知道OSD模块在请求处理的最后阶段会向ObjectStore发起操作请求，ObjectStore负责对象的实际存储功能，有filestore、bluestore、memstore、kstore等多种存储方式，这里我们以基本的filestore为例展开分析。FileStore模块中对象、流程概览 我们照例先整体来看一下FileStore模块的对象和流程： OSD模块在tp_osd_tp线程上下文的最后阶段，通过queue_transactions调用Fil...…
-
【Rados Block Device】七、OSD原理分析－OSD模块
OSD进程从网络收到客户端的读写请求后，交由OSD模块执行核心的请求处理逻辑，本篇博文将讨论OSD模块的实现原理。OSD模块中对象、流程概览 我们先整体来看一下OSD模块的对象和流程： 回顾前文对SimpleMessenger的分析，我们看到ms_pipe_read线程从网络中收到请求消息后，通过fast_dispatch接口将消息分发给OSD对象进行处理。OSD对象针对接收到的每一个消息，都会将它们放入一个工作队列中(ShardedOpWQ，片式队列)。到这里，ms_pipe...…
-
【Rados Block Device】六、OSD原理分析－SimpleMessenger模块
OSD进程通过网络对Client提供服务，因此网络层是OSD中的基础层。本篇博文将讨论ceph中传统的SimpleMessenger实现原理。SimpleMessenger模块中对象、流程概览 如果将OSD进程的网络服务模式配置成SimpleMessenger，那么它采用的是POSIX标准网络接口来实现网络功能。也就是说，此时我们的OSD服务从代码实现流程上来说就是通过socket()->bind()->listen()->accept()进行连接建立，随后再通过每...…
