硬件虚拟化与相关逻辑_什么情况下需要把多个物理设备虚拟成一个逻辑设备

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Golang全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注go）

正文

再来看硬件系统的互联总线，不同模块之间进行数据传输，必须有相同的地址域，也就是图中的Physical Address(PA)。

实际上，上述的VM和进程均属于软件层面的概念，存在于CPU内部。若进程内使用VA访问Memory系统时，必须进行地址转换，而负责这一转换的硬件逻辑是MMU。

至此，硬件系统结构模型如下，MMU将CPU当前进程的虚拟地址转换为PA，再发送至互联总线访问其余模块。由于VA->PA的页表保存于Memory内存，为避免每次转换都需要查询内存的页表，增加了Cache进行加速，也即Translation Lookaside Buffer(TLB)。

注意到地址域分析图，进程内的应用基于物理地址访问Memory，需要经过两级地址转换，Stage 1是将VA转换为对应虚拟机内的地址，称为Intermediate Physical Address(IPA)，Stage 2是将IPA转换为PA。这两级的地址转换由MMU完成，还有各种权限及属性相关内容。根据不同的场景，两级地址转换均可进行Bypass处理，其转换关系如下图所示。另外，系统内的很多特性均是构建于该地址转换流程的，如隔离和安全，进程使用VA访问，若没有相关页表，就无法访问。

被启动DMA，包括片上设备和PCIe设备，其中片上设备为芯片内部集成的硬件加速器或IO口，PCIe设备为通过PCIe接口连接的设备。设备虚拟化，也即是一个物理设备，对上层软件系统呈现为多个逻辑设备，可以被虚拟机及其进程直接使用。

在数据传输一文有描述，设备工作需要接收其余模块的配置请求，也能够访问系统内的其余模块。配置请求的上游是互联总线，使用的是PA，因此每个逻辑设备的配置空间地址是真实存在的，有多少逻辑设备，就需要在系统的物理地址内分配多少的配置空间。VMM会先将配置空间的PA转换为VA，虚拟机及其进程可使用该VA直接访问设备，MMU将该地址转换为PA再发送至互联总线。

设备直接接收虚拟机及其进程的配置请求，拿到的是VA，再使用该VA访问其余模块，必须先上互联总线，因此设备的访问出口与互联总线之间必须引入地址转换模块，将VA转换为PA。

通过扩展信号位宽来区分其地址域，设备也是采用相同的策略，只是其名称有所区别。在ARM体系中，命名为StreamID和SubstreamID；在PCIe体系中，命名为RequesterID和PASID；实际上两者是等价的。该地址转换模块就是将(StreamID + SubstreamID + VA)转换为PA，再发送至互联总线访问其余模块，该模块就是SMMU或IOMMU。

硬件系统结构模型如下，与MMU类似，SMMU也同样存在TLB，其作用是相同的，存在细节差异(注:若系统内不存在SMMU，那么设备无法直接使用VA，操作系统需要将VA转换为PA再发送至设备)。

系统基本是以CPU为核心，Device属于被启动或被调用的模块，因此从逻辑来看，每个进程可以绑定一个或多个设备Substream，但每个设备Substream只能与一个进程绑定，其逻辑关系如下图所示。

综上，在虚拟化场景下，某个进程调用Device的典型流程有如下几个步骤。

1. 进程，标记为VMID+ASID，申请Device资源，与StreamID+SubstreamID进行绑定，并获得该设备配置地址窗口的虚拟地址，同时在内存中记录进程与Device的映射关系；
2. 该进程申请Memory空间，获得其进程内的虚拟地址，并将该地址通过设备配置窗口的虚拟地址下发至Device；
3. Device再基于该虚拟地址进行读写访问，SMMU将VA转换为PA发送至互联总线。

SMMU的地址转换流程就是上述的逆过程，Arm官方文档有相关描述，下图非常清晰的描述其先后关系。MMU与SMMU非常类似，同样存在两级地址转换，根据具体场景需求可分别进行Bypass，其差别是图中的Configuration lookup流程，将StreamID + SubstreamID转换为VMID + ASID。

