通过为虚拟机引入 Hybrid vCPU 模型，将云计算的“可用性”带往下一个发展阶段。本文将详细介绍该技术背后的实现过程。

作者 |腾讯云 IaaS 前沿技术团队

腾讯云工程师在KVM Forum 2023会议上分享Hybrid vCPU技术

Hybrid 架构的兴起

随着云计算需求愈发多样且复杂，定制化程度日益加深。在这种大背景下，硬件供应商已经在客户端计算市场，引入了平衡功耗与性能的异构计算架构，在 CPU 体系结构中，为人津津乐道的是 ARM 指令集设计下的大小核架构。

目前，Hybrid CPU 还处于第一发展阶段(stage 1)。在该阶段，CPU 中可单独执行任务的各个计算单元（core）都是同构的，即它们拥有总体相同的指令集架构与软件交互界面，但是在微架构实现上会根据自身的设计目标与限制使用不同倾向的微架构设计。

比较常见的设计倾向是性能与功耗的平衡即在 CPU 中部分使用性能核心（P-core），部分使用能效核心（E-core），两者不同的微架构设计（包括缓存层级设计）体现出不同的IPC（instruction-per-cycle）潜力。第一阶段的Hybrid CPU在用户态应用程序视角上都是 Symmetrical multiprocessing (SMP ) ，每个计算核心在可用的指令集架构（ISA）上没有设计上的差异。但是在操作系统驱动层视角上，第一阶段的 Hybrid CPU 已经显示出了不容忽视的核心间差异。基于对目前已上市 Intel 混合架构 CPU 的观察，这些差异一方面体现在部分硬件特性在 CPUID 与 MSR 上不一致，这导致了操作系统的驱动开发人员需要针对不同的核心来初始化不同的驱动逻辑，并在用户使用差异化的硬件特性时，避免能力不一致的错误；另一方面不同 CPU 微架构在实现指令集未定义行为时存在差异，包括比特位逻辑与移动操作指令（诸如 bitwise, shifts 和 single-bit shift），这部分差异要求软件开发人员在硬件未定义行为的推测上应保持非常谨慎的处理逻辑，已确保同一任务在 Hybrid CPU 上调度保持行为一致。

目前第一阶段的 Hybrid CPU 主要来自三家硬件设计厂商。最早在 2011 年引入大小核(big. LITTLE)设计的 arm 公司，其系列主打产品 Cortex-X Custom (CXC) 处理器和它的厂商自定义芯片代表 Apple 公司的M系列处理器已经有力地说明了 Hybrid 架构在客户端市场的设计优势；10 年后由 Intel 公司推出的 12 代酷睿处理器 Alder Lake 拉开了 Hybrid 架构在 x86 指令集上的市场实践，其第一代混合产品融合基于 Golden Cove 微架构的性能核心与 Gracemont 为架构的能效核心，并进一步催生了 Windows 11 操作系统，已更好地利用差异化的计算核心。值得关注的是，AMD 公司在 Hybrid 架构上也早有布局，比如引入了在 Zen4 微架构上为数据中心高密度部署场景量身定做的 Zen4c 微架构，尽管它们在单节点上依旧以 SMP Cluster 形式存在；在客户端与边缘计算市场上，AMD 硬件规范文档已经揭示了 Family 19h Model 70h Core 的存在，其中更新的 CPU 拓扑结构将在一个字段上区分当前计算核心是性能核还是能效核，两种不同类型的核心可能存在于同一平台不同的 CCX 中，并拥有访问内存的不同物理布局。

AMD 硬件规范手册中首次出现性能核心与能效核心

Hybrid 架构第一阶段的显著特征，是能耗比差异，软件开发者仍可以期待不同核心在执行基于同一指令集的负载上没有功能性差异。

