dbs-upcall

dbs-upcall 是基于 vsock 开发的 VMM 与虚拟机之间的直接通信工具。upcall 的服务器端在虚拟机内核中是一个驱动程序（此功能需要内核补丁），内核启动后开始服务请求。客户端位于 VMM 中，它将是一个通过 uds 与 vsock 通信的线程。

我们已通过 upcall 直接完成设备热插拔/热拔除，以避免虚拟化 ACPI，从而最小化虚拟机的开销。还有许多其他用法可以通过这个直接通信通道实现。

设计

服务器设计

upcall 的服务器端在虚拟机内核中是一个驱动程序，vsock 端口为 0xDB。vsock 连接后，将注册与 upcall 相关的服务，并创建一个提供相应服务的 kthread。upcall 服务线程将首先发送一个带有连接消息类型的消息，尝试与客户端（VMM）建立连接。服务成功连接后，服务线程将进入一个循环，连续接收来自客户端的请求并处理请求，直到服务停止。

我们目前支持的服务

1. 设备管理器：支持 CPU 热插拔/热拔除，virtio-mmio 设备热插拔/热拔除

客户端设计

客户端位于 VMM 中，我们将相关逻辑抽象到这个包 dbs-upcall 中。

客户端的 upcall 状态机：

客户端的工作流程

1. [当前状态：等待服务器] 检查与 vsock 服务器的连接。
2. [当前状态：等待服务] 检查与虚拟机内核中 upcall 服务器端的连接，以获取消息类型连接和魔数版本。
3. [当前状态：服务连接] 此状态下可以通过 upcall 发送请求。

如果步骤1和2失败，upcall将尝试重新连接。如果步骤3发送了请求，upcall状态将变为ServiceBusy，并且在此状态下upcall不会处理其他请求。

消息设计

upcall请求消息包含两个部分：消息头和消息负载。upcall回复消息包含三个部分：消息头、结果和消息负载。

消息头包含以下信息，请求和回复中保持不变

1. magic_version(u32)：用于识别upcall和服务类型的魔数版本
2. msg_size(u32)：消息负载的大小
3. msg_type(u32)：消息类型，用于识别其用途（例如ADD_CPU）
4. msg_flags(u32)：保留

对于upcall请求消息，消息负载目前包含两种msg_load。msg_load类型1：add_mmio_dev - 用于virtio-mmio热插拔/热拔插请求

1. mmio_base
2. mmio_size
3. mmio_irq

msg_load类型2：cpu_dev_info - 用于CPU热插拔/热拔插请求

1. count
2. apic_ver
3. apic_ids[256]

对于upcall回复消息，回复包含结果和两种msg_load。如果结果为0，则操作成功。如果结果不为0，则结果表示错误代码。

msg_load类型1：add_mmio_dev - 用于virtio-mmio回复：目前为空

msg_load类型2：cpu_dev_reply_info - 用于CPU热插拔/热拔插回复

1. apic_index

内核补丁

内核补丁对于dbs-upcall是必需的。您可以访问内核补丁来获取补丁。0001-dragonball-introduce-dragonball-driver.patch在/kernel中是启用upcall的先决条件。0001-upcall-add-vsock-server-and-upcall-support.patch在/kernel/upcall是启用upcall的补丁。这些补丁已经在linux内核4.19（稳定版）上进行了测试。

许可

本项目遵循Apache许可证，版本2.0。