一颗SoC里同时住着Cortex-A和Cortex-M两种核心A核上跑着Linux负责网络和用户交互M核上跑着裸机或RTOS负责实时采集与控制。选型时人人都会说异构多核香可真到了联调阶段第一个卡住你的问题往往不是算力不够而是A核上的应用到底怎么把数据交给M核M核算完的结果又怎么送回来这个问题就是AMP架构下的核间通信IPC要解决的核心问题。本文要讲的是其中应用最广的一套组合拳——共享内存 RPMSG协议。它不是某个芯片厂商的私有方案而是OpenAMP框架所定义、在STM32MP1、i.MX8M Plus、Zynq UltraScale MPSoC等主流异构SoC上都能见到的标准做法。我写这篇文章的缘由很直接网上关于AMP核间通信的资料不少但大多数要么只讲概念图要么只贴一堆设备树配置真正把为什么要这么设计讲透的很少。而这类问题恰恰是新手最容易卡住的地方。本文会从AMP架构本身的特殊性出发依次讲清楚共享内存该怎么划分、cache一致性为什么是头号大坑、RPMSG在共享内存上是怎么组织消息的最后结合OpenAMP给我实际调过的一组数据和踩坑经验。无论你用的是哪家芯片这套原理都是通用的。1. AMP架构为何绕不开核间通信——先搞清楚三种多核路线的区别1.1 SMP、AMP、BMP你面对的是哪种异构很多刚接触异构多核的人会把多核等同于SMP对称多处理这是第一个认知偏差。SMP是指多个核心运行同一个操作系统共享同一份内存映射Linux调度器把线程均衡地分配到各个核上。在这种模式下核间通信对应用开发者几乎是透明的因为操作系统已经把所有共享资源的竞争问题都接管了你根本不需要自己设计跨核数据通路。AMP非对称多处理则完全不同。它的核心特征是每个核或每簇核运行各自独立的操作系统或裸机程序彼此拥有独立的内存映射、独立的中断控制器视图、甚至独立的运行库。以Cortex-A Cortex-M组合为例A核跑LinuxM核跑裸机或FreeRTOS两边各有各的启动流程和内存布局。它们之间唯一的物理连接是芯片内部的互联总线以及那颗共享的DDR控制器。这种架构的好处是实时性和通用性可以兼得坏处是——一切跨核协作机制都得自己动手搭。BMPBound Multi-Processing绑定多处理是Linux内核社区的一种扩展思路允许同一操作系统将任务绑定到指定核心介于SMP和AMP之间。它不是本文的主角但理解它的存在有助于你分辨很多标称AMP的SoC在Linux侧其实是用BMP方式把任务钉在某个核上跑而不是真正让每个核运行独立OS。1.2 异构核之间真正缺的是什么明确了AMP的定义你会发现问题其实很具体。A核上的Linux进程想知道M核上的传感器数据至少需要三样东西一块两边都能访问的存储空间用来放数据。DDR是天然候选但要确保这块物理内存在两边的地址映射里都存在并且不被Linux或RTOS的内存管理当成普通堆内存乱分配。一条能打断对方的通知通道用来告诉对方数据来了或缓冲空了。在嵌入式SoC上这通常由硬件中断完成有时也叫门铃doorbell。一份双方都认的数据组织格式用来规定消息边界、通道标识、长度等元信息。否则两边只是看到一堆原始字节根本不知道该从哪个偏移读、读多长。三者缺一不可。很多人一开始只解决第一项直接在共享内存里摆几个全局变量让两边读写结果要么数据被对方中途踩掉要么长期运行后内存越界谁也说不清。原因就是没有一套协议级的约束。1.3 核间通信必须解决的四个基础问题把需求抽象一下任何核间通信方案本质上都要解决四个问题数据放哪——共享内存的物理位置、大小、对齐方式。怎么通知——通过中断、轮询还是硬件事件触发。怎么保证一致——cache一致性、内存屏障、原子操作。用什么语义传输——是裸字节流、消息包还是远程函数调用。RPMSG方案对这四件事都有明确的答案数据放在预先划分的共享内存区通知靠中断或轮询可配置一致性靠内存属性和屏障指令管理传输语义是面向消息的通道模型。后面的章节我逐一展开。2. 共享内存设计的门道划分、cache一致性与门铃2.1 为什么共享内存是AMP通信的必然选择理论上两个核心之间可以通过专用硬件Mailbox交换短消息也可以通过总线互联直接访问对方的外设寄存器。但在实际AMP产品中需要跨核搬运的数据量通常远大于Mailbox能承载的几十字节。比如M核采集的一帧音频、一帧图像动辄几KB甚至几MB靠Mailbox逐包送是完全不现实的。共享内存的优势在于DDR控制器在物理上同时挂在所有核心面前任何核访问同一物理地址时硬件天然就是彼此可见的。你要做的只是把这段地址用好。用生活类比来说共享内存相当于两间办公室中间的一块公共白板两边都看得见、摸得着。而Mailbox则像两部对讲机——传个开会了来一下很方便但想传一份完整文档就太费劲了。RPMSG的哲学是对讲机只用来喊一嗓子白板上有新内容真正的文档内容写在公共白板上。2.2 物理地址规划与MPU/MMU配置无论哪家SoC共享内存的第一步都是在物理地址空间里划出一块专有区域。划的时候要避开两边的程序代码、堆栈、外设寄存器还要考虑cache line对齐和访问效率。以一颗典型的Cortex-A Cortex-M SoC为例假设DDR起始地址为0x80000000总大小512MB。常见的做法是从DDR里划出最顶部或特定位置的2MB作为共享内存池A核侧在设备树里用reserved-memory声明reserved-memory { #address-cells 2; #size-cells 2; ranges; rpmsg_reserved: rpmsg80000000 { compatible shared-dma-pool; reg 0x0 0x80000000 0x0 0x200000; no-map; }; };no-map是关键它的意思是这段内存不被Linux的页表映射为常规内存也不进入伙伴系统。没有它Linux可能会把这2MB分配给某个进程导致共享区数据被悄悄篡改。M核侧的处理方式因SoC而异。如果M核使用MPU通常把这段地址区域配置成内存属性并挂在链接脚本里保留起来保证RTOS的堆分配器不碰它。如果M核有MMU比如Cortex-R系列搭配MMU使用的情况则要像A核侧一样在页表里建立物理地址到虚拟地址的映射。这里有相当多芯片的SDK已经帮你做好了比如STM32MP1的OpenAMP例程但你仍然要知道它在背后做了什么否则一旦出问题会无从下手。2.3 一致性问题的两种策略这是整个共享内存设计里最容易出bug的地方。现代CPU都会有一级或多级cacheA核写入共享内存时数据可能停留在A核的cache里并没有真正到达DDRM核随后去读同一物理地址读到的却是DDR中的旧值。反过来也一样。这就是cache一致性问题。业界有两种基本策略我建议在最初阶段直接采用第一种策略一把共享内存映射为non-cacheable或device类型内存。对A核侧来说在MMU页表中把这段地址配成强序内存对M核侧在MPU/MMU里同样配置。这样每一笔读写都会直接落到DDR任何一核的写入立刻对另一方可见。好处是省心不需要手动clean/invalidate缺点是每次读写都要走DDR延迟偏高吞吐受限。策略二保持cacheable靠软件在关键点做缓存维护操作。发送方写完数据后执行clean把cache内容写回DDR接收方在读数据前执行invalidate让cache失效强制从DDR重新拉取。这种方式吞吐更高但代码里必须小心地在所有收发路径上处理好缓存维护漏一次就可能出现偶发数据错乱。在实际产品中很多团队采用混合布置控制结构描述符、环形缓冲索引用non-cacheable内存大块数据缓冲区用cacheable内存。原因是控制结构访问频率高但数据量小non-cacheable的额外延迟可以接受而大块业务数据拷贝成本高值得用cacheable把吞吐提上去。TI的IPC方案里就有类似的多缓冲区乒乓设计。无论用哪种策略都要注意一个细节共享内存里的关键结构体和缓冲区最好按cache line大小对齐ARM64通常是64字节。如果两个核同时读写同一个cache line里的不同字段硬件虽然是原子的但cache一致性协议会强制整行同步造成不必要的性能损耗严重的还能触发伪共享问题。2.4 门铃通知与内存屏障的实际顺序数据到位只是第一步对方还得知道数据来了。AMP中最常见的通知方式是触发中断也就是门铃。以两个核通过共享内存消息区通信为例发送方的流程必须严格遵循以下顺序把消息内容写入共享内存缓冲区。执行内存屏障ARM上是dmb或dsb确保上面的写操作真正完成且对其他核可见。写一个标志位更新环形缓冲区的写索引。再次执行内存屏障确保索引更新可见。触发对方核的中断门铃。有人会问为什么写了数据还要执行屏障因为CPU和编译器都可能对访存指令重排如果屏障顺序不对对方核心在处理中断、读取共享内存时可能看到索引已经更新了但消息内容还没写进去的中间状态。这个bug的恐怖之处在于它极难复现通常要在高负载下偶发一次。内存屏障和编译器屏障是两回事。compiler barrier如Linux里的barrier()只是阻止编译器把代码重排到边界之外而CPU仍然可能乱序执行dmb/dsb才真正约束硬件。数据通信里的发布-订阅语义靠的是CPU屏障。3. RPMSG协议拆解共享内存之上如何长出消息通道3.1 裸共享内存在真实项目中为什么不够用既然共享内存本身就能传数据为什么还需要RPMSG这是我被问得最多的问题。答案是共享内存解决的是数据能看到的问题但解决不了数据能正确交接的问题。想象两个核共用一个环形缓冲A核往里头写M核从里头读。如果没有任何协议约束你至少要自己解决缓冲区满的时候A核该怎么办M核读得快还是A核写得快多个业务模块比如控制通道和日志通道怎么区分消息归属如果A核写了半个消息就切换走了M核读到的不完整数据算不算一条消息这些问题如果都用裸共享内存手工维护每上一个新项目都要重写一套而且极易在边界条件下死锁或踩内存。RPMSG的价值在于它把这些问题全部标准化了。它基于virtio的环形缓冲区设计提供消息边界、多通道复用、流控和通知语义是一套可以直接拿来用的生产级协议。3.2 Virtio Ringvring在RPMSG里的角色RPMSG的底层是virtio标准它不依赖具体硬件传输方式核心数据结构叫vring。你可以把vring理解为一张双方共享的环形调度表这张表放在共享内存区记录着消息描述符的来龙去脉。一个vring内部有三个关键组成部分描述符表descriptor table描述各个缓冲区的位置、长度和标志。发送方把要发送的数据描述符填入表中。可用环avail ring也译作avail queue生产方向消费方宣布哪个描述符已经可用了的地方。发送方写完数据后把描述符索引放进avail ring并更新ring的idx。已用环used ring消费方处理完数据后回告这个描述符我用完了、你可以回收的地方。这两个环各配一个idx索引计数器两端的读写位置通过idx来区分。这里有个很巧妙的简化不需要锁。在任意时刻要么是生产方更新avail ring要么是消费方更新used ring不会出现双方同时写同一个环的情况。这个模型的容错性相当好也是virtio能几十年应用下来的原因。打个比方餐厅里有两位服务员和一位厨师。服务员A发送方把订单写好放到待做订单夹avail ring按铃通知厨师厨师接收方做完了把做好的菜放到已出菜夹used ring。两边各自维护订单号和出菜号两个计数器就能对齐状态不用争抢同一支笔。3.3 一条消息从发送到接收的完整旅程具体到RPMSG收发一条消息它要经过这些步骤发送方比如A核上的用户态应用打开RPMSG通道对应的设备节点Linux下是/dev/rpmsg0这类字符设备。write()数据到内核驱动。驱动获取共享内存中一块空闲的RPMSG缓冲区把数据拷进去缓冲区大小一般默认512字节或1KB。在缓冲区头部填充rpmsg_hdr结构src地址、dst地址、长度、flags等。把这个缓冲区的描述符加入发送方向的vring avail ring更新idx。执行内存屏障确保描述符和数据的写入对远端可见。触发M核的中断门铃。接收方M核上的OpenAMP中断处理或轮询线程收到门铃中断。从中断服务程序或轮询线程进入RPMSG接收路径。从RX方向的vring avail ring找到新的描述符获取缓冲区地址。根据rpmsg_hdr解析src/dst地址和长度取出消息内容。消息投递给注册好的回调函数例如用户自定义的Echo回调。回调处理完成后把描述符放入used ring让发送方可回收再用于下一次发送。如果M核需要回复数据执行同样的发送流程反过来触发A核中断。注意双方各自维护自己的发送方向和接收方向各用一个vring。所以一份RPMSG配置里通常会有两个vring方向相反互不干扰。你在配置资源表时看到的RPMSG_NUM_VRINGS常数就是2RPMSG_NUM_BUFFS决定缓冲区数目RPMSG_BUF_SIZE决定单个缓冲区大小。rpmsg_hdr的标准结构在rpmsg.h里定义关键字段如下struct rpmsg_hdr { uint32_t src; uint32_t dst; uint32_t reserved; uint16_t len; uint16_t flags; uint32_t ticket; };src和dst是通道地址len是消息有效载荷长度flags和ticket用于服务质量管理。消息内容是紧跟在rpmsg_hdr之后的字节流整个缓冲区大小由RPMSG_BUF_SIZE决定。3.4 多通道与名字服务工作机制RPMSG不仅仅是单条管道。它允许一个核上创建多个通道channel通道由src和dst地址对唯一标识。比如你可以建一个控制通道、一个数据通道、一个日志通道它们共用同一个物理共享内存区但消息通过地址区分路由到不同的处理回调。问题来了A核怎么知道M核上有一个新通道创建了这就要提到名字服务Name Service。RPMSG规定了一个特殊的通道使用固定的源/目标地址对例如0x35表示NS地址用于广播消息。当M核创建一个动态通道时它会通过NS通道发一条announce消息声明通道名字、源地址和目标地址A核的RPMSG核心收到这条消息后会创建对应的RPMSG设备节点用户态就能看到一个新的/dev/rpmsgN设备。你会在M核代码里看到rpmsg_create_ept()这样的函数它做的事情就是找空闲通道地址、注册端点回调、通过NS通道发出通知。这套机制的好处是通道的创建时机完全动态不用两边的开发者预先约定死通道号。4. 基于OpenAMP的落地配置与实测4.1 Master和Remote两侧需要准备什么聊完原理说落地。绝大多数AMP SoC的软件栈都是OpenAMP框架它既包含远端remote核心上运行的库也包含主控master核心上Linux侧的remoteproc/rpmsg驱动。具体到你会操作的东西在主控侧一般是Cortex-A Linux设备树里配置remoteproc节点和reserved-memory共享内存区。内核开启CONFIG_RPMSG、CONFIG_REMOTEPROC、CONFIG_RPMSG_VIRTIO等选项。通常还需要一个固件加载机制把M核的elf/bin文件放到/lib/firmware/下由remoteproc驱动加载以启动M核。启动后系统会在/dev/下生成rpmsg控制设备和数据设备。在远端侧一般是M核 裸机/FreeRTOS在M核工程里集成OpenAMP库或NXP的rpmsg-lite这类轻量实现。在链接脚本中预留共享内存地址和大小配置与主控侧保持一致。注册远端固件的资源表resource table里面描述了vring地址、缓冲区大小和数目。实现一个应用层回调处理收到的RPMSG消息。一个很常见的坑是两侧配置的参数不一致。主控侧设备树里写的共享内存基地址、M核链接脚本里声明的共享内存地址、资源表里的vring地址这三个地址只要有一个对不上启动时要么找不到固件资源要么收发消息时直接内存越界异常。排查起来非常费时间。我的习惯是先把这些地址整理成一张表放在代码头部注释里改任何一侧都同步更新。4.2 资源表与共享内存参数的对应关系以OpenAMP的标准资源表为例它一般长这样#define RPMSG_BUF_SIZE 512U #define RPMSG_NUM_BUFS 32U static struct fw_rsc_vdev rpmsg_vdev { .id VIRTIO_ID_RPMSG, .num_of_vrings 2, .vring { { VRING0_ADDR, 8, RPMSG_BUF_SIZE, 0, 0 }, { VRING1_ADDR, 8, RPMSG_BUF_SIZE, 0, 0 } }, };字段含义字段含义影响RPMSG_BUF_SIZE单个RPMSG缓冲区长度决定单条消息最大载荷也影响吞吐RPMSG_NUM_BUFS缓冲区个数决定收发队列的深度影响消息突发能力VRING0_ADDR/VRING1_ADDR两个vring的物理基址必须是共享内存范围内且对齐合理num_of_vringsvring个数RX/TX各一个固定为2缓冲区大小和数目是刚接触的人最爱照抄但又不理解的参数。RPMSG_BUF_SIZE设小了大块数据会被拆成多条消息每拆分一次就多一次握手开销设大了共享内存消耗成倍增加。RPMSG_NUM_BUFS设少了在两端处理速度不匹配时容易写满导致发送方阻塞或丢包设多了同样消耗内存。实际项目中数据包平均大小在几百字节时512到1024字节的缓冲区大小、16到32个缓冲数目是个稳妥的起点。后面调吞吐再按实测数据改。4.3 一个最小可运行的收发例程主控侧Linux下用C写一个最小发送程序其实非常简单#include stdio.h #include fcntl.h #include unistd.h #include string.h int main(void) { int fd open(/dev/rpmsg0, O_RDWR); if (fd 0) { perror(open rpmsg0); return -1; } char buf[256]; for (int i 0; i 10; i) { snprintf(buf, sizeof(buf), hello from A core, seq%d, i); write(fd, buf, strlen(buf) 1); printf(sent: %s\n, buf); memset(buf, 0, sizeof(buf)); read(fd, buf, sizeof(buf)); printf(recv: %s\n, buf); } close(fd); return 0; }对应的M核侧用OpenAMP注册一个回调收到什么就回什么就能形成一次ping-pongstatic int echo_cb(struct rpmsg_endpoint *ept, void *data, size_t len, void *priv, uint32_t src) { /* 原样回复发送方 */ rpmsg_send(ept, data, len); return 0; } void app_main(void) { struct rpmsg_lite_instance *rl; struct rpmsg_lite_endpoint *ept; rl rpmsg_lite_master_init(SHARED_MEM_BASE, SHARED_MEM_SIZE, 0, 0); ept rpmsg_lite_create_ept(rl, LOCAL_EPT_ADDR, echo_cb, NULL); while (1) { /* 等待中断/轮询处理 */ } }跑通这个例程后你会在Linux串口看到一条条sent/recv成对输出。第一次跑通时那种两个核终于说上话了的感觉比看任何文档都让人踏实。4.4 我实测的一组性能数据以一颗800MHz的A核和一颗400MHz的M核组合为例共享内存为non-cacheable时我做过的ping-pong测试结果大致是这样的缓冲区大小单次往返延迟单方向持续吞吐128字节约25us约5MB/s512字节约40us约13MB/s1024字节约65us约21MB/s延迟主要花在门铃中断触发、中断响应和共享内存访问上吞吐则明显受缓冲区大小影响因为单条消息载荷越大同样的握手开销摊到每字节成本就越低。如果把A核侧共享内存改成cacheable并做好缓存维护吞吐能再上一个台阶但代码复杂度也随之上升。我在项目里见过用RPMSG传音视频流跑到80MB/s以上的配置但那往往还配合了下面第5章要讲的零拷贝优化。5. 调优与踩坑记cache污染、门铃丢失、环形缓冲争用5.1 cache一致性问题的复现与排查链路先说最容易踩的坑cache污染。现象是通信在低负载时一切正常一旦高负载跑一段时间接收方读到的数据偶尔会出现半新半旧——消息头是新的payload是旧的或者干脆出现整段FF。这种bug很难稳定复现往往测试跑一晚上才出一次是调试时最折磨人的一类问题。排查链路我建议按下述顺序来先把共享内存区域改成non-cacheable如果问题消失说明基本可以锁定与cache相关。这一步是最快的试金石。检查共享内存的MMU/MPU配置确认设备树里的no-map生效了确认M核侧MPU区域优先级没有更低优先级配置覆盖它。有时问题根源是两段内存配置区域重叠低优先级区域被意外覆盖。检查收发代码路径上的缓存维护操作。如果走cacheable方案发送方是否在提交描述符之前对数据区做了cache_clean接收方是否在读取之前做了cache_invalidate有没有漏掉消息尾部最后一小段对比极端负载。可以在A核侧故意压测内存访问比如跑一个memcpy大数组的程序增加DDR访问冲突概率加快问题复现。我在项目中复现过一次类似的bug最终定位到M核侧在回调里读了数据但是没及时invalidate下一次的缓冲区导致缓冲区复用后拿到了上一轮的残留内容。解决办法是把invalidate操作挪到缓冲区分配时而不是接收回调里这个细节不仔细想很难发现。5.2 门铃机制下中断丢失与延迟抖动门铃中断在设计上是可靠的但实际系统中它的表现会受到中断屏蔽interrupt masking和优先级的影响。如果M核侧的RTOS在某段临界区长时间关闭中断而A核在这期间发送了多条消息M核中断恢复后可能只处理一次pending中断剩下的消息要靠后续轮询或者再次收到门铃才能被发现。消息本身没有丢还在共享内存里但延迟会陡然变大。解决办法有几种接收侧不要完全依赖中断可以在RTOS空闲任务或定时任务里周期性检查vring的idx是否变化作为中断的兜底。使用virtio的VRING_AVAIL_F_NO_INTERRUPT特性让发送方在接收方处理不过来时合并通知减少中断风暴但打开这个特性后接收方必须自己主动轮询否则会漏消息。确认两端的中断优先级配置确保核间通信中断不被低优先级任务长时间阻塞。这里有个教训不要一开始就开NO_INTERRUPT优化。先把基本中断模式跑通确认通信正确再考虑合并通知来降负载。否则你会有两个变量在同时变化出了问题很难归因。5.3 环形缓冲区水位告罄时的死锁风险RPMSG的vring虽然避免了读写同一环的竞争但缓冲区被用完的边界条件依然危险。考虑这样一个死锁场景A核持续发送占满了发送方向vring里所有描述符。M核接收回调在处理A核发来的消息时尝试回发一条响应但此时M核的发送方向vring对应A核的接收方向也被占满了。于是M核阻塞在rpmsg_send()上不再返回A核的接收路径回收描述符。A核也在等待M核的响应不回收对方发送方向的描述符。双方互等死锁。最常见的治疗手段是为发送操作加超时或者事先把发送方向缓冲区设置得比接收方向更深。另一个思路是回调里不要同步发送大块数据而是把待发送消息复制到本地队列由独立任务发送避免接收路径被发送阻塞反向拖死。这类死锁最大的问题是它不报错——两边看起来都在运行但消息就是不通。排查时用/proc/interrupts看门铃中断计数很久不增长是个快速判断手段。5.4 大块数据的零拷贝替代方案RPMSG每次传输都涉及一次从用户缓冲区到共享内存的拷贝当业务数据量很大时这个拷贝成本会占掉一大部分吞吐。我在实测中发现即使缓冲区从512字节加大到1024字节吞吐提升也有限瓶颈往往已经从内存拷贝转移到了中断处理频率上。对大块数据的常见优化思路是让RPMSG只传描述符/元数据实际数据走共享内存中的直通区。具体做法预先在共享内存里划出一块大区域比如1MB两端约定该区域的读写互斥规则A核要传一张图时先把图数据写入这个直通区然后通过RPMSG发一条图片数据已在xxx偏移长度yyyy的控制消息给M核M核收到后直接从直通区读数据读完再通过RPMSG回复可复用。这样大块数据只发生一次写入和一次读取完全绕过了RPMSG缓冲区的大小限制和拷贝开销。这种方案的代价是直通区的同步和互斥需要你自己设计常见的做法是简单的一写一读乒乓缓冲或者用共享内存上放一个原子标志位表示区域占用状态。不要在这里引入重量级的POSIX信号量那些依赖操作系统调度在异构核间不存在统一的调度器。一个自旋标志或乒乓切换就够用了。6. 什么时候该绕开RPMSG与裸共享内存、Mailbox、专有IPC的对比6.1 四类方案的核心差异对照不是所有核间通信场景都适合RPMSG。我做项目时习惯先把需求分清楚再选型下面是我自己用的对照表方案数据大小延迟复杂度适用场景裸共享内存 自设计协议任意适合大块数据低但受协议质量影响高cache/同步全得自己管固定格式的流式数据、点对点大数据RPMSG单条消息受缓冲区大小限制典型0.5KB~1KB中低门铃中断主导中OpenAMP已封装消息型业务、多通道控制、通用IPC硬件Mailbox一般几十字节极低低简单命令/事件通知、电源管理同步专有IPC框架TI IPC、NXP rpmsg-lite等看实现中低中与厂商核心绑定较紧的异构平台补充一点共享内存方案本身不排斥Mailbox。实际产品里最常见的设计是用Mailbox传事件信号用共享内存传业务数据两者配合。RPMSG只是把这个设计标准化了——它在virtio层面已经定义好了谁来决定vring的idx变化而门铃中断的具体实现可以落到芯片的Mailbox或任意中断控制器上。6.2 基于业务场景的选择建议如果是做控制类消息比如A核下发一条指令让M核调整PID参数消息长度几十字节、需要保证可靠到达——RPMSG是非常均衡的选择你不需要自己维护消息边界和通道复用。如果是做音视频流或大批量传感器数据消息体积动辄几十KB——直接用RPMSG搬原数据会很难受建议用上节说的RPMSG传控制信息 共享内存直通区传payload的混合模式。如果是做高频小事件通知比如M核每秒上报10000次按键扫描事件——门铃中断本身可能成为瓶颈要认真考虑合并通知、批量上报或者让M核把状态写入共享标志A核轮询读取。如果是做极低延迟的硬实时协作比如两个核在几十纳秒内协同响应一个硬件事件——RPMSG的消息封装和中断路径都太重了不如用硬件Mailbox加共享寄存器直接同步。我自己在实际项目中的体会是不要一上来就选最复杂的零拷贝方案也不要把RPMSG神话。任何通信方案的价值都要放到具体的数据模型里去检验。先把双方的数据交互流程画清楚消息频度、消息大小、可容忍延迟这三个指标算明白再决定用哪套方案。AMP核间通信的坑从来不在协议本身而在对业务模型的误判——把控制消息当成流数据处理或者反过来把大块流式数据硬塞进消息队列都会让系统在性能或复杂度上付出代价。最后分享一个调试技巧无论用哪套方案第一版都把共享内存区域设成non-cacheable跑通链路后再去优化cache策略。这样能帮你把协议逻辑问题和cache一致性问题分开排查而不是一上来就两团乱麻缠在一起。毕竟核间通信本身已经够复杂了没必要在第一步就给调试难度叠buff。