硬件架构设计者们，通常并不会满足于在 CPU 架构设计上始终保持 ISA 一致。在进一步为不同负载匹配上更合适的硬件计算资源，走出ISA的一致性或许是一个不错的尝试。这就引向了 Hybrid 架构，即在同一个 CPU 设计引入数量不同的 ISA 非对称核心。抛弃 ISA 完全一致的承诺可以带来诸多电气化好处，比如通过削减大部分不需要支持的 ISA 特性来获得足量的晶体管布局优化空间，从而获得更大的功耗节省与更低的制造成本，在硬件IP的复用上将不再保持 ISA 的一致性，进一步放开 chiplet 的组合空间。

Hybrid 架构的第二阶段已经可以在真实世界中获得初体验。比如在早期的 Intel ADL 平台上，其性能核心依旧保留着 AVX-512 指令集，即使在产品交付后期 Intel 官方禁用了这部分支持，部分主板厂商依旧允许终端用户再一次启用性能核心上的 AVX-512 支持。AMD 厂商在一份专利设计中揭示了其实现 ISA 异构处理器，即 CPU 上一部分计算核心拥有与另一部分核心不同的 ISA 特性。尽管硬件厂商在第二阶段跃跃欲试，但相关产品尚未在更广大的软件开发者中普及。

Hybrid 架构第二阶段的显著特性，是不同核心间存在 ISA 差异，软件开发者需要预期一部分负载将无法运行在一部分核心上。为了丝滑无感知的实现这一点，底层基础软件的开发者们并没有下定决心来重塑软件栈，软件生态的支持程度将会直接决定 Hybrid 第二架构产品的市场表现。

尽管软件开发者并不普遍预期支持 ISA 差异的新系统会在短期内得到大流行，但在 Hybrid 架构的推广上，芯片制造商已经迫不及待将 Hybrid 架构推进至第三阶段。在最后的第三阶段，随着 chiplet 芯片封装技术与商业生态的成熟与落地，在同一物理硅片上将同时存在 x86、ARM 与 Risc-V 的计算核心。这种大异构核心将配合硅片上其他异构计算单元（诸如 GPU、FPGA 等各类加速器），为不同负载的提供不同的硬件计算匹配方案（best-fit）。在现代 x86 芯片上，已经存在 Arm 架构的协处理器来执行大部分安全特性，尽管其编程接口仍控制在厂商手里并未完全开放。与此同时，Intel 的芯片工厂在其 IDM 2.0 战略的执行路径上，已经克服了芯片设计上的困难， 成功地让 x86、ARM 和 Risc-V 在同一芯片封装上互相连接，其战略也有可能直接授权 x86 给客户，从而帮助客户定制自己的芯片组合。

硬件设计的迭代总是昂贵和缓慢的。拥有探索精神的软件开发者们，特别是系统虚拟化的从业人员已经在 Hrbrid 方向做出了自己的尝试。在 KVM Forum 2023 技术峰会上，来自腾讯云开源团队的工程师提出了虚拟化 Hybrid 架构的想法，并分享了通过引入 Hybrid vCPU 概念进一步实现虚拟机在线控制 CPU 特性的软件探索。值得一提的是，该议题也是 2023 年度来自亚洲地区的唯一入选议题，其背后是腾讯云对开源社区与探索创新技术的长期支持。

引入Hybrid vCPU的动机

虚拟化技术的一个重要应用需求是将物理机的 CPU 能力呈现给虚拟机客户，包括在客户端计算平台上（比如笔记本或者工作站）运行的虚拟机。在 Hybrid 架构的物理 CPU 芯片上，当前的开源虚拟化软件栈并没有向这些虚拟机呈现其真实的 Hybrid 架构（它们依旧会认为虚拟机中的 vCPU 是同构的）。这样的虚拟机无法感知到真实的 CPU 拓扑信息，就像没有正确配置 NUMA 信息的负载一样，被偷偷地挪走了性能潜力。为运行在真实 Hybrid 架构 CPU 上的虚拟机呈现真实或者部分运行时真实的 Hybrid CPU 拓扑信息对提升其中负载的性能至关重要。

