置顶 |

linux下多核通讯

字数统计: 3.9k字   |   阅读时长: 18分
阅读量

引言

在现代多核处理器系统中，处理器核心的组织方式和任务分配策略直接影响系统的软件设计与通信方式。按照核心间的共享程度，多核系统通常可以分为 对称多处理（SMP, Symmetric Multi-Processing） 和 非对称多处理（AMP, Asymmetric Multi-Processing） 两类。

SMP 架构

SMP 系统中的所有核心平等地共享同一份内存和 I/O 资源。每个核心运行相同的操作系统实例，一个核通过_start初始化以后，唤醒其他的核做secondary_start_kernel，可以执行任意任务，并通过统一的调度器协调任务执行。

AMP 架构

AMP 系统中，各个核心独立运行自己的操作系统实例或裸机程序，它们之间可能不共享内存，甚至运行不同类型的操作系统。典型应用包括 异构多核 SoC，如 Cortex-A 与 Cortex-M 核组合，或者 CPU 与 DSP 的混合系统。

SMP 与 AMP 的主要区别

特性 SMP AMP
核心对等性 所有核心对等 核心独立
操作系统 单实例，多核心共享 每核心独立操作系统
内存访问 全部共享 部分共享或不共享
通信方式 共享内存 + IPI 中断 消息通道（RPMsg / Mailbox）
通信目标 任务同步、调度、资源管理 命令下发、事件通知、数据传输

SMP多对称处理器间的通讯

应用场景

  1. 调度应用

    • 场景：当一个 CPU 修改了任务优先级 / 唤醒了一个任务，但该任务更适合在另一个 CPU 上执行时。

    • 做法：当前 CPU 向目标 CPU 发送 IPI，目标 CPU 立即触发调度器，切换到这个任务

  2. 跨核函数调用（smp_call_function）

    • 场景：某个内核子系统需要在所有 CPU 上执行一段代码，比如linux下的fiq-debugger机制：当某个核卡死的时候依然可以通过smp_call_function让该卡死的核执行传入的回调函数，在调试的时候非常好用，比如我的代码导致了某一个核卡死了，可以通过smp_call_function的机制让卡死的核dump一些信息

    • 做法：一个 CPU 发 IPI 给其他 CPU，让它们都执行一个回调函数。

  3. 核间通知 / 快速消息传递

    • 场景：一个 CPU 发现了全局事件（如中断、数据更新），需要立即通知其他 CPU。
    • 做法：通过 IPI 发送“消息”或触发事件处理函数。

在linux下多个a核间的通讯相对来说比较简单，主要是通过向需要通讯的核发一个ipi中断来实现，ipi中断以及中断处理函数在初始化的时候进行注册

IPI 的全称是 Inter-Processor Interrupt，中文一般叫 处理器间中断 或 核间中断。

它的作用就是在 **多核处理器 ** 系统里，让一个 CPU 主动“打断”另一个 CPU，从而实现 跨核通信与协作。

初始化前瞻

