smart_an的专栏

OpenCL(Open Computing Language，开放计算语言）：从软件视角看，它是用于异构平台编程的框架；从规范视角看，它是异构并行计算的行业标准，由Khronos Group来维护；异构平台包括了CPU、GPU、FPGA、DSP，以及最近几年流行的各类AI加速器等；OpenCL包含两部分：1）用于编写运行在OpenCL device上的kernels的语言（基于C99）；2）OpenCL API，至于Runtime的实现交由各个厂家，比如Intel发布的。

Workqueue工作队列是利用内核线程来异步执行工作任务的通用机制；Workqueue工作队列可以用作中断处理的机制，利用进程上下文来执行中断处理中耗时的任务，因此它允许睡眠，而Softirq和Tasklet在处理任务时不能睡眠；在中断处理过程中，或者其他子系统中，调用workqueue的调度或入队接口后，通过建立好的链接关系图逐级找到合适的worker，最终完成工作任务的执行；

中断子系统中有一个重要的设计机制，那就是Top-half和Bottom-half，将紧急的工作放置在Top-half中来处理，而将耗时的工作放置在中来处理，这样确保Top-half能尽快完成处理，那么为什么需要这么设计呢？ARM处理器在进行中断处理时，处理器进行异常模式切换，此时会将中断进行关闭，处理完成后再将中断打开；如果中断不分上下半部处理，那么意味着只有等上一个中断完成处理后才会打开中断，下一个中断才能得到响应。

之前文章里讲到了底层硬件GIC驱动，以及Arch-Specific的中断代码，本文将研究下通用的中断处理的过程，属于硬件无关层。当然，我还是建议你看一下上篇文章。用户是怎么使用中断的（中断注册外设触发中断信号时，最终是怎么调用到中断handler的（中断处理从上到下：围绕irq_desc中断描述符建立好连接关系，这个过程就包括：中断源信息的解析（设备树），硬件中断号到Linux中断号的映射关系、irq_desc结构的分配及初始化（内部各个结构的组织关系）、中断的注册（填充irq_desc。

从这篇文章开始，来聊一聊中断子系统。中断是处理器用于异步处理外围设备请求的一种机制，可以说中断处理是操作系统管理外围设备的基石，此外系统调度、核间交互等都离不开中断，它的重要性不言而喻。硬件层：最下层为硬件连接层，对应的是具体的外设与SoC的物理连接，中断信号是从外设到中断控制器，由中断控制器统一管理，再路由到处理器上；硬件相关层：这个层包括两部分代码，一部分是架构相关的，比如ARM64处理器处理中断相关，另一部分是中断控制器的驱动代码；

汪汪汪，最近忙成狗了，一下子把我更新的节奏打乱了，草率的道个歉。前边系列将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入手，我会选择从一个实际的设备来阐述，没错，还是上篇文章中提到的网络设备。

作者简介：大家好，我是码炫码哥，前中兴通讯、美团架构师，现任某互联网公司CTO，兼职码炫课堂主讲源码系列专题代表作：《jdk源码&多线程&高并发》，《深入tomcat源码解析》，《深入netty源码解析》，《深入dubbo源码解析》，《深入springboot源码解析》，《深入spring源码解析》，《深入redis源码解析》等联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬。

先从操作系统的角度来看一下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设备；，一切从源代码出发；本文作为开篇，从宏观方面来进行介绍，有个初步认识，不涉及到具体原理分析。

Linux内核中关于视频设备驱动的框架，对上向应用层提供统一的接口，对下支持各类复杂硬件的灵活扩展；V4L2框架，主要包括v4l2-corevideobuf2等模块，这也是本文将要展开的内容，仅提纲挈领；开始吧。

本文将讲PCIe Host的驱动，对应为部分，相当于PCI的部分；本文会选择Xilinx的nwl-pcie来进行分析；驱动的编写整体偏简单，往现有的框架上套就可以了，因此不会花太多笔墨，点到为止；PCIe控制器驱动，各家的IP实现不一样，驱动的差异可能会很大，单独分析一个驱动毕竟只是个例，应该去掌握背后的通用框架；各类驱动，大体都是硬件初始化配置，资源申请注册，核心是处理与硬件的交互（一般就是中断的处理），如果需要用户来交互的，则还需要注册设备文件，实现一堆操作函数集；

本文将分析Linux PCI子系统的框架，主要围绕Linux PCI子系统的初始化以及枚举过程分析；如果对具体的硬件缺乏了解，建议先阅读上篇文章《Linux PCI驱动框架分析（一）》；话不多说，直接开始。

PCI/PCIe总线硬件；Linux PCI驱动核心框架；Linux PCI Host控制器驱动；不排除会包含PCIe外设驱动模块，一切随缘。作为专题的第一篇，当然会先从硬件总线入手。进入主题前，先讲点背景知识。第一代总线包含ISAEISAVESA和等；第二代总线包含PCIAGPPCI-X等；第三代总线包含PCIemPCIem.2等；

sysfs文件系统提供了一种用户与内核数据结构进行交互的方式，可以通过来进行挂载；Linux设备模型中，设备、驱动、总线组织成拓扑结构，通过sysfs文件系统以目录结构进行展示与管理；Linux设备模型中，总线负责设备和驱动的匹配，设备与驱动都挂在某一个总线上，当它们进行注册时由总线负责去完成匹配，进而回调驱动的probe函数；SoC系统中有spii2cpci等实体总线用于外设的连接，而针对集成在SoC中的外设控制器，Linux内核提供一种虚拟总线platform。

Blocking IO Model，阻塞IO模型；Nonblocking I/O Model，非阻塞IO模型；I/O Multiplexing Model，IO多路复用模型;Signal Driven I/O Model，信号驱动IO模型；Asynchronous I/O Model，异步IO模型；今天我们来分析下IO多路复用机制，在Linux中是通过机制来实现的。

连续内存分配器，用于分配连续的大块内存。CMA分配器设备驱动不用时，内存管理系统将该区域用于分配和管理可移动类型页面；设备驱动使用时，用于连续内存分配，此时已经分配的页面需要进行迁移；此外，CMA分配器还可以与DMA子系统集成在一起，使用DMA的设备驱动程序无需使用单独的CMA API。

RMAP反向映射是一种物理地址反向映射虚拟地址的方法。映射页表用于虚拟地址到物理地址映射，其中的PTE页表项记录了映射关系，同时结构体中的mapcount字段保存了有多少PTE页表项映射了该物理页。反向映射当某个物理地址要进行回收或迁移时，此时需要去找到有多少虚拟地址射在该物理地址，并断开映射处理。在没有反向映射的机制时，需要去遍历进程的页表，这个效率显然是很低下的。反向映射可以找到虚拟地址空间VMA，并仅从VMA使用的用户页表中取消映射，可以快速解决这个问题。kswapd。

上篇文章分析到函数中，内核实现只是在进程的地址空间建立好了vma区域，并没有实际的虚拟地址到物理地址的映射操作。这部分就是在Page Fault异常错误处理中实现的。Linux内核中的Page Fault异常处理很复杂，涉及的细节也很多，的物理内存映射只是它的一个子集功能，下图大概涵盖了出现Page Fault的情况：下边就开始来啃啃硬骨头吧。

vma;malloc;mmap;进程地址空间中，我们常见的代码段，数据段，bss段等，实际上都是一段地址空间区域。Linux将地址空间中的区域称为， 简称VMA，使用来描述。在进行内存申请和映射时，都会去地址空间中申请一段虚拟地址区域，而这部分操作也与vma关系密切，因此本文将三个放到一块来进行分析。开启探索之旅吧。

在之前的系列文章中，分析到了的页框分配，Slub分配器的小块内存对象分配，这些分配的地址都是物理内存连续的。当内存碎片后，连续物理内存的分配就会变得困难，可以使用vmap机制，将不连续的物理内存页框映射到连续的虚拟地址空间中。vmalloc的分配就是基于这个机制来实现的。还记得下边这张图吗？的区域就是在之间。开启探索之旅吧。

之前的文章分析的都是基于页面的内存分配，而小块内存的分配和管理是通过块分配器来实现的。，最先有slab分配器，slub/slob分配器是改进版，slob分配器适用于小内存嵌入式设备，而slub分配器目前已逐渐成为主流块分配器。接下来的文章，就是以slub分配器为目标，进一步深入。

本文将讨论内存回收这个话题。在内存分配出现不足时，可以通过唤醒kswapd内核线程来异步回收，或者通过直接回收来处理。在针对不同的物理页会采取相应的回收策略，而页回收算法采用来选择物理页。直奔主题吧。

本文将描述，内存碎片整理技术。内碎片：内存页里边的碎片；外碎片：内存页之间的碎片，可能会造成连续物理页面分配失败。就是通过将正在使用的可移动页面迁移到另一个地方以获得连续的空闲页面的方法。针对内存碎片，内核中定义了：不可移动，对应于内核分配的页面；：可移动，对应于从用户空间分配的内存或文件；：不可移动，可以进行回收处理；先来一张的概况图：上图对应的是的操作，而针对物理内存的操作如下图所示：在之前的文章中提到过pageblock，我们看到图中zone区域是以pageblock。

本文将分析watermark。简单来说，在使用分配页面时，会将可用的free pages与zone的watermark进行比较，以便确定是否分配内存。同时watermark也用来决定kswapd内核线程的睡眠与唤醒，以便对内存进行检索和压缩处理。回忆一下之前提到过的....WMARK_MIN,WMARK_LOW,NR_WMARK可以看出，总共有三种水印，并且只能通过特定的宏来访问。WMARK_MIN内存不足的最低点，如果计算出的可用页面低于该值，则无法进行页面计数；

本文将分析。伙伴系统，是通过将物理内存划分为页面来进行管理的系统，支持连续的物理页面分配和释放。此外，使用与碎片相关的算法来确保最大的连续页面。先通过一个例子大体介绍一下原理吧：空闲的物理页框按大小分组成个链表，每个链表存放页框的大小为2的n次幂，其中n在中取值。假设请求分配2^8 = 256检查n = 8的链表，检查是否有空闲块，找到了则直接返回；没有找到满足需求的，则查找n = 9的链表，找到512大小空闲块，拆分成两个256大小块，将其中一个256大小块返回，另一个256大小块添加到。

之前的系列内存管理文章基本上描述的是物理页面的初始化过程，以及虚拟页面到物理页面的映射建立过程，从这篇文章开始，真正要涉及到页面的分配了。接下来的文章会围绕着分区页框分配器(zoned page frame allocator)来展开，其中会包含大家熟知的分析。本文会先围绕着涉及到的数据结构，以及大体的流程做一个整体的分析，后续会针对这个流程中的细节进行更详细的拆解，我已经迫不及待了。先回顾一下（五）Linux内存管理zone_sizes_init的数据结构图：的组织关系，其中。

前面我们分析了函数的上半部分，这次让我们来到下半部分吧，下半部分主要是围绕函数展开。前景回顾：/**/在Linux中，物理内存地址区域采用zone来管理。不打算来太多前戏了，先上一张的函数调用图吧：需要再说明一点是，使用的是ARM64，UMA（只有一个Node），此外，流程分析中那些没有打开的宏，相应的函数就不深入分析了。开始探索吧！

顺着之前的分析，我们来到了函数了，本以为一篇文章能搞定，大概扫了一遍代码之后，我默默的把它拆成了两部分。/**/这一部分，我们将研究一下。PFN和NUMA。

从（二）Linux物理内存初始化中，可知在调用之前，存放和DTB的两段物理内存区域可以访问了（相应的页表已经建立好）。尽管物理内存已经通过添加进系统，但是这部分的物理内存到虚拟内存的映射还没有建立，可以通过分配一段物理内存，但是还不能访问，一切还需要等待的执行。最终页表建立好后，可以通过虚拟地址去访问最终的物理地址了。按照惯例，先上图，来一张ARM64内核的内存布局图片吧，最终的布局如下所示：开启探索之旅吧！

让我们思考几个朴素的问题？系统是怎么知道物理内存的？在内存管理真正初始化之前，内核的代码执行需要分配内存该怎么处理？我们先来尝试回答第一个问题，看过dts文件的同学应该见过memory的节点，以这个节点描述了内存的起始地址及大小，事实上内核在解析dtb文件时会去读取该memory节点的内容，从而将检测到的内存注册进系统。那么新的问题又来了？Uboot会将和dtb拷贝到内存中，并且将dtb物理地址告知kernelkernel需要从该物理地址上读取到dtb文件并解析，才能得到最终的内存信息，dtb。

要想理解好Linux的页表映射，MMU的机制是需要去熟悉的，因此将这两个模块放到一起介绍。。MMU：完成的工作就是虚拟地址到物理地址的转换，可以让系统中的多个程序跑在自己独立的虚拟地址空间中，相互不会影响。程序可以对底层的物理内存一无所知，物理地址可以是不连续的，但是不妨碍映射连续的虚拟地址空间。TLBMMU工作的过程就是查询页表的过程，页表放置在内存中时查询开销太大，因此专门有一小片访问更快的区域用于存放地址转换条目，用于提高查找效率。当页表内容有变化的时候，需要清除TLB，以防止地址映射出错。

在Linux内核中，实时进程总是比普通进程的优先级要高，实时进程的调度是由Real Time Scheduler(RT调度器)来管理，而普通进程由CFS调度器来管理。SCHED_FIFO和SCHED_RR。前边的系列文章都是针对CFS调度器来分析的，包括了CPU负载组调度Bandwidth控制等，本文的RT调度器也会从这些角度来分析，如果看过之前的系列文章，那么这篇文章理解起来就会更容易点了。前戏不多，直奔主题。

完全公平调度器，用于Linux系统中普通进程的调度。CFS采用了红黑树算法来管理所有的调度实体，算法效率为O(log(n))。CFS跟踪调度实体的虚拟运行时间vruntime，平等对待运行队列中的调度实体，将执行时间少的调度实体排列到红黑树的左边。调度实体通过和来进行红黑树的出队入队。每个周期内，根据各个任务的权重值，可以计算出运行时间runtime；运行时间runtime可以转换成虚拟运行时间vruntime；