Intel AlderLake CPU 中不对称的缓存共享结构

一个重要的使用场景是负载对缓存的利用优化严重依赖于 CPU 拓扑与缓存共享结构，比如 AMD 最新的 CPU 芯片将拥有单硅片 1.1GB 的 L3 Cache，如何充分利用缓存是每个关键负载提升性能的课题。

在 Intel ADL 平台上，它的能耗核心之间会共享 L3 缓存，并进一步在 Cluster 范围内共享 L2 缓存，这种共享设计与其能效核心截然不同，如果虚拟机没有觉察到共享缓存带来的缓存容量竞争，将会错误地实施缓存优化策略，而且随着虚拟机负载从能效核心迁移到性能核心，同一缓存优化策略并不会带来同样的效果，而 vCPU 与 pCPU 的匹配与调度迁移并不天然地被操作系统支持，需要虚拟机管理器的介入。

在真实的 Hybrid 架构计算平台上，迫切需要使用虚拟化技术将 Hybrid 属性（包括 CPU 拓扑与缓存层级）呈现给虚拟机。拥有 Hybrid 属性的虚拟机，在特定虚拟化电源管理特性的支持下，可以充分利用 Hybrid 第一阶段的性能与功耗平衡特性，比如让调度器感知到真实的超线程启用情况、逻辑计算核心的集群总线共享情况、能耗管理与 CPU 故障，来实现更合理的虚拟机内部调度。

在虚拟化世界中实现 Hybrid vCPU，将有助于体系结构从业者们进一步探索纯软件系统模拟的乐趣。在真实硬件设计实施之前，系统设计的从业人员、研究人员与爱好者们往往会通过使用目前流行的开源虚拟化技术来实现新型体系结构的系统模拟，即用软件模拟硬件，并由硬件辅助虚拟化技术来加速。在这种使用场景中，hybrid vCPU 的引入将会让用户更方便的配置与探索不同的 CPU 混合方案，特别是缓存配置方案。利用软件的灵活性，创造尚不存在的 CPU 模型，并基于此提前探索各个软件栈的应用与收益。这种创新实践的左移思路（left shift）将加速硬件 Hybrid 特性的研发速度并降低硬件试错成本。

在云计算越发普及的当下，开发者们往往会预期自己的虚拟机实例拥有当前物理 CPU 上支持的几乎全部 CPU 特性，并渴望在云厂商升级物理 CPU 之后，能继续获得新物理 CPU 上的新 CPU 特性。物理 CPU 的升级或降级往往通过云厂商的热迁移技术来实现。一台虚拟机从 A 节点热迁移到 B 节点，其 vCPU 模型依旧会保持其在虚拟机创建时期由虚拟机管理器指定的 vCPU 模型，这个初始化 vCPU 模型会与虚拟机的生命周期绑定，也就意味着虚拟机的全部可用 CPU 特性并不会发生变化。基于不同的 vCPU 模型，云厂商会把真实的不同 CPU 能力的物理机集群们在逻辑上分成多个虚拟机池，拥有同一个 vCPU 模型的虚拟机们在同一个热迁移池的不同物理节点间热迁移。vCPU 模型的升级或者降级往往依赖于下一次虚拟机的主动或被动重启。通过严重影响虚拟机业务服务状态的方式，完成 vCPU 模型的管理。

基于 Hybrid vCPU 模型，可以将不同 vCPU 模型的虚拟机池连接在一起，并允许一个虚拟机从一个 vCPU 模型到另一个模型的在线切换，而不是在虚拟机冷启动阶段完成切换。为了更好地实现这个愿景，云厂商将首先基于一种不同代际的硬件平台都支持的通用 vCPU 模型来启动虚拟机，比如通用 x86 vCPU 模型，它与特定的 x86 厂商无关，该模型定义个各厂商都支持的 CPU 特性。基于通用 x86 vCPU 模型，可以实现将通用 x86 虚拟机从 Intel 物理机热迁移到 AMD 物理机。在这个基础的 vCPU 模型上，可以定制化地在线添加感兴趣的 CPU 新特性，新添加的 CPU 特性在当前物理 CPU 上得到支持，并在热迁移不支持该特性的新物理 CPU 之前予以删除。这显然是一种理想化的管理状态，也形成了在线控制虚拟机 CPU 特性的想法雏形。