先看一些定义： linux内核支持的ipi调用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
enum ipi_msg_type {
	IPI_WAKEUP,
	IPI_TIMER,
	IPI_RESCHEDULE,
	IPI_CALL_FUNC,
	IPI_CPU_STOP,
	IPI_IRQ_WORK,
	IPI_COMPLETION,
	NR_IPI,
	/*
	 * CPU_BACKTRACE is special and not included in NR_IPI
	 * or tracable with trace_ipi_*
	 */
	IPI_CPU_BACKTRACE = NR_IPI,
	/*
	 * SGI8-15 can be reserved by secure firmware, and thus may
	 * not be usable by the kernel. Please keep the above limited
	 * to at most 8 entries.
	 */
	MAX_IPI
};

  1. 为每个核注册ipi中断（也就是gic控制器的SGI中断–注册为软件中断）：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    void __init set_smp_ipi_range(int ipi_base, int n)
    {
    	int i;

    	WARN_ON(n < MAX_IPI);
    	nr_ipi = min(n, MAX_IPI);
      //遍历所有支持的sgi中断号
    	for (i = 0; i < nr_ipi; i++) {
    		int err;
    		//为每个cpu注册相同的中断处理函数
    		err = request_percpu_irq(ipi_base + i, ipi_handler,
    					 "IPI", &irq_stat);
    		WARN_ON(err);

        //把中断描述符存在本地静态变量中
    		ipi_desc[i] = irq_to_desc(ipi_base + i);
    		irq_set_status_flags(ipi_base + i, IRQ_HIDDEN);

    		/* The recheduling IPI is special... */
    		if (i == IPI_RESCHEDULE)
    			__irq_modify_status(ipi_base + i, 0, IRQ_RAW, ~0);
    	}

    	ipi_irq_base = ipi_base;

    	/* Setup the boot CPU immediately */
    	ipi_setup(smp_processor_id());
    }

  2. 看一下ipi的处理函数

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    //看一下都支持哪些中断处理
    static void do_handle_IPI(int ipinr)
    {
    	unsigned int cpu = smp_processor_id();

    	if ((unsigned)ipinr < NR_IPI)
    		trace_ipi_entry_rcuidle(ipi_types[ipinr]);

    	switch (ipinr) {
    	case IPI_WAKEUP:
    		break;

    #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
    	case IPI_TIMER:
        	//看起来是时钟相关的
    		tick_receive_broadcast();
    		break;
    #endif

    	case IPI_RESCHEDULE:
        	//执行调度
    		scheduler_ipi();
    		break;

    	case IPI_CALL_FUNC:
        	//执行某个函数回调
    		generic_smp_call_function_interrupt();
    		break;

    	case IPI_CPU_STOP:
        	//暂停cpu
    		ipi_cpu_stop(cpu);
    		break;

    #ifdef CONFIG_IRQ_WORK
    	case IPI_IRQ_WORK:
        	//执行延迟的 irq_work 任务
    		irq_work_run();
    		break;
    #endif

    	case IPI_COMPLETION:
        	//通知ipi发起者某个操作完成了
    		ipi_complete(cpu);
    		break;

    	case IPI_CPU_BACKTRACE:
        	//打印backtrace
    		printk_nmi_enter();
    		nmi_cpu_backtrace(get_irq_regs());
    		printk_nmi_exit();
    		break;

    	default:
    		pr_crit("CPU%u: Unknown IPI message 0x%x\n",
    		        cpu, ipinr);
    		break;
    	}

    	if ((unsigned)ipinr < NR_IPI)
    		trace_ipi_exit_rcuidle(ipi_types[ipinr]);
    }

    static irqreturn_t ipi_handler(int irq, void *data)
    {
      //通过传入相对的中断号码
    	do_handle_IPI(irq - ipi_irq_base);
    	return IRQ_HANDLED;
    }

案例分析

这里拿IPI_CALL_FUNC来举例，场景是我们需要唤醒某个cpu执行一个函数（比如dump当前的reg）：ps – 为了方便理解整体的链路，代码部分我进行了一定的删减，因此与实际上的linux的代码有差异，感兴趣可移步至源码kernel/smp.c与arch/arm/kernel/smp.c中阅读

处理部分主要分为两个链路，一个是发ipi的链路，一个是处理ipi的链路，先看发ipi中断的链路：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
//这里其实就是处理所有发送ipi中断请求的接口，属于芯片架构层（这里会调用不同中断处理器的架构注册的回调函数）
int __ipi_send_mask(struct irq_desc *desc, const struct cpumask *dest)
{
    struct irq_data *data = irq_desc_get_irq_data(desc);
    struct irq_chip *chip = irq_data_get_irq_chip(data);
    unsigned int cpu;
	
    //如果该中断处理器已经注册了直接处理对应掩码的函数直接调用
    if (chip->ipi_send_mask) {
    	chip->ipi_send_mask(data, dest);
    	return 0;
    }

    //开始发送
    for_each_cpu(cpu, dest)
		chip->ipi_send_single(data, cpu);
    return 0;
}

static void smp_cross_call(const struct cpumask *target, unsigned int ipinr)
{
    trace_ipi_raise_rcuidle(target, ipi_types[ipinr]);
    __ipi_send_mask(ipi_desc[ipinr], target);
}

void arch_send_call_function_single_ipi(int cpu)
{
  	smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC);
}

void send_call_function_single_ipi(int cpu)
{
    //这里就进入到架构层了，会去对应的架构找相应的发ipi的函数
    arch_send_call_function_single_ipi(cpu);
}

