📚 课程目录第4章 RPMsg消息发送机制

4. RPMsg消息发送机制：从用户态write到硬件Mailbox触发的中文路径

这一章我们来啃一块硬骨头——一条消息从用户态应用写出来，到最终敲响硬件Mailbox的大门，中间到底经历了什么。我当年第一次调RPMsg驱动时，就被这条路径上的各种“隐形关卡”折腾得不轻。你想想看，用户态一个简单的write()，背后要穿越五六层软件栈，每一层都可能成为性能瓶颈或者故障点。

说白了，这条路径就是RPMsg的“生命线”。搞懂了它，你才能知道消息为什么丢了、为什么延迟高、为什么CPU占用异常。咱们今天就把这条路径拆开揉碎，一帧一帧地看。

4.1 整体路径概览：五层一跳

从用户态到硬件，我习惯把它分成五个阶段：

阶段	所在层级	核心动作	关键数据结构/函数
① 用户态写入	应用层	write(fd, buf, len)	文件描述符、iovec
② 内核VFS层	文件系统	调用驱动注册的write回调	struct file_operations
③ RPMsg核心层	RPMsg协议栈	消息分片、添加头、入队	rpmsg_send()、struct rpmsg_hdr
④ 底层传输层	Virtio/共享内存	填充vring、更新avail ring	vring、virtqueue
⑤ Mailbox触发	硬件层	写Doorbell寄存器	mailbox_send_message()

这五层缺一不可。我在项目中遇到过好几次“消息发不出去”的问题，最后定位到都是某一层断掉了——要么是VFS回调没注册，要么是vring满了没检查。

4.2 用户态write()：入口的伪装

用户态看到的write()，其实是个“障眼法”。它背后走的是字符设备驱动的标准路径：

// 用户态代码
int fd = open("/dev/rpmsg0", O_RDWR);
write(fd, "Hello RPMsg!", 12);

内核里对应的回调长这样：

static ssize_t rpmsg_chrdev_write(struct file *filp, 
                                   const char __user *buf,
                                   size_t len, loff_t *ppos)
{
    struct rpmsg_device *rpdev = filp->private_data;
    char *kbuf;
    int ret;

    // 从用户空间拷贝数据到内核空间
    kbuf = memdup_user(buf, len);
    if (IS_ERR(kbuf))
        return PTR_ERR(kbuf);

    // 调用RPMsg核心发送接口
    ret = rpmsg_send(rpdev->ept, kbuf, len);
    kfree(kbuf);
    return ret ? ret : len;
}

注意：这里有个常见的坑——memdup_user()可能因为用户态指针非法而失败。我曾经见过一个案例，应用层传了个野指针进来，驱动没做充分检查，直接导致内核Oops。所以生产代码里一定要加IS_ERR判断。

4.3 RPMsg核心层：消息的“分装车间”

进入rpmsg_send()之后，才是真正的RPMsg协议处理。这一层做的事情，我总结为三步：

分片：如果消息长度超过底层buffer大小（通常是512字节），需要拆成多个片。
加头：每个片前面加上struct rpmsg_hdr，包含源地址、目的地址、长度、标志位。
入队：把组装好的buffer交给底层传输层。

核心数据结构长这样：

struct rpmsg_hdr {
    __le32 src;     // 源端点地址
    __le32 dst;     // 目的端点地址
    __le32 len;     // 数据长度（不含头）
    __le16 flags;   // 标志位：保留/确认/分片
    __le16 reserved;
    // 后面紧跟有效载荷
} __packed;

这里有个细节：分片标志位。如果消息被分片了，第一片的flags要置位RPMSG_FIRST_FRAG，最后一片置位RPMSG_LAST_FRAG，中间片两个都不置。接收端靠这个来重组消息。

我的经验：调试分片问题时，我习惯在驱动里加一个dump打印，把每个片的flags和len打出来。有一次发现中间片的len字段算错了，导致接收端重组时内存越界。这种问题光靠看代码很难发现，必须抓现场数据。

4.4 Virtio传输层：共享内存里的“环形跑道”

RPMsg最常用的底层传输机制是Virtio。说白了，就是主核和从核之间划出一块共享内存，里面放一个环形缓冲区（vring）。发送方往环里塞buffer，接收方从环里取buffer。

发送路径上的关键步骤：