基于通用 vCPU 模型，云计算厂商将成为另一种形式的 CPU 厂商，定制化自己 vCPU 模型的特性集合，并充分解放基于自己 vCPU 模型的热迁移限制。以往依赖于 vCPU 模型的热迁移兼容性检查将会更细粒度地依赖于具体某个 CPU 特性的兼容性检查，大大增强了虚拟机在数据中心范围内的可维护性。

通过支持 Hybrid vCPU 模型，可以在线添加或移除 vCPU 的特性。这种 CPU 特性实时被添加或删除的软件支持，可以进一步降低虚拟化软件栈（特别是KVM）的攻击面。当确定安全风险被某个 CPU 特性意外暴露之后，通过移除 vCPU 该特性及时地完成自我保护，进一步减小公有云上侧信道攻击、架构化的信息泄漏、基于功耗的性能等攻击手段的发挥空间。

Hybrid vCPU 模型还可以进一步提升数据中心范围内的 CPU 使用效率。一种场景是，运维管理员在检测到部分物理计算核心出现不可恢复的单核心故障后，会选择下线（offline）这部分逻辑 CPU，并保持其余计算核心继续工作。特性丰富、性能强劲、工艺先进的新一代物理 CPU 往往拥有更高的硬件故障率。高故障率下被下线的计算核心无疑提升了整体的计算成本与管理成本。通过对故障计算核心的充分测试，基于其硬件实施的特性，可以确定这部分有缺陷的 CPU 能正常工作的特性集合，将只使用这部分特性集合的 vCPU 调度当前部分故障的 CPU 上，可以继续使用这部分计算核心未损坏的特性，而不是一昧地实施错误隔离策略。在这种应用场景中，通过 Hybrid vCPU 限制可用的 CPU 特性，确保每个计算核心都能继续被使用，进一步提高整体资源使用效率，继续发挥云计算边际成本降低效应。

分布式应用开发者会提议直接使用基于多个不同 vCPU 模型的分布式应用架构来发挥不同 vCPU 特性的效用。但这会显著增加编程模型的复杂度，开发者可以在 Hybrid vCPU 模型上继续使用单体模型，继续共享同一份虚拟地址空间而不引入额外的 RPC 交互。通过使用 Hybrid vCPU 上的新特性，大幅提升应用性能，减小跨虚拟机的同步开销与数据搬运开销。Hybrid vCPU 方案不需要引入多个不同类型的虚拟机，从而避免保持多个虚拟机运行的重复管理动作，提升 vCPU 的利用率。

Hybrid vCPU 的虚拟化定义空间

进一步的思考是，如何改造当前的虚拟化软件栈以支持最基础的 Hyrbid vCPU 模型。限制 Hybrid 的定义空间将限制虚拟机管理器如何配置不同 vCPU 之间可以有哪些 CPU 特性是不相同的，良好的 Hybrid 定义空间可以限制上层软件的修改范围，避免出现概念落地时预期的收益无法兑现。

以 Hybrid 架构的第一阶段为例。虚拟机管理器将拥有虚拟机 CPU 拓扑结构的定义空间，vCPU 拓扑结构包括了当前可用 CPU 数量 cpus，最大可用 CPU 数量 max_cpus，CPU 类型 type，插槽数量 sockets，单插槽硅片数量 dies，计算模块数量 modules，计算集群 clusters，物理计算核心数量 cores，以及逻辑计算核心数量 threads。上述拓扑信息将由虚拟机管理器的 TopologyState 与 MachineState 存储，并在随后的虚拟机存活周期中给调整Hybrid vCPU模型给予明确的约束限制。