void __smp_call_single_queue(int cpu, struct llist_node *node)
{
    //把回调的结构体加入对应cpu的链表中 -- 该例子中传入的是0 也就是代表将该事件加入到cpu0的执行list中
    if (llist_add(node, &per_cpu(call_single_queue, cpu)))
    	send_call_function_single_ipi(cpu);
}

static int generic_exec_single(int cpu, struct __call_single_data *csd)
{
    //如果是本cpu就直接执行传入的函数
    if (cpu == smp_processor_id()) {
        smp_call_func_t func = csd->func;
        void *info = csd->info;
        unsigned long flags;

        csd_lock_record(csd);
        csd_unlock(csd);
        local_irq_save(flags);
        func(info);
        csd_lock_record(NULL);
        local_irq_restore(flags);
        return 0;
    }
    
    //发ipi到其他cpu
    __smp_call_single_queue(cpu, &csd->llist);

    return 0;
}

//参数： cpu：要执行回调的cpuid func：回调函数指针 info：私有指针，供回调函数使用 wait：是否等待其他cpu执行完再退出
int smp_call_function_single(int cpu, smp_call_func_t func, void *info,
                             int wait)
{
    call_single_data_t *csd;
    call_single_data_t csd_stack = {
    	.flags = CSD_FLAG_LOCK | CSD_TYPE_SYNC,
    };
    int this_cpu;
    int err;

	//防止当前线程被调度到其他 CPU
    this_cpu = get_cpu();

    //确保这里不是在中断的上下文中调用的
    WARN_ON_ONCE(!in_task());

    csd = &csd_stack;
    //如果这里不等其他cpu执行完再退出的话就需要用全局变量作为参数防止该函数退出后导致访问空指针
    if (!wait) {
        csd = this_cpu_ptr(&csd_data);
        csd_lock(csd);
    }
	//设置函数指针和信息
    csd->func = func;
    csd->info = info;
	//发送ipi
    err = generic_exec_single(cpu, csd);

    if (wait)
    	csd_lock_wait(csd);

    put_cpu();

    return err;
}

既然中断已经发送过去了就需要看一下对应的中断处理函数，也就是generic_smp_call_function_interrupt：代码依旧只保留了关键逻辑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
static void flush_smp_call_function_queue(bool warn_cpu_offline)
{
    call_single_data_t *csd, *csd_next;
    struct llist_node *entry, *prev;
    struct llist_head *head;
    static bool warned;

    lockdep_assert_irqs_disabled();

    // 获取当前CPU的回调队列
    head = this_cpu_ptr(&call_single_queue);
    entry = llist_del_all(head);
    entry = llist_reverse_order(entry);

    prev = NULL;
    llist_for_each_entry_safe(csd, csd_next, entry, llist) {
		// 处理 SYNC 类型回调（同步等待的回调）
        if (CSD_TYPE(csd) == CSD_TYPE_SYNC) {
            smp_call_func_t func = csd->func;
            void *info = csd->info;
			
            if (prev) {
                prev->next = &csd_next->llist;
            } else {
                entry = &csd_next->llist;
            }

            csd_lock_record(csd);
          	//关键就是从链表中取出该该任务执行对应的回调
            func(info);
            csd_unlock(csd);
            csd_lock_record(NULL);
        } else {
            prev = &csd->llist;
        }
    }

    if (!entry)
        return;
    if (entry)
        sched_ttwu_pending(entry);
}


void generic_smp_call_function_single_interrupt(void)
{
	flush_smp_call_function_queue(true);
}

for test

我们可以写一段测试程序来验证一下我们上面所说的框架：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/smp.h>

static void smp_test_func(void *info)
{
    int cpu = smp_processor_id();
    printk("CPU%d executed callback, info=%s\n",
            cpu, (char *)info);
}

static int __init smp_test_init(void)
{
    int cpu;
    printk("SMP Call Function Any Test Module Loaded\n");

    for_each_online_cpu(cpu) {
        printk("Sending task to CPU%d...\n", cpu);
        smp_call_function_any(cpumask_of(cpu),
                              smp_test_func,
                              "Hello SMP",
                              1 );
    }

    printk("All CPUs have executed the callback.\n");
    return 0;
}

static void __exit smp_test_exit(void)
{
    printk("SMP Call Function Any Test Module Unloaded.\n");
}