// 简化后的virtqueue_add()逻辑
int virtqueue_add(struct virtqueue *vq, struct scatterlist *sgs[],
                  unsigned int out_num, unsigned int in_num)
{
    struct vring *vr = vq->vring;
    unsigned int head, i;

    // 1. 从free list中取一个空闲描述符
    head = vr->free_head;

    // 2. 填充描述符表：地址、长度、标志
    for (i = 0; i < out_num; i++) {
        vr->desc[head + i].addr = sg_phys(sgs[i]);
        vr->desc[head + i].len = sgs[i]->length;
        vr->desc[head + i].flags = VRING_DESC_F_NEXT;
    }

    // 3. 更新avail ring，通知接收方
    vr->avail->ring[vr->avail->idx % vr->num] = head;
    virtio_wmb();  // 写屏障，保证共享内存可见性
    vr->avail->idx++;

    return 0;
}

嗯，这里要注意内存屏障。共享内存场景下，主核和从核可能跑在不同的缓存一致性域里。不加屏障的话，从核可能读到过期的avail ring数据。我见过一个性能调优案例，工程师把virtio_wmb()换成了更轻量的smp_wmb()，结果在某个ARM平台上频繁丢消息——因为那个平台的硬件自动同步只保证cache coherence，不保证store buffer的冲刷顺序。

4.5 Mailbox触发：最后一声“敲门”

数据已经放到共享内存里了，但对方还不知道。这时候就需要Mailbox来“敲门”。

Mailbox的本质就是一个寄存器写操作：

static void rpmsg_send_doorbell(struct virtio_device *vdev)
{
    struct virtio_mailbox_device *vmdev = to_virtio_mbox_dev(vdev);

    // 写Doorbell寄存器，触发接收端中断
    mailbox_send_message(vmdev->mbox_chan, DOORBELL_VALUE);
}

这个操作虽然简单，但却是整个路径上最容易被忽视的性能瓶颈。为什么？因为Mailbox的写操作通常要经过总线仲裁，延迟可能在几微秒到几十微秒不等。如果每条消息都触发一次Mailbox，高频小消息场景下，Mailbox的开销可能占到总延迟的50%以上。

    优化思路：批量发送。把多条消息攒在一起，一次Mailbox触发通知对方。RPMsg协议本身支持这种模式——只要在最后一条消息的flags里置位RPMSG_NOTIFY，中间的消息不触发中断。我在一个音频数据流项目里用了这个技巧，把Mailbox触发频率从10kHz降到了200Hz，CPU占用率直接降了30%。

4.6 完整路径流程图

下面这张图把整个路径串起来了，建议你保存下来对照着看：

4.7 常见故障点与排查思路

路径上的每个环节都可能出问题。我整理了一个故障排查表，都是实战中遇到过的：

故障现象	可能原因	排查方法
write返回-ENOMEM	vring已满，没有空闲描述符	检查vring大小配置，看接收端是否及时回收buffer
消息内容错乱	共享内存地址映射错误或缓存一致性问题	加dma_sync检查，确认物理地址是否跨核一致
接收端收不到中断	Mailbox通道未正确配置或Doorbell值不对	用示波器抓Mailbox信号线，或读Mailbox状态寄存器
性能远低于预期	每条消息都触发Mailbox，中断频率过高	启用批量发送，减少Mailbox触发次数
大消息发送失败	分片逻辑有bug，flags标志位设置错误	抓取每个分片的rpmsg_hdr，检查flags和len

避坑指南：我曾经在一个项目里遇到“消息偶尔丢失”的诡异问题。查了三天，最后发现是Virtio的avail ring索引更新顺序不对——发送端先更新了idx，再填充desc，导致接收端读到了不完整的描述符。正确的顺序应该是：先填desc，加写屏障，再更新idx。这个顺序问题在单核环境下永远不会暴露，但多核并发时就会随机出现。

4.8 小结

从用户态write到硬件Mailbox触发，这条路径看似漫长，但每一层都有明确的职责和边界。我个人建议你在调试时，从两端往中间查：先确认Mailbox能正常触发，再确认共享内存数据是否正确，最后看RPMsg协议头是否合规。这样能快速缩小问题范围。

下一层我们会深入Virtio vring的实现细节，看看共享内存里的“环形跑道”到底是怎么运作的——那里才是RPMsg性能调优的主战场。