为了更好地将真实物理 CPU 的 Hybrid 属性呈现给虚拟机，虚拟机管理器将拥有虚拟机 CPU 处理器频率的定义空间，包括基础与最大可持续运行的 CPU 频率。作为 Hybrid 属性的一部分，缓存拓扑信息也是虚拟机管理器的可定义范围，包括向虚拟机呈现真实的缓存大小、关联方式以及缓存预取的大小，同时提供的信息也包括 TLB 信息，包括各大小页面的条目数、TLB 是否在物理逻辑 CPU 之间共享、TLB 的缓存级别等物理核心间的微架构资源差异。

对于第一阶段的Hybrid vCPU模型来说，最大的软件能感到到差别就是不同核心之间PMU特性的差异。这些差异体现在PMU各个特性上，这些差异也将出现在Hybrid vCPU的定义空间中，包括通用计数器数量、缓存事件的编码、PEBS高级特性与计数器的绑定关系、架构化LBR包含的RIP类型、处理器跟踪的RIP信息与可输出缓冲区类型、中断处理的硬件机制等。

实现上述 Hybrid vCPU 模型需要虚拟机管理器各个组件与子系统共同协作。比如 Hybrid 的 vCPU 与缓存拓扑信息主要由 QEMU 来模拟，Hybird 的 PMU 特性支持信息主要有 KVM 来模拟。KVM 还需要保证任意 Hybrid vCPU 模型一旦确定后，不再允许被更改。KVM 所在母机还需要完成最基础的调度，已确保 vCPU 与 pCPU 的特性匹配。虚拟机启动时需要的固件也将允许重设第一个被初始化的处理器 BSP，以支持虚拟机可以在启动时选择不同的 vCPU 来初始化虚拟机操作系统。

在虚拟机池中应用 Hybrid vCPU

一个虚拟机池往往会包含大量不同类型的母机，同一 vCPU 模型的虚拟机在虚拟池中可自由的迁移，该 vCPU 模型往往只具备不同类型母机所共有的 CPU 特性集合。当新母机上线时，可以选择支持某虚拟机池的 vCPU 模型，并加入该虚拟机池，也可以选择新成为虚拟机池，并启用新的 vCPU 模型，以求暴露新的 CPU 特性服务新启动的虚拟机。对于始终在线的大量虚拟机来说，完成 vCPU 模型的在线升级几乎是不可能的，在海量虚拟机运维上就会产生大量独立管理虚拟机池已适应不同的 CPU 特性诉求。

发挥 Hybrid vCPU 设计优势的绝佳场景是通过其连接多个虚拟机可迁移池。腾讯云技术团队首先引入一个最基础共享的 vCPU 模型，它的特性集合可以被任意母机所支持。通过基础 vCPU 模型，可以将虚拟机运行在全部母机上并保持全局的可热迁移性。一台在新母机上运行的虚拟机可以通过虚拟机管理器接口热插入新类型的 vCPU，并在虚拟机内部让这些新 vCPU 上线，虚拟机的操作系统需要识别新的 Hybrid 属性的 vCPU 并把它们正确初始化，呈现给潜在的应用程序。完成新 vCPU 的上线之后，就可以完成旧的 vCPU 下线，这可以继续通过虚拟机管理器的 CPU 热拔出接口来完成。通过新老 vCPU 模型的切换，新的 vCPU 特性可以被顺利暴露给虚拟机，并在虚拟机能感知的情况下供用户态程序使用。同样的机制也可以完成一个 vCPU 特性的下线，将新的 vCPU 模型逐步回退至基础共享的 vCPU 模型，迁移到另一台母机上，可以继续添加新母机上的新 CPU 特性。在这其中的虚拟机可以支持 Hybrid vCPU，即可以支持两种或两种不同类型的 vCPU，这样通过上线新类型的 vCPU，完成新 vCPU 特性的呈现，反之亦然。