module_init(smp_test_init);
module_exit(smp_test_exit);

MODULE_LICENSE("GPL");

image-20250905234646775

这里只是做了一行打印，但是我们在回调函数中的自由度是非常高的，所以可以做一些非常有意思的事情，例如dump当前cpu的一些信息

总结

所以总的来说，linux下的smp间的通信就是基于下发ipi中断来实现的，整体的流程也非常的简单：

  1. 初始化阶段

    • 内核启动时，会调用 set_smp_ipi_range()

    • 为 每个 CPU 注册好所有支持的 IPI 中断号（SGI → 对应 ipi_handler）

    • 所有 IPI 的入口统一落到 ipi_handler() → do_handle_IPI(ipinr)

  2. 通信阶段

    • 某个 CPU 需要和别的 CPU 通讯时 → 调用 smp_cross_call(cpumask, ipi_nr)

    • 本质就是往目标 CPU 发一个 IPI 中断（SGI）

  3. 处理阶段

    • 目标 CPU 收到 IPI → 进入统一的 ipi_handler()

    • 根据 IPI 类型 分发到不同的处理逻辑：

      • IPI_CALL_FUNC → 执行 generic_smp_call_function_interrupt()，在目标 CPU 上调用函数
        • IPI_RESCHEDULE → 执行 scheduler_ipi() → 触发一次 schedule() 调度
        • IPI_CPU_STOP → 停止 CPU
        • IPI_IRQ_WORK → 执行 irq_work
        • IPI_CPU_BACKTRACE → 打印 backtrace

  4. 举一反三（线程切换例子）
    如果我们想让某个 CPU 立刻执行一次线程切换：

1
2
// 发一个 IPI_RESCHEDULE 到目标 CPU -- 可能会封装好api，但是最终都会走到这里
smp_cross_call(cpumask_of(cpu), IPI_RESCHEDULE);

​ 在目标 CPU 上最终执行的就是：

1
2
3
case IPI_RESCHEDULE:
    scheduler_ipi();   // -> 最终进入 schedule()
    break;

​ 所以完全可以推断：**IPI_RESCHEDULE 的处理函数就是触发 schedule()**。

图示如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
graph TD

    subgraph CPUn["CPUn (发起方)"]
        FUNCREQ["smp_call_function*() 发起请求"]
        RESECHEDULE["smp_send_reschedule"]
        .....["....."]
        SENDIPI["调用 send_call_function_single_ipi()"]
    end

    subgraph ABST["架构抽象层 (ARCH 层)"]
        ARCHSEND["arch_send_call_function_single_ipi() 发送 IPI"]
        ARCHRECV["handle_IPI() (ARCH 层实现)"]
    end

    subgraph HW["硬件 (GIC / APIC)"]
        HWIPI["触发 IPI 硬件中断"]
    end

    subgraph CPUm["CPUm (接收方)"]
        IRQ["CPUm 收到 IPI 中断"]
        HANDLEIPI["进入 handle_IPI()"]
        
    end
    
    subgraph ipi_hand["handle_IPI"]
    	DISPATCH["根据 IPI 类型分发"]
        CALLFUNC["IPI_CALL_FUNC → generic_smp_call_function_interrupt()"]
        RESCHED["IPI_RESCHEDULE → scheduler_ipi() 调度器"]
        ...["..."]
    end

    FUNCREQ --> SENDIPI
    RESECHEDULE --> SENDIPI
    ..... --> SENDIPI
    SENDIPI --> ARCHSEND
    ARCHSEND --> HWIPI
    HWIPI --> IRQ
    IRQ --> HANDLEIPI
    HANDLEIPI --> ARCHRECV
    ARCHRECV --> DISPATCH
    DISPATCH --> CALLFUNC
    DISPATCH --> RESCHED
    DISPATCH --> ...

AMP非对称多核的通讯

由于a核和m核心之间通信方式有很多，大部分要看soc内部的硬件实现，比如mailbox，共享内存等等的机制，对于机制的具体实现本节我们不过多关注，但是linux提供了一个rpmsg的框架，用于向用户屏蔽底层差异。源码位于 driver/rpmsg下

rpmsg在linux中作为一个单独的总线实际上和其他类似platform，iic，pcie总线类似，总线的主体都是由probe，remove，match组成的。

