4. 域间通信（一）：QNX IPC 基础——Message Passing、Pulse、Channel/Connection 在虚拟化中的角色
各位好，欢迎来到第四章。
前面几章我们聊了怎么把系统拆成多个域，怎么给每个域分配资源。但有个问题你肯定想到了——域之间怎么说话？
你想想看，一个系统里如果每个域都完全隔离，那跟几台独立的电脑有什么区别？虚拟化的价值在于：隔离但不孤立。安全域需要给仪表盘发车速数据，娱乐域要给安全域发用户指令，这些都需要通信。
在 QNX 的世界里，域间通信的基石就是 IPC（Inter-Process Communication）。而 IPC 的核心，说白了就是三样东西：Message Passing、Pulse、Channel/Connection。
我刚开始接触 QNX Hypervisor 时，总觉得 IPC 不就是进程间通信嘛，跟 Linux 的 socket 差不多。后来踩了几个坑才明白——QNX 的 IPC 设计哲学完全不同，它不是为了“能通”，而是为了“可靠、实时、零拷贝”。
4.1 为什么虚拟化需要 IPC？
先想一个场景：你的仪表盘域（安全关键）需要从娱乐域（非安全）获取导航信息。这两个域运行在不同的 VM 里，甚至可能跑在不同的 CPU 核心上。
直接共享内存？不安全。娱乐域崩溃了可能把仪表盘的数据也搞坏。
用网络协议栈？太重了。一个简单的车速数据，走 TCP/IP 要经过好几层封装，延迟不可控。
QNX 的 IPC 就是为这种场景设计的。它提供了一套同步、异步、带优先级的通信机制，而且 Hypervisor 层对 IPC 做了特殊优化——跨 VM 的 IPC 延迟可以做到微秒级。
核心观点：在 QNX Hypervisor 中，IPC 不仅是进程间通信，更是域间通信的默认首选方案。除非你有极致的带宽需求（比如视频流），否则优先用 IPC。
4.2 Message Passing：同步通信的基石
Message Passing 是 QNX IPC 的核心原语。它遵循一个简单的模型：发送方（Send）阻塞，直到接收方（Receive）处理完并回复（Reply）。
这个模型跟 Linux 的 socket 完全不同。Linux 的 send() 通常是非阻塞的，数据扔进内核缓冲区就返回了。但 QNX 的 MsgSend() 会一直等到对方处理完。
我的经验：刚开始用 QNX 时，我写了一个简单的客户端-服务器程序。客户端 MsgSend 之后，服务器还没启动，客户端就卡死了。后来才意识到——MsgSend 是同步阻塞的，服务器必须先 MsgReceive，客户端才能 Send 成功。
Message Passing 在虚拟化中的角色很明确：
- 安全域向非安全域请求服务：比如安全域需要读取一个文件，通过 Message Passing 发给文件系统域，等待结果返回。
- 非安全域向安全域上报数据：比如娱乐域采集到用户语音指令，通过 Message Passing 发给语音识别域。
- 跨 VM 的同步调用：Hypervisor 层会把 Message Passing 透明地桥接到另一个 VM 的进程。
代码示例：一个简单的 Message Passing 客户端-服务器
// 服务器端
int chid = ChannelCreate(0); // 创建通道
int rcvid = MsgReceive(chid, msg, sizeof(msg), NULL); // 接收消息
// 处理消息...
MsgReply(rcvid, EOK, reply, sizeof(reply)); // 回复
// 客户端
int coid = ConnectAttach(0, pid, chid, 0, 0); // 连接到服务器
MsgSend(coid, msg, sizeof(msg), reply, sizeof(reply)); // 发送并等待回复注意看：服务器必须先 ChannelCreate，客户端才能 ConnectAttach。这个顺序搞反了，客户端就会报错。我在项目中遇到过好几次这种低级错误，排查了半天才发现是启动顺序的问题。
4.3 Pulse：轻量级的异步通知
Message Passing 虽然可靠，但有个问题——它是同步的。如果服务器处理时间很长，客户端就得一直等着。这在实时系统中是不能接受的。
Pulse 就是来解决这个问题的。Pulse 是一种轻量级的异步消息，它只有 8 字节的数据负载（加上一些控制信息）。发送方发完 Pulse 就返回，不等待接收方处理。
注意：Pulse 虽然轻量，但不能保证送达。如果接收方的 Pulse 队列满了，发送方会收到一个错误码。所以 Pulse 适合用于通知、事件、中断等场景，不适合传输关键数据。
Pulse 在虚拟化中的典型用途：
- 中断通知：一个 VM 里的硬件中断，通过 Pulse 通知另一个 VM 的中断处理线程。
- 状态变化通知：比如安全域检测到车辆碰撞，通过 Pulse 通知娱乐域立即停止播放视频。
- 看门狗心跳：每个域定期发送 Pulse 给监控域，表示自己还活着。
代码示例：发送和接收 Pulse
// 发送 Pulse
struct _pulse pulse;
pulse.code = _PULSE_CODE_MINAVAIL + 1; // 自定义脉冲码
pulse.value.sival_int = 42; // 数据负载
MsgSendPulse(coid, -1, pulse.code, pulse.value);
// 接收 Pulse（在 MsgReceive 中处理）
rcvid = MsgReceive(chid, &pulse, sizeof(pulse), NULL);
if (rcvid == 0) {
// 收到的是 Pulse，不是普通消息
// pulse.code 和 pulse.value 就是数据
}这里有个细节：MsgReceive 返回 0 表示收到的是 Pulse。这个判断很重要，因为 Pulse 和普通消息共用同一个接收通道。我见过有人忘了判断 rcvid == 0，直接把 Pulse 当普通消息处理，结果数据全乱了。
4.4 Channel 和 Connection：通信的“管道”
Channel 和 Connection 是 QNX IPC 的通信基础设施。它们的关系很简单：
- Channel：服务器端创建的“接收端口”。一个进程可以创建多个 Channel，每个 Channel 有唯一的 ID。
- Connection：客户端创建的“发送连接”。一个 Connection 连接到某个 Channel，客户端通过它发送消息。
你可以把 Channel 想象成邮局的邮箱，Connection 就是你家的信箱钥匙。服务器把邮箱挂出来，客户端拿着钥匙往里投信。
| 概念 | 创建函数 | 角色 | 生命周期 |
|---|---|---|---|
| Channel | ChannelCreate() | 服务器端接收端口 | 进程退出时自动销毁 |
| Connection | ConnectAttach() | 客户端发送连接 | 可跨进程、跨 VM |
| Message | MsgSend() | 同步请求/回复 | 一次性的 |
| Pulse | MsgSendPulse() | 异步通知 | 8 字节负载 |
在虚拟化环境中，Channel 和 Connection 有一个特殊能力：跨 VM 连接。Hypervisor 会维护一个全局的命名空间，一个 VM 里的进程可以通过 ConnectAttach() 连接到另一个 VM 里的 Channel。
关键点：跨 VM 的 Connection 在 Hypervisor 层是透明的。客户端不需要知道目标进程在哪个 VM 里，只需要知道它的进程 ID 和 Channel ID。Hypervisor 会自动路由消息。
4.5 虚拟化中的 IPC 架构图
下面这张图展示了两个 VM 之间通过 IPC 通信的典型架构。我建议你仔细看看，理解 Channel、Connection、Message、Pulse 在虚拟化层是如何配合的。
4.6 实际项目中的选择策略
讲了这么多理论，你可能想问：实际项目中到底怎么选？
我根据自己的经验，总结了一个简单的决策流程：
- 需要同步请求-回复？ → 用 Message Passing。比如安全域请求一个加密计算结果。
- 需要异步通知，数据量小？ → 用 Pulse。比如状态变化、中断通知。
- 需要传输大量数据？ → 考虑 共享内存 + Pulse 同步。Pulse 用来通知数据就绪，共享内存用来传输数据。
- 需要跨 VM 通信？ → 用 ConnectAttach 跨 VM 连接，Hypervisor 自动处理路由。
避坑指南：我曾经在一个项目中，用 Pulse 传输了 100 字节的数据。结果发现 Pulse 只有 8 字节负载，剩下的数据全丢了。后来改用 Message Passing 才解决问题。记住：Pulse 不是用来传数据的，是用来发信号的。
4.7 本章小结
这一章我们聊了 QNX IPC 的三大核心概念：
- Message Passing：同步、可靠、适合请求-回复模式。
- Pulse：异步、轻量、适合通知和事件。
- Channel/Connection：通信的基础设施，支持跨 VM 透明连接。
在虚拟化环境中，这些 IPC 原语被 Hypervisor 层增强，实现了跨 VM 的零拷贝通信。下一章我们会深入聊一个更高级的话题——共享内存，看看它如何与 IPC 配合，实现高性能的域间数据传输。
嗯，今天就到这里。如果你在实际项目中遇到 IPC 相关的问题，欢迎随时交流。