RPMsg核心数据结构：从设备到虚拟队列的完整链路

说实话，RPMsg协议栈的数据结构，是理解整个通信机制的地基。我刚开始接触RPMsg时，光看头文件里的结构体定义，感觉像在看天书。后来在项目中调试一个内存泄漏问题，才真正把这些结构体之间的关系摸透了。

今天我们就来拆解四个核心结构体：rpmsg_device、rpmsg_endpoint、virtqueue和vring。它们之间的关系，说白了就是一条从「通信节点」到「物理内存」的完整链路。

2.1 rpmsg_device：通信节点的抽象

rpmsg_device代表一个RPMsg通信节点。在Linux内核中，它通常对应一个远程处理器（比如Cortex-M核或DSP）。

来看它的核心定义（简化版）：

struct rpmsg_device {
    struct device dev;          // 内核设备模型
    struct rpmsg_endpoint *ept; // 默认端点
    struct rpmsg_driver *drv;   // 绑定的驱动
    bool announce;              // 是否主动通知远端
    bool little_endian;         // 字节序
    unsigned int src;           // 源地址
    unsigned int dst;           // 目的地址
};

这里有个关键点：src和dst是地址，不是物理地址，而是RPMsg协议层的逻辑地址。我在项目中遇到过一个问题：两个核通信时，地址配反了，结果消息发出去就石沉大海。排查了半天才发现是src和dst搞混了。

2.2 rpmsg_endpoint：消息收发的「窗口」

rpmsg_endpoint是真正收发消息的实体。每个端点绑定一个回调函数，当消息到达时，内核会调用这个回调。

struct rpmsg_endpoint {
    struct rpmsg_device *rpdev;  // 所属设备
    struct rpmsg_channel_info info; // 通道信息
    rpmsg_rx_cb_t cb;            // 接收回调
    void *priv;                  // 私有数据
    unsigned int addr;           // 端点地址
    spinlock_t lock;             // 自旋锁
};

为什么需要端点？你想想看，一个远程处理器可能同时处理多个服务——比如一个负责音频，一个负责传感器数据。如果只有一个通信通道，那所有消息都混在一起，根本没法区分。端点就是用来做多路复用的。

我记得有一次调试，发现某个端点的回调函数一直没被调用。查了半天，原来是addr字段没有正确初始化。RPMsg协议规定，端点的地址必须唯一，而且要与远端协商一致。

2.3 virtqueue：虚拟队列的抽象

virtqueue是virtio规范中的核心概念。它本质上是一个「消息队列」，负责管理缓冲区的入队和出队。

在RPMsg中，通常有两个virtqueue：一个用于发送（tx），一个用于接收（rx）。

struct virtqueue {
    struct list_head list;       // 链表节点
    struct vring vring;          // 底层环形缓冲区
    unsigned int num_free;       // 空闲描述符数
    void *priv;                  // 私有数据
    bool (*notify)(struct virtqueue *vq); // 通知函数
    const char *name;            // 队列名称
};

这里最核心的是vring字段——它指向实际的环形缓冲区。而notify函数指针，用于通知远端处理器有新消息到达。不同平台的通知机制不一样：ARM平台可能用IPI（核间中断），而RISC-V平台可能用MSI。

2.4 vring：共享内存的环形缓冲区

vring是virtqueue的底层实现，它直接操作共享内存。说白了，就是一块环形缓冲区，主核和从核都能读写。

vring由三部分组成：

组件	作用	注意事项
描述符表（desc）	存储缓冲区的地址和长度	每个描述符指向一段物理内存
可用环（avail）	记录哪些描述符可供使用	由驱动端写入，设备端读取
已用环（used）	记录哪些描述符已被处理	由设备端写入，驱动端读取

vring的结构体定义如下：

struct vring {
    unsigned int num;            // 描述符数量
    struct vring_desc *desc;     // 描述符表
    struct vring_avail *avail;   // 可用环
    struct vring_used *used;     // 已用环
};

这里num字段决定了队列的深度。我建议至少设置为256，否则在高吞吐场景下容易丢包。我曾经在一个音频流项目中，把num设为64，结果播放时频繁卡顿。后来改成512，问题就解决了。

2.5 四者关系：一张图看懂

下面这张SVG图，展示了从rpmsg_device到vring的完整链路：

2.6 数据结构间的交互流程

理解了四个结构体后，我们来看一次完整的消息收发流程：

1. 发送消息：应用层调用rpmsg_send()，传入rpmsg_endpoint指针。
2. 入队：内核将消息数据放入vring的描述符表中，更新可用环的idx。
3. 通知：调用virtqueue的notify函数，触发核间中断。
4. 远端处理：远端处理器收到中断，从vring的已用环中取出描述符，读取数据。
5. 回调：远端调用rpmsg_endpoint的cb回调函数，处理消息。

接收流程正好相反：远端写入vring，主核读取并调用回调。

2.7 常见问题与调试方法

问题现象	可能原因	排查方法
消息发送失败	virtqueue已满（num_free为0）	检查vring的num值，增大队列深度
回调函数未触发	端点地址不匹配	打印rpmsg_endpoint的addr字段
数据错乱	字节序不一致	检查rpmsg_device的little_endian字段
死锁	回调函数中调用了发送函数	确保回调函数不阻塞，使用工作队列

嗯，这里要特别强调一下死锁问题。我曾经在回调函数里直接调用rpmsg_send()，结果因为自旋锁被重复获取，系统直接hang住。后来改成用workqueue异步发送，问题就解决了。