先看一下这个结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
/**
 * struct rpmsg_device_ops - indirection table for the rpmsg_device operations
 * @create_ept:		create backend-specific endpoint, required
 * @announce_create:	announce presence of new channel, optional
 * @announce_destroy:	announce destruction of channel, optional
 *
 * Indirection table for the operations that a rpmsg backend should implement.
 * @announce_create and @announce_destroy are optional as the backend might
 * advertise new channels implicitly by creating the endpoints.
 */
struct rpmsg_device_ops {
	struct rpmsg_endpoint *(*create_ept)(struct rpmsg_device *rpdev,
					    rpmsg_rx_cb_t cb, void *priv,
					    struct rpmsg_channel_info chinfo);

	int (*announce_create)(struct rpmsg_device *ept);
	int (*announce_destroy)(struct rpmsg_device *ept);
};
/**
 * rpmsg_device - device that belong to the rpmsg bus
 * @dev: the device struct
 * @id: device id (used to match between rpmsg drivers and devices)
 * @driver_override: driver name to force a match
 * @src: local address
 * @dst: destination address
 * @ept: the rpmsg endpoint of this channel
 * @announce: if set, rpmsg will announce the creation/removal of this channel
 */
struct rpmsg_device {
	struct device dev;
	struct rpmsg_device_id id;
	char *driver_override;
	u32 src;
	u32 dst;
	struct rpmsg_endpoint *ept;
	bool announce;

	const struct rpmsg_device_ops *ops;
};

typedef int (*rpmsg_rx_cb_t)(struct rpmsg_device *, void *, int, void *, u32);
typedef int (*rpmsg_rx_sig_t)(struct rpmsg_device *, void *, u32, u32);

/**
 * struct rpmsg_endpoint - binds a local rpmsg address to its user
 * @rpdev: rpmsg channel device
 * @refcount: when this drops to zero, the ept is deallocated
 * @cb: rx callback handler
 * @cb_lock: must be taken before accessing/changing @cb
 * @sig_cb: rx serial signal handler
 * @addr: local rpmsg address
 * @priv: private data for the driver's use
 *
 * In essence, an rpmsg endpoint represents a listener on the rpmsg bus, as
 * it binds an rpmsg address with an rx callback handler.
 *
 * Simple rpmsg drivers shouldn't use this struct directly, because
 * things just work: every rpmsg driver provides an rx callback upon
 * registering to the bus, and that callback is then bound to its rpmsg
 * address when the driver is probed. When relevant inbound messages arrive
 * (i.e. messages which their dst address equals to the src address of
 * the rpmsg channel), the driver's handler is invoked to process it.
 *
 * More complicated drivers though, that do need to allocate additional rpmsg
 * addresses, and bind them to different rx callbacks, must explicitly
 * create additional endpoints by themselves (see rpmsg_create_ept()).
 */
struct rpmsg_endpoint {
	struct rpmsg_device *rpdev;
	struct kref refcount;
	rpmsg_rx_cb_t cb;
	struct mutex cb_lock;
	rpmsg_rx_sig_t sig_cb;
	u32 addr;
	void *priv;

	const struct rpmsg_endpoint_ops *ops;
};

struct rpmsg_driver {
	struct device_driver drv;
	const struct rpmsg_device_id *id_table;
	int (*probe)(struct rpmsg_device *dev);
	void (*remove)(struct rpmsg_device *dev);
	int (*callback)(struct rpmsg_device *, void *, int, void *, u32);
	int (*signals)(struct rpmsg_device *rpdev,
		       void *priv, u32 old, u32 new);
};

使用方法

我们以rockchip的核间通讯的驱动为例：
首先会注册一个platform总线的驱动框架用于管理自己的设备资源：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
static const struct of_device_id rockchip_rpmsg_match[] = {
	{ .compatible = "rockchip,rk3562-rpmsg", .data = (void *)RK3562, },
	{ .compatible = "rockchip,rk3568-rpmsg", .data = (void *)RK3568, },
	{ /* sentinel */ },
};

MODULE_DEVICE_TABLE(of, rockchip_rpmsg_match);

static struct platform_driver rockchip_rpmsg_driver = {
	.probe = rockchip_rpmsg_probe,
	.remove = rockchip_rpmsg_remove,
	.driver = {
		.name = "rockchip-rpmsg",
		.of_match_table = rockchip_rpmsg_match,
	},
};