前面的硬件系统结构模型中，Device包含了PCIe设备，如果把PCIe设备单独拿出来，其结构如下所示。

PCIe报文的RequesterID直接映射到StreamID，PASID映射到SubstreamID，接收到报文之后，先将(RequesterID，PASID)转换为(vmid，asid)，Stage 1基于(vmid，asid)将VA转换为IPA，Stage 2基于vmid将IPA转换为PA，再发送至互联总线。PCIe PASID属于报文的Prefix，长度为1DW(32bit)，需占用32bit的链路带宽，其格式如下所示。

实际上，当前绝大部分的PCIe设备是不支持PASID，也就是SMMU无需处理Stage 1的地址转换。因此，进程应用在将VA下发至PCIe设备时，需要虚拟机将该VA转换为IPA，再下发至PCIe设备，后续SMMU接收到报文后，仅处理Stage 2的地址转换。与上述类似，两级地址转换也会基于具体场景需求进行Bypass处理。

PCIe Endpoint通过SR-IOV支持设备虚拟化，使得一个PCIe物理设备可以映射为多个逻辑设备，可以被一个或多个操作系统和进程进行调用，如下图所示。

从软件视角来看，该设备呈现为多个Device，每个Device是互相独立的。在PCIe协议内，图中的Device称为Function，每个Function都分配一个独有的16bit ID，发出读写访问请求时使用该ID作为RequesterID。注意，每个Function之间是独立的，其在系统的Memory视角，每个Function均必须有其独立的配置空间，该物理设备可以共享，但其BAR空间的分配是无法被多个Function共享的。

Root Port接收到请求后，发送至SMMU做地址转换，再发送至互联总线。这一过程中，地址转换是需要时间的，也就是SMMU使能与Bypass相比，增加了地址转换的延时。如果对应页表不在TLB内，还需要到内存进行检索，非常影响性能。另外，如果连接了较多的设备，还会有大量的转换请求，而且这些设备还会发出大量的小粒度请求(512Byte)，这些都会对SMMU和系统形成压力。

在具体实现中，使用了各种手段解决该问题，如将固定页表分配给Device使用。实际上，某些情况下，Device早已拿到访问请求的地址，只是处理任务未完成，还不能直接发出读写请求。

PCIe ATS就是用于解决该问题，将地址转换流程挪至Device侧，内部集成Address Translation Cache(ATC)，ATS协议用于维护该ATC及其相关流程。PCIe Device在发出读写请求时，将VA转换为PA再进行发送，到Host侧则不再需要进行地址转换，直接发送至互联总线。

实际上，当前的PCIe设备都不支持ATS机制，主要还有较多的问题无法解决，如安全问题，Cache维护的问题，等等。

页表维护

所有页表均保存在Memory内，若没有TLB，所有查表请求均需要在Memory进行查找。虚拟机或进程申请Memory空间时，获取到其虚拟地址，同时在Memory内建立页表，也就是VA->PA的映射关系；释放Memory空间时，则对应为删除页表关系。

为加快地址转换流程，MMU/SMMU实现了TLB，缓存了部分页表。若接收到的请求在TLB命中，直接返回转换结果，否则需要在Memory进行查找。一般来说，系统会维护多级页表，每级页表之间使用指针进行索引，在Memory查找时需要多次访问才能拿到结果，这一过程也叫Page Table Walk。

既然有Cache，那么在删除页表关系时，同时也要将TLB Cache的页表关系也一并删除，否则会造成内存踩踏。SMMU协议内定义了大量的TLB invalidation命令，较为复杂，在之前参与的项目中，使用了大量的逻辑来处理这一命令。若在PCIe设备内实现了ATC，还需要同时Invalid该Cache缓存的页表关系。

页表属性

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
中…(img-LVawxZ2H-1713590618050)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！