ZVM技术解读·内核篇③｜1V1静态绑核
1V1静态绑核是指在客户OS（Guest）运行前，为Guest的每个虚拟CPU（vCPU）绑定一个指定的物理CPU（pCPU），并在Guest运行期间保持这一绑定关系不变。每个vCPU只在自己的pCPU上执行，不参与pCPU之间的调度，也不与其他vCPU共享同一个pCPU。
01 哪些Hypervisor采用静态CPU绑定
不同Hypervisor对CPU资源的组织方式并不相同。KVM和Xen中vCPU在运行时作为可调度实体参与调度，无法支持1V1静态绑核。Jailhouse、Bao和ZVM则采用静态CPU组织方式，在Guest运行前确定vCPU与CPU映射关系，运行时不再进行vCPU调度。其中，Jailhouse以Cell为单位划分pCPU，Bao在启动阶段为Guest静态分配固定pCPU，ZVM进一步建立vCPU与pCPU的1V1静态绑定。
表1. 主流Hypervisor的pCPU资源组织方式
| Hypervisor | 是否支持静态绑定 | vCPU是否参与调度 | 1V1管理者 |
|---|---|---|---|
| KVM | 否 | 是 | Linux Host |
| Xen | 否 | 是 | Xen |
| Jailhouse | 是 | 否 | Linux Root Cell |
| Bao | 是 | 否 | 无 |
| ZVM | 是 | 否 | ZVM |
ZVM采用vCPU与pCPU的1V1静态绑定技术，一方面避免vCPU在不同pCPU之间调度带来的运行时干扰，另一方面提供运行时灵活的1V1静态绑核能力。
- 1 支持绑定任意核心：可根据Guest配置和硬件资源布局，将vCPU绑定到指定的任意pCPU，不要求按照固定编号或连续pCPU进行分配。
- 2 支持绑定多个核心：单个Guest可配置多个vCPU，并分别绑定多个独立pCPU，从而根据Guest计算需求灵活扩展其pCPU资源。
- 3 支持ZVM运行时资源管理：vCPU-pCPU绑定关系无需完全固化在ZVM启动阶段，可在创建Guest和vCPU时再确定目标pCPU，并支持删除Guest后回收pCPU资源。
图1. ZVM的1V1静态绑核
02 Jailhouse、Bao与ZVM的1V1管理者组织方式
Jailhouse、Bao和ZVM都采用静态CPU资源组织方式，但三者在1V1管理者的组织方式上存在不同。Jailhouse依托Linux Root Cell承担绑核管理；Bao采用纯静态分区设计，不设置独立1V1管理者；ZVM自身作为1V1管理者，不依赖Linux等管理OS完成绑核。
- 1 Jailhouse：Linux Root Cell作为1V1管理者，负责启动Jailhouse并在运行时承担核心管理功能。Root Cell需要保留独立的CPU、内存及设备资源，用于Non-root Cell的创建、启动和停止。因此，Jailhouse虽然能够提供运行时绑核能力，但其1V1管理者与Linux绑定，系统运行期间需要保留完整的Linux Root Cell。
- 2 Bao：采用无1V1管理者配置，在Hypervisor启动阶段按照预先配置完成CPU、内存和设备等资源划分，各Guest随后直接使用已经分配的pCPU资源运行，但Guest资源须在启动阶段确定，且运行时无法更改。
- 3 ZVM：自身为独立1V1管理者且不依赖Guest，ZVM首先预留一个独立pCPU，用于执行Guest管理和外设管理等ZVM内核线程；其余pCPU分别分配给不同vCPU。ZVM控制管理功能运行在独立pCPU上，Guest的vCPU静态绑定到其他pCPU。ZVM不是为了静态分区而静态分区，而是在保留完整虚拟化、Guest运行和外设共享能力的情况下，通过1V1静态绑核消除CPU层面的运行时竞争。
图2. Jailhouse、Bao与ZVM的1V1管理者组织方式
从1V1管理者设计来看，三种方案形成了明显不同的组织方式：Jailhouse的1V1管理者为Linux Root Cell中，管理能力依赖Linux Guest；Bao没有独立1V1管理者，不具备运行时核心绑定能力；ZVM则将管理功能集中在独占的pCPU上，实现不依赖Guest的运行时管理能力。
表2. Jailhouse、Bao与ZVM的1V1管理者对比
| 对比项 | Jailhouse | Bao | ZVM |
|---|---|---|---|
| 1V1管理者类型 | Linux Root Cell | 无 | ZVM自身 |
| 是否依赖Guest | 是 | 否 | 否 |
| 是否具备1V1运行时管理能力 | 是 | 否 | 是 |
03 例子：Jailhouse、Bao与ZVM的pCPU资源配置流程对比
三种方案在运行时1V1绑核管理流程上存在明显差异。我们以给Guest分配pCPU资源这一操作为例，对比三者管理路径的不同。
- 1 Jailhouse：依赖Linux Root Cell完成绑核管理。管理请求首先由Linux Root Cell发起，Root Cell调用Jailhouse完成Cell创建和资源配置，随后将指定pCPU分配给目标Non-root Cell。因此，Jailhouse的绑核管理能力依赖Linux Root Cell，承担运行期管理职责。
- 2 Bao：通过修改静态配置完成绑核管理。Bao采用静态配置方式管理pCPU资源，Guest与pCPU的对应关系在启动阶段由配置文件确定。当需要调整vCPU-pCPU绑定关系时，需要修改配置文件并重新启动Bao。因此，Bao缺乏运行时绑核管理的能力。
- 3 ZVM：请求直接由ZVM接管，并在自身独占的pCPU上实现绑核管理功能。ZVM根据Guest配置创建vCPU，并将对应的vCPU绑定给pCPU，形成固定的vCPU-pCPU 1V1绑定关系。该过程不依赖Linux等管理OS即可实现运行时绑定核管理。
图3. Jailhouse、Bao与ZVM的分配pCPU流程对比
04 总结
Jailhouse、Bao和ZVM在pCPU绑核管理上采用了不同设计。Jailhouse将管理功能交由Linux Root Cell承担，资源管理请求需要经过Root Cell路径完成；Bao取消独立1V1管理者，资源绑定关系通过启动前配置确定，缺少运行运行时的管理能力；ZVM则自身承载资源管理功能，管理请求直接由ZVM处理，不依赖Linux等外部管理OS。ZVM的1V1静态绑核并非简单设置CPU亲和性，而是在Guest启动前建立固定的vCPU–pCPU资源关系，并在运行期间保持不变。结合ZVM独立控制管理、外设共享与虚拟化服务，实现CPU确定性与多OS协同运行的统一。