通过Hybrid vCPU模型连接多个虚拟机池

无论 Hybrid vCPU 模型中不同类型的 vCPU 如何组合，都需要其遵守虚拟机管理器的拓扑结构和虚拟主板的限制，同时可插拔的数量、类型与机制均由虚拟机管理器限制，特别是需要遵守 ACPI 设备热插拔规范。其中一个例外是对虚拟机初始化 CPU，即 BSP 的热插拔支持。虚拟机管理器可以通过更新 ACPI 模拟表项中 SRAT 与 MADT 的字段，重置虚拟机的 BSP，来避免虚拟机用户潜在冷重启之后的特性丢失。实现 BSP 的热插拔需要更改虚拟机 ACPI 驱动已消除警告，在 BSP vCPU 下线之后，需要虚拟机管理器为 BSP 销毁并重新创建vCPU线程以完成CPUID与MSR的配置更新。虚拟机内部可以重新上线 BSP 或者通过 kexec() 机制重新选择 BSP。

在上述 Hybrid vCPU 的技术场景中，虚拟机内部至少有一个 vCPU 可以始终保持在线，最小程度的支持了虚拟机内部业务的在线承诺。考虑到热插拔全路径的执行难度，支持 Hybrid vCPU 的大规格虚拟机将更加收益。

实现在线控制 vPMU 特性

选择 vPMU 特性集合作为在线控制 vCPU 特性，有诸多考虑，其中一个原因是上游 Linux 社区在支持 Intel Aldlake Hybrid CPU 时已添加了较为良好的原生驱动支持：

存在已体现 Hybrid 不同 CPU 差异的数据结构；

有多套针对不同 Hybrid CPU 的驱动注册机制；

驱动刷新机制已被 CPU 热插拔流程支持，包括在 CPU 生命周期的各个阶段的注册与删除

CPU 热插拔失败时的错误处理，回退机制较为完善；

为了使用非原生支持 Hybrid CPU 的虚拟机也能支持 Hybrid PMU，需要把针对 ADL Hybrid PMU 的支持迁移到虚拟机的 vCPU 模型驱动中，这包括了少量的虚拟机内核改造：

用同一份 CPU 模型微架标记数据填充多套 Hybrid CPU 模型；

注册一份空 PMU 驱动已支持虚拟机在 vPMU 被彻底禁用时能顺利初始化（PERFMON_）；

通过 /sys/device 向用户态暴露不同 vCPU 的能力差异；

让用户态 perf 工具根据 cpu 类型差异调用相关配置；

最后，主机侧可以在线控制虚拟机 vPMU 的多个状态，比如从 vPMU 被彻底禁用到只暴露几个基础计数器，到继续暴露LBR特性，也可以实现在虚拟机内部没有潜在的特性用户时逐步删除这些特性。

不同类型的vPMU在同一虚拟机中被顺利初始化

为了帮助用户态程序能更好地利用 Hyrbid 架构的硬件属性（或者在主机侧人为构造的 Hybrid 属性），在项目中引入一个灵活的任务调度器。这个新的任务调度器需要同时支持不同 Hybrid 架构不同阶段的差异化调度，它可以同时出现母机和子机中，核心思路是基于当前任务的上下文在下一次调度决策前更新其调度上下文。它需要实现特性匹配，在主机侧需要用一种通用的方式完成 vCPU 与 pCPU 的灵活绑定，同时完成常规的任务负载均衡或其他调度目标。

其中一个差异化调度策略是基于硬件的解决方案: Intel Thread Director。它旨在根据负载运行的指令集类型将负载分为固定数量的 ISA 类型，利用不同 ISA 的类型提示调度器分配不同负载，相关内核补丁集已出现在社区中。

硬件解决方案的前提是负载需要先运行一段时间，且向前预测的兼容性非常差。一种更为通用的软件方案是基于 BPF 的可拓展调度器，其作为内核调度子系统最近几年最大的变化，可以帮助非内核开发者轻松快速地实现调度目标自定义的调度器。

在 Hybrid vCPU 项目，该调度器在任务第一次分配前会查询基于 KVM API 的多种 BPF helpers 确定 vCPU 的 CPUID 和 MSR 与 pCPU 能支持的能力完成匹配。基于 vCPU 瞬时执行上下文所需的 CPU 特性，将会让此调度器更加灵活。

在线控制任意 CPU 特性的通用改动

目前 Linux 上游社区已经支持 Hybrid CPU 第一阶段的部分特性，包括性能监控管理单元 PMU、机器错误检查 MCE 以及电源管理特性等。

在虚拟机池中落地 CPU 特性的在线控制时，那些不同虚拟机池中存在差异的 CPU 特性自然成为了腾讯云技术团队早期考察的推广目标，即此处的大部分 CPU 特性只聚焦在热迁移目的端 vCPU 模型需要添加和删除的 CPU 特性。

比如从 Intel CLX 迁移到 ICX 之后，需要删除 cdp_l3、hle、rtm、mpx 等特性，需要添加 avx512ifma, sha_ni, split_lock_detect, wbnoinvd, hwp, hwp_act_window, hwp_epp, hwp_pkg_req, avx512vbmi, umipavx512_vbmi2, gfni, vaes, vpclmulqdq, avx512_bitalg, tme、avx512_vpopcntdq, la57, rdpid, fsrm, pconfig 等特性；从 Intel ICX 迁移到 SPR 之后，需要删除 dca 等特性，需要添加 tsc_known_freq, cat_l2, cdp_l3, cdp_l2, vnmi, arch_lbr,avx_vnni, avx512_bf16, avx512_vp2intersect, avx512_fp16, amx_bf16, amx_tile,amx_int8, hfi, waitpkg, bus_lock_detect, cldemote, movdiri, movdir64b ,enqcmd, serialize, tsxldtrk, ibt 等特性。考虑到其实践价值，上述需要变化的 CPU 特性是第一批基于 Hybrid vCPU 模型实施在线控制特性的目标特性。

要实现上述大部分 CPU 特性的在线改动，需要的软件栈改动包括：

允许通过 ACPI 事件顺利切换初始化 CPU；

虚拟机启动时初始化 CPU 特性流程的清理，包括重构 SMP 的初始化逻辑、把一些 BSP 不需要的初始化特性延后至 per-CPU 初始化、将 BSP 的特性查询原语改造成 per-CPU 的特性查询等；

继续支持通过内核启动行参数解析来过滤 CPU 特性，已保持内核对可用 CPU 特性的控制承诺；

支持 per-CPU 驱动层的数据结构初始化与逻辑注册；

在 CPU 热插拔代码逻辑上完成 per-CPU 的驱动刷新；

对用户态负载来说，可以自适应的在各个 Hybrid CPU 之间完成迁移，这包括在同一二进制中包含多个 ISA 实现，并由内核态实现 ISA 匹配机制；

管理员往往会希望增加更多用户友好的控制开关来实现更加灵活地虚拟机 CPU 特性控制。相比于在启动阶段配置 CPU 特性的组合，实现在线控制要求管理员和接口设计者更深刻地确定各个 CPU 特性之间依赖关系，需要精心设计 CPU 特性的最小子集。这部分以往是 CPU 厂商的设计思考被上移到了 vCPU 厂商。

特性限制与不足之处

尽管大部分新增的 CPU 特性可以通过 Hybrid vCPU 机制被追加到虚拟机中，但是依旧存在一些暂时无法被支持的特性。分析这些不被支持的 CPU 特性，它们往往具有共同的性质。比如大部分影响全局行为的特性，它们往往依赖于 BSP 的初始化流程，在下一次新的 BSP 没有正确初始化全局生效前，它们都无法被在线控制，包括内存分段分页机制的启用、保护模式与其他非保护模式之前的切换、APIC 模式等。对于那些需要母机固件配置更新的 CPU 特性，也无法被轻松地在线控制，包括 Intel SGX、TDX 与 AMD SEV 技术族。除此之外，一些基于特定硬件架构细节来实现同步语义的软件原语也无法被在线控制，比如内存屏障的硬件依赖。