在probe中会注册一个virtio设备，同时注册mailbox通道，将virtio的rx tx 接口设置为mailbox，我们可以理解mailbox是在virtio的下一层，是实际和硬件交互的层级：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
//这是我从probe中提取出来的一部分
for (i = 0; i < rpdev->vdev_nums; i++) {
		dev_info(dev, "rpdev vdev%d: vring0 0x%x, vring1 0x%x\n",
			 i, rpdev->rpvdev[i]->vring[0], rpdev->rpvdev[i]->vring[1]);
		rpdev->rpvdev[i]->vdev.id.device = VIRTIO_ID_RPMSG;
		rpdev->rpvdev[i]->vdev.config = &rk_rpmsg_config_ops;
		rpdev->rpvdev[i]->vdev.dev.parent = dev;
		rpdev->rpvdev[i]->vdev.dev.release = rk_rpmsg_vdev_release;
		rpdev->rpvdev[i]->base_queue_id = i * 2;
		rpdev->rpvdev[i]->rpdev = rpdev;

		ret = register_virtio_device(&rpdev->rpvdev[i]->vdev);
		if (ret) {
			dev_err(dev, "fail to register rpvdev: %d\n", ret);
			goto free_reserved_mem;
		}
	}

在a核上我们可以将m核作为一个虚拟设备，使用virtio去管理，所以rgmsg基于virtio注册了一个通用的驱动，位于drivers/rpmsg/virtio_rpmsg_bus.c下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

//只要virtio id device ==  VIRTIO_ID_RPMSG 的所有设备都可以进probe中
static struct virtio_device_id id_table[] = {
	{ VIRTIO_ID_RPMSG, VIRTIO_DEV_ANY_ID },
	{ 0 },
};

static unsigned int features[] = {
	VIRTIO_RPMSG_F_NS,
};

static struct virtio_driver virtio_ipc_driver = {
	.feature_table	= features,
	.feature_table_size = ARRAY_SIZE(features),
	.driver.name	= KBUILD_MODNAME,
	.driver.owner	= THIS_MODULE,
	.id_table	= id_table,
	.probe		= rpmsg_probe,
	.remove		= rpmsg_remove,
};

static int __init rpmsg_init(void)
{
	int ret;

	ret = register_virtio_driver(&virtio_ipc_driver);
	if (ret)
		pr_err("failed to register virtio driver: %d\n", ret);

	return ret;
}

当我们的soc中需要做m核和a核的通讯的时候，我们需要注册一个rpmsg driver以及一个device，而在上面的rpmsg_probe就会执行device的注册，此时我们再需要注册一个rpmsg的driver就可以让这一套机制运行起来了，由于virtio框架内容比较多，这里不纠结底层的实现了，大致流程可以从如下框图看出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
sequenceDiagram
    participant APP as 用户态应用
    participant RPDRV as RPMsg 驱动
    participant VQ as Virtio/vring
    participant MBOX_CL as Mailbox Client
    participant HW as Mailbox 硬件
    participant MBOX_SRV as Mailbox Server
    participant RPKERN as 远端 RPMsg 核心
    participant FW as 远端固件/RTOS 应用

    APP->>RPDRV: 写消息
    RPDRV->>VQ: enqueue 到 tx virtqueue
    VQ->>MBOX_CL: virtqueue_kick()
    MBOX_CL->>HW: mbox_send_message()
    HW->>MBOX_SRV: 触发中断 / 写寄存器
    MBOX_SRV->>RPKERN: 收到消息，放入 vring buffer
    RPKERN->>FW: 调用远端应用回调
    FW-->>RPKERN: 响应数据
    RPKERN->>MBOX_SRV: enqueue 响应到 vring
    MBOX_SRV->>HW: 触发中断通知 A 核
    HW->>MBOX_CL: 收到中断
    MBOX_CL->>VQ: virtqueue callback
    VQ->>RPDRV: rpmsg_receive()
    RPDRV->>APP: 调用用户回调 / 返回消息

赏

谢谢你请我吃糖果

支付宝
微信
置顶

扫一扫，分享到微信

微信分享二维码
总访问量:

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

争取<br><br>早日成为大牛<br>