vCPU从SMP走向Hybrid（vcs initreg）

👉腾小云导读

随着云计算需求愈发多样且复杂，定制化程度日益加深。在这种大背景下，硬件供应商已经在客户端计算市场，引入了平衡功耗与性能的异构计算架构，在 CPU 体系结构中，为人津津乐道的是 ARM 指令集设计下的大小核架构。下面我们跟着腾讯云工程师的分享，详细了解 Hybrid 架构是怎么诞生的吧。欢迎围观～

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

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

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年度来自亚洲地区的唯一入选议题，其背后是腾讯云对开源社区与探索创新技术的长期支持。

一个虚拟机池往往会包含大量不同类型的母机，同一 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 特性集合作为在线控制 vCPU 特性，有诸多考虑，其中一个原因是上游 Linux 社区在支持 Intel Aldlake Hybrid CPU 时已添加了较为良好的原声驱动支持：

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

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

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

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

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

在 Hybrid vCPU 项目，该调度器在任务第一次分配前会查询基于 KVM API 的多种 BPF helpers 确定 vCPU 的 CPUID 和 MSR 与 pCPU 能支持的能力完成匹配。基于 vCPU 瞬时执行上下文所需的 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 特性的在线改动，需要的软件栈改动包括：

管理员往往会希望增加更多用户友好的控制开关来实现更加灵活地虚拟机 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 模型的各个子特性上，这需要探索很多子特性之间的依赖、子特性之间的组合来充分实践发挥真实业务价值的控制策略，在扩大特性控制自由度的同时显著提升了管理复杂度。

关注并星标腾讯云开发者