Kata Containers 中的 Upcall：基于 vsock 的 VMM 与 Guest 直接通信通道及其设备热插拔实现解析

云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载Upcall是 Kata Containers 的 Dragonball 虚拟化组件VMM与 Guest 内核之间基于vsock建立的一条直接通信通道服务端是运行在 Guest 内核中的驱动需配套内核补丁客户端是 Dragonball VMM 内一个通过 UDS 与 vsock 交互的工作线程。本文以 src/dragonball/docs/upcall.md 为主线结合dbs-upcallcrate 的源码实现、Dragonball VMM 的集成代码与 Guest 内核补丁讲解 Upcall 的架构、消息协议、设备热插拔能力、客户端状态机以及从内核构建到 VMM 编译的完整启用流程帮助读者理解并复用这条轻量级 ACPI 替代方案。Upcall 是什么为轻量 VM而生的直接通信通道Upcall是运行于 VMM虚拟机监视器与 Guest客户机之间的一种直接通信工具其传输层建立在vsockvirtio vsock 协议之上。整个通道分为两端服务端Server位于 Guest 内核中的驱动需要为 Upcall 特性打入若干内核补丁。该驱动在内核启动后即开始服务请求客户端Client位于 Dragonball VMM 内是一个与vsock通过udsUnix Domain Socket通信的工作线程。从源码结构看客户端逻辑被抽象为独立的dbs-upcallcratesrc/dragonball/crates/dbs_upcall/其包描述即a direct communication tool between VMM and guest见 Cargo.toml版本为 0.3.0仅依赖log、thiserror、timerfd、dbs-utils与dbs-virtio-devices启用virtio-vsock特性。设计 Upcall 的核心动机是保持 VM 的轻量We want to keep the lightweight of the VM through the implementation of the upcall。传统 VMM 为了支持设备热插拔需要虚拟化 ACPI 子系统这会给虚拟机引入额外开销而 Upcall 通过一条精简的直接通信通道完成同样的热插拔/热卸载操作从而尽可能压低虚拟机的资源占用与复杂度。Upcall 能做什么设备管理器服务与热插拔能力在 Upcall 通道上Dragonball 定义并实现了设备管理器服务Device Manager Service——它是当前已实现的 Upcall 服务之一。借助该服务VMM 可以直接完成以下设备热插拔 / 热卸载操作vCPU 热插拔 / 热卸载hotplug / hot-unplugvirtio-mmio 设备热插拔 / 热卸载内存热插拔文档明确提及协议层亦定义了相应操作码此外dbs-upcall的补丁集中还包含PCI 设备热插拔 / 热卸载支持见后文补丁 0008选择直接通过 Upcall 完成设备热插拔的根本原因是为了避免对 ACPI 的虚拟化从而最小化虚拟机开销。从 dev_mgr_service.rs 中可以看到协议层为设备管理器定义了完整的操作码集合DevMgrMsgType#[repr(u32)]操作码数值含义Connect0x00000000连接握手AddCpu0x00000001vCPU 热插拔DelCpu0x00000002vCPU 热卸载AddMem0x00000003内存热插拔DelMem0x00000004内存热卸载AddMmio0x00000005virtio-mmio 设备热插拔DelMmio0x00000006virtio-mmio 设备热卸载AddPci0x00000007PCI 设备热插拔DelPci0x00000008PCI 设备热卸载客户端侧的请求类型DevMgrRequest与之一一对应包含AddMmioDev/DelMmioDev/AddVcpu/DelVcpu/AddPciDev/DelPciDev六种并在DevMgrRequest::build()中负责把客户端表示序列化为服务端期望的二进制消息。架构设计服务端驱动与客户端状态机服务端设计Guest 内核驱动Upcall 的服务端是 Guest 内核中的一个驱动其vsock端口固定为0xDB219。vsock连接建立后Upcall 相关的服务会被注册并创建对应的内核线程提供服务。该服务线程的启动流程为首先发送一条msg_type为Connect的消息尝试与客户端VMM握手连接服务连接成功后进入循环持续接收来自客户端的请求并处理直到服务停止。当前支持的服务即设备管理器支持 CPU 热插拔/热卸载、virtio-mmio 设备热插拔/热卸载并可扩展 PCI 等。客户端设计VMM 侧客户端位于 VMM 内相关逻辑被抽象进dbs-upcallcrate。客户端以事件驱动 状态机的方式工作其工作流程如下[WaitingServer状态]校验与 vsock server 的连接[WaitingService状态]与 Guest 内核中的 upcall 服务端校验Connect消息类型与 magic version[ServiceConnected状态]此时可以正常通过 Upcall 发送请求。若第 1、2 步失败Upcall 会尝试重连若在第 3 步发出请求状态切换为ServiceBusy此状态下 Upcall 不再处理其他请求保证同一时刻只有一个请求在途。对应源码 lib.rs 中定义了完整的UpcallClientState枚举WaitingServer服务端连接已断开等待重连或连接请求已发出等待服务端响应WaitingService服务连接请求已发出等待服务响应ServiceConnectedUpcall 服务已连接可发送请求ServiceBusy请求已发出但响应未回通道繁忙ReconnectError无法通过简单重连恢复的错误态。客户端核心是UpcallClientS泛型参数S: UpcallClientService通过epoll_manager注册UpcallEpollHandler事件处理器来驱动状态流转。UpcallClientServicetrait 定义了四个关键回调lib.rsconnection_start发起服务连接connection_check校验服务连接结果send_request发送请求handle_response处理响应。DevMgrServicedev_mgr_service.rs正是该 trait 的设备管理器实现。连接与重连机制从源码中可以看到客户端连接与重连的具体参数lib.rs服务端口SERVER_PORT 0xDB连接服务端时首先写入CONNECT 0xDB\n命令并等待服务端返回以OK开头的响应校验buffer[0..2] [bO, bK]重连间隔SERVER_RECONNECT_DURATION_MS 1010 毫秒的一次性定时器最大重连次数SERVER_MAX_RECONNECT_TIME 500超过后进入ReconnectError状态并停止重连。当检测到连接异常时UpcallEpollHandler::set_reconnect()会先移除旧 stream 的 fd、丢弃旧连接并向回调投递UpcallClientResponse::UpcallReset随后通过timerfd定时触发重连handle_reconnect_event中重新发起server_connection_start并重新注册 epoll 事件。消息设计请求与回复的二进制协议Upcall 的消息分为两部分结构请求消息消息头message header 消息载荷message load回复消息消息头 结果result 消息载荷。消息头Message Header请求与回复共用相同结构的消息头DevMgrMsgHeader#[repr(C)]共 16 字节包含四个u32字段字段类型说明magic_versionu32标识 Upcall 及其服务类型的魔数版本msg_sizeu32消息载荷的大小msg_typeu32消息类型标识用途如 ADD_CPUmsg_flagsu32保留字段设备管理器消息的魔数版本为DEV_MGR_MAGIC_VERSION 0x444D0100单条消息的固定缓冲大小为DEV_MGR_MSG_SIZE 0x4001024 字节服务连接握手时客户端先发送单字节bdDEV_MGR_BYTE服务端随后回送一条msg_type Connect且msg_size 0、msg_flags 0、magic 匹配的消息完成校验。请求载荷msg_load当前请求载荷包含两类类型 1add_mmio_devvirtio-mmio 热插拔 / 热卸载——对应结构体MmioDevRequestmmio_baseu64virtio MMIO 配置窗口的基地址mmio_sizeu64virtio MMIO 配置窗口的大小mmio_irqu32分配给该 MMIO virtio 设备的中断号。类型 2cpu_dev_infoCPU 热插拔 / 热卸载——对应结构体CpuDevRequestcountu8热插拔 / 热卸载的 CPU 数量apic_veru8x86_64APIC 版本apic_ids[256]u8 数组x86_64APIC ID 数组。注aarch64 架构下CpuDevRequest仅携带count字段apic_ver/apic_ids通过#[cfg(target_arch ...)]条件编译。另外 PCI 热插拔请求结构体PciDevRequest包含busnoPCI 总线号与devfn设备号与功能号的组合两个字段均为 u8。回复载荷Upcall 回复消息中result字段为 i32result 0表示操作成功非 0 表示错误码。回复载荷也有两类virtio-mmio 热插拔回复当前为空cpu_dev_reply_infoCPU 热插拔 / 热卸载回复x86_64 下为apic_index最后激活 CPU 的 APIC ID 索引即CpuDevResponse.apic_id_indexaarch64 下为cpu_id。客户端侧的回复类型DevMgrResponse通过DevMgrResponse::make()解析根据msg_type区分AddMmioDev(DevMgrResponseInfo())、CpuDev(DevMgrResponseInfoCpuDevResponse)与Other(DevMgrResponseInfo())三类其中DevMgrResponseInfoI由result和附加信息info组成。VMM 集成从编译特性到热插拔调用链编译开关dbs-upcall在 Dragonball 中是可选依赖根 Cargo.toml 声明dbs-upcall { optional true, workspace true }并定义了hotplug [virtio-vsock]特性。也就是说Dragonball 以dbs-upcall特性编译时才会启用客户端侧实现Dragonball compiled withdbs-upcallfeature will enable Dragonball client side。初始化与使用VMM 侧的集成点集中在 src/dragonball/src/vm/mod.rs#[cfg(feature hotplug)]与#[cfg(feature dbs-upcall)]门控new_upcall()从device_manager获取 vsock 内部连接器get_vsock_inner_connector()以DevMgrService::default()为服务构建UpcallClient并connect()将实例以ArcUpcallClientDevMgrService存入upcall_client字段init_upcall()初始化 Upcall 客户端并把通道设置给vcpu_managerset_upcall_channelcreate_device_hotplug_context()在upcall_client存在且is_upcall_client_ready()状态为ServiceConnected时创建设备热插拔上下文。热插拔调用链vCPU 热插拔在 vcpu_manager.rs 的do_add_vcpu/do_del_vcpu中先计算待增/删的 CPU ID 列表填充CpuDevRequestcount、apic_ids数组、apic_ver APIC_VERSION构造DevMgrRequest::AddVcpu / DelVcpu再通过send_upcall_action(upcall_client, req)发出。热卸载时会校验vcpu_count 0不允许移除 vCPU 0以及可移除 CPU 数量是否充足LackRemovableVcpus设备热插拔在 device_manager/mod.rs 中统一封装了send_request/send_request_without_result分别对应带回调与丢弃响应两种发送方式blk 设备blk_dev_mgr.rs与 vfio 设备vfio_dev_mgr/mod.rs在回调中匹配UpcallClientResponse::DevMgr(response)处理结果UpcallReset则表示连接重置。如何启用 Upcall内核补丁与构建步骤Upcall 需要 Guest 内核中同时存在Upcall 服务端驱动与各服务的内核补丁其客户端位于 VMM。Kata 已将 Guest 侧补丁开源在 tools/packaging/kernel/patches/5.10.x/dragonball-experimental 目录下共包含 8 个补丁补丁文件作用0001-upcall-establish-upcall-server.patch建立 upcall 服务端驱动0002-upcall-introduce-device-manager-upcall-service.patch引入设备管理器 upcall 服务0003-upcall-add-cpu-hotplug-hot-unplug-into-device-manage.patch为设备管理器增加 CPU 热插拔/热卸载0004-upcall-add-virtio-mmio-hotplug-hot-unplug-into-devic.patch为设备管理器增加 virtio-mmio 热插拔/热卸载0005-upcall-dragonball-devmgr-suppots-cpu-hotplug-on-arm6.patch设备管理器在 arm64 上的 CPU 热插拔支持0006-msi-control-msi-irq-number-activated.patchMSI 中断号控制0007-smp-update-bringup_nonboot_cpus-parameters.patch更新bringup_nonboot_cpus参数0008-upcall-add-pci-hotplug-hot-unplug-support.patch增加 PCI 热插拔/热卸载支持Kata 同时在 Guest 内核构建脚本 tools/packaging/kernel/build-kernel.sh 中集成了 Upcall 支持。下载上游内核并把 Upcall 补丁与其他 Kata 补丁打入内核代码可执行sh build-kernel.sh -e -t dragonball -f setup各参数含义如下-e启用实验性内核experimental。之所以标记为实验性是因为Upcall 补丁尚未合入上游 Linux 内核-t dragonball指定 hypervisor 类型为 dragonball-f生成.config配置文件。执行后带 Upcall 补丁的内核代码及对应的.config会就绪于目录kata-linux-dragonball-experimental-kernel 版本-config 版本中。之后可以选择手动执行make编译内核或参考 tools/packaging/kernel/README.md 中 build-kernel.sh 的完整文档来完成 Guest 内核的构建与使用。关于内核版本需要说明两点以帮助读者对齐环境原文档src/dragonball/docs/upcall.md写作时Upcall 在上游 Linux 内核 5.10上完成测试Dragonball 当时使用 5.10.25补丁目录也以5.10.x命名当前仓库的 versions.yaml 中kernel-dragonball-experimental的版本已更新为v6.18.52且 build-kernel.sh 中有注释说明dragonball-experimental kernel patches are only tested on 6.18.x kernel now, other kernel version may cause confliction当前仅在 6.18.x 内核上测试其他内核版本可能冲突。因此实际构建时应以脚本所选的kernel-dragonball-experimental版本为准。VMM 客户端侧的启用同样简单以dbs-upcall特性编译 Dragonball例如启用hotplug特性组合即可。测试与验证客户端行为的源码级证据dbs-upcallcrate 内置了较完整的单元测试位于 lib.rs 与 dev_mgr_service.rs 的mod tests中可以作为理解客户端行为的直接证据test_upcall_client_info_server_connection_start_and_check验证客户端写入CONNECT 0xDB\n命令服务端回ERR时连接校验失败、回OK 1024\n时成功test_upcall_client_info_service_connection验证服务连接发送CONN START、连接校验读取CONN CHECKtest_upcall_client_info_request_and_response验证请求TEST REQ与响应TEST RESP的往返test_dev_mgr_service_connection_start验证设备管理器连接握手发送单字节bdtest_build_dev_mgr_request/test_make_dev_mgr_response验证DevMgrRequest::build()序列化出的消息头magic_version、msg_size、msg_type与载荷内容以及DevMgrResponse::make()对 CPU / MMIO / 未知消息类型的解析test_upcall_epoll_handler_set_reconnect验证重连定时器为 10ms 量级的一次性定时、重连计数递增。局限与展望实验性特性Upcall 补丁尚未合入上游 Linux 内核因此始终依赖 Kata 维护的 experimental 内核构建路径且内核版本升级需要与补丁集保持同步当前以kernel-dragonball-experimental对应版本为准面向轻量场景Upcall 是避开 ACPI 虚拟化、以直接通信替代的设计取舍其收益主要体现在 VM 开销的最小化从协议看AddMem/DelMem操作码与 PCI 热插拔已在消息层就绪为后续扩展内存热插拔与更多服务保留了空间there could be many other uses if other services are implemented单请求在途模型客户端通过ServiceBusy状态保证同一时刻只处理一个请求适合热插拔这类低频操作而非高吞吐控制面。如需深入源码建议继续阅读dbs-upcall客户端实现 src/dragonball/crates/dbs_upcall/src/lib.rs、设备管理器服务 src/dragonball/crates/dbs_upcall/src/dev_mgr_service.rs、VMM 初始化与热插拔上下文 src/dragonball/src/vm/mod.rs、设备热插拔统一入口 src/dragonball/src/device_manager/mod.rs以及 Guest 侧补丁集 tools/packaging/kernel/patches/5.10.x/dragonball-experimental。赞分享云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载相关推荐Kata Containers 中 dbs-upcall 详解基于 VSOCK 的 VMM 与 Guest 直连热插拔通道Kata Containers 中 dbs upcall 详解基于 VSOCK 的 VMM 与 Guest 直连热插拔通道 dbs upcall 是 Drag云原生容器运行时Kata Containers终极指南GPU直通、设备热插拔与内存管理高级功能详解Kata Containers终极指南GPU直通、设备热插拔与内存管理高级功能详解 Kata Containers作为开源的轻量级虚拟机容器运行时完美结合了云原生容器运行时Kata Containers 中的 VSOCK 机制VM 与宿主机间 Agent 通信的设计与实现Kata Containers 中的 VSOCK 机制VM 与宿主机间 Agent 通信的设计与实现 Kata Containers 中虚拟机内的 kata云原生容器运行时创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考