应用在 Hybrid vCPU 之间迁移任务是应该保持统一的内存视图，任何破坏这一假设的 CPU 新特性都无法被多线程应用所用，处于保守考虑这些特性也会被排除在外。由于 Hybrid vCPU 模型会在虚拟机管理器的介入下随时改变其属性特征与拓扑结构，由这部分不稳定的信息派生出的不稳定的平台签名会破坏基于稳定 CPU 模型的软件功能性，包括一些数字版权控制与验证的软件服务。

利用 Hybrid vCPU 模型来实现 CPU 特性的添加与删除，严重依赖于虚拟机内部原生的 CPU 热插拔特性，而完整的设备热插拔路径覆盖涉及当前 CPU 行为的所有子系统初始化与退出路径。在满负载的虚拟机中，复杂的使用场景将导致某个 vCPU 的热插拔流程无法再被预期的时间内顺利完成，并有概率失败触发回退机制。这部分由 Hybrid vCPU 模型引入的额外回退机制会给虚拟机引入额外的故障来源，考虑到不同的 CPU 特性对热插拔失败的原因各不相同，这将大幅提示系统调试的困难程度。

使用 Hybrid vCPU 模型可以实现热插拔新类型的 vCPU 并正确初始化，但其最大可插入的 vCPU 数量依旧由虚拟机管理器的最大拓扑结构限制。可控制的 CPU 特性也取决于虚拟机对该特性是否可以在 per-CPU 上出现或消失的操作系统级支持来限制，这部分先验知识意味着拥有旧内核的存量虚拟机无法从中受益或只能控制极小一部分的 CPU 特性。

对于控制面来说，之前管理 vCPU 模型的逻辑需要被细化到管理 vCPU 模型的各个子特性上，这需要探索很多子特性之间的依赖、子特性之间的组合来充分实践发挥真实业务价值的控制策略，在扩大特性控制自由度的同时显著提升了管理复杂度。

总结与反思

目前该项目在实现上，只支持 vPMU 相关特性的在线控制。整体还处于 POC 阶段，考虑到全栈软件的改动范围，也远未进入产品规划阶段。腾讯云技术团队的实现，探索了最小的软件栈改动：虚拟机管理器的控制面可以通过已为 Hybrid vCPU 模型改造的虚拟机热插拔一类拥有或去除某些 vPMU 特性的 vCPU，在线控制 vPMU 各项特性。

根据腾讯云技术团队的探索，从 vPMU 特性推广到大部分 CPU 特性，需要逐个击破，特别是在虚拟机内部增加针对每个vCPU特性的驱动刷新支持。

将每个基于SMP视图的CPU特性驱动转化成per-CPU驱动，是非常耗时且不具实践价值，但是如果能改造其中一部分只在本地逻辑计算核心范围内使用的特性，就可以支持比如在热迁移之后为虚拟机在线添加新指令等刚需场景。

开发者正在为上游社区添加 Hybrid 架构第一阶段而忙碌，而第二和第三阶段的上游时间点还远未成熟。特别是应用程序需要逐渐适应一个新的编程模型，即应用开发者需要提前预知各个 CPU 之间可能的 ISA 差异。ISA 差异的任意性和应用程序当下所用 ISA 的有限性，两者的冲突是 Hybrid vCPU 进一步落地的原生障碍。

管理者总是希望能在线开启有价值的特性、关闭有风险的特性，但为了实现在线控制，Hybrid vCPU 或许并不是最佳路径。如果读者中有 Hybrid CPU 和特性在线控制两个方向的开发者，希望本文能对你有所启发，并帮助你继续前行。