本文转自 周贺贺，baron，代码改变世界ctw，Arm精选， armv8/armv9，trustzone/tee，secureboot，资深安全架构专家，11年手机安全/SOC底层安全开发经验。擅长trustzone/tee安全产品的设计和开发。
- 思考和质疑 在一个大架构大系统中，有哪些一致性需要维护？我们先看如下一张架构图。
然后请思考：
(1)、core0中的L1和L2 cache有一致性的要求吗？缓存和替换策略是怎样的？ (2)、core0 cache 和 core1 cache的一致性是谁来维护？ 遵从MESI协议吗？ (3)、core0 cache 和 core4 cache的是怎么维护一致性的呢？ (4)、custer0 L3 cache 和 cluster1 L3 cache的一致性是谁来维护？遵从什么协议吗？ (5)、custer0 L3 cache 和 GPU的L2一致性呢？遵从什么协议？ (6)、custer0 L3 cache 和 其它的I/O device Master一致性呢？遵从什么协议？ (7)、DSU、ACE、CHI、CCI、CMN的概念？ 网上的好多篇博文，一提Cache的多核一致性就必然提到MESI、MOESI ，然后就开始讲MESI、MOESI维护性原理？试问一下，您是真的不理解MESI吗？您真的需要学习MESI？你不理解的是架构吧，而不是学什么协议. 既然要学习MESI，那么这里也继续提出一些问题：
(1)、ARM架构中真的使用MESI了吗？ 或者是哪一级cache使用了，哪一级cache没有使用？ (2)、MESI是一个协议？ 是谁来维护的？总得有个硬件实现这个协议吧，是在ARM Core实现？DSU实现？ (3)、MESI的四种状态，分别记录在哪里的？ (4)、arm现在主流的core，到底使用的是MESI，还是MOESI？
- 怎样去维护多核多系统缓存的一致性 有三种机制可以保持一致性：
禁用缓存是最简单的机制，但可能会显着降低 CPU 性能。为了获得最高性能，处理器通过管道以高频率运行，并从提供极低延迟的缓存中运行。缓存多次访问的数据可显着提高性能并降低 DRAM 访问和功耗。将数据标记为"非缓存"可能会影响性能和功耗。 软件管理的一致性是数据共享问题的传统解决方案。在这里，软件（通常是设备驱动程序）必须清除或刷新缓存中的脏数据，并使旧数据无效，以便与系统中的其他处理器或主设备共享。这需要处理器周期、总线带宽和功率。 硬件管理的一致性提供了一种简化软件的替代方案。使用此解决方案，任何标记为"共享"的缓存数据将始终自动更新。该共享域中的所有处理器和总线主控器看到的值完全相同。 然而，我们在ARM架构中，默认使用的却是第三种 硬件管理的一致性, 意思就是：做为一名软件工程师，我们啥也不用管了，有人帮我们干活，虽然如此，但我们还是希望理解下硬件原理。
再讲原理之前，我们先补充一个场景: 假设在某一操作系统中运行了一个线程，该线程不停着操作0x4000_0000地址处内存（所以我们当然期望，它总是命中着），由于系统调度，这一次该线程可能跑在cpu0上，下一次也许就跑在cpu1上了，再下一次也许就是cpu4上了(其实这种行为也叫做CPU migration)
或者举个这样的场景也行： 在Linux Kernel系统中，定义了一个全局性的变量，然后多个内核线程(多个CPU)都会访问该变量.
在以上的场景中，都存在一块内存(如0x4000_0000地址处内存)被不同的ARM CORE来访问，这样就会出现了该数据在main-memory、cluster cache、core cache不一致的情况, 复杂点场景可能还会考虑cluster chache和other Master(如GPU) cache的一致性情况。
既然出现了数据在内存和不同的cache中的不一致的情况，那么就需要解决这个问题（也叫维护cache一致性），那么怎么维护的呢，上面也说了"使用 硬件管理的一致性"，下面就以直接写答案的方式，告诉你硬件是怎样维护一致性的。
-
1 多核缓存一致性 同一个cluster中多core之间的缓存一致性由DSU(big.LITTLE叫SCU)来维护，遵循MESI协议。
-
2 多Master之间的缓存一致性 在讲述多Master之间的缓存一致性之前，我们先将Master分为以下几类：
ACE Master : 如 big.LITTLE cluster 或 DSU cluster CHI Master : 如 big.LITTLE cluster 或 DSU cluster ACE-lite Master： 如 GPU cluster I/O Device Master : 如 DMA
以下是多Master之间的缓存一致性的结论：
首先，CHI/ACE总线都是支持MESI协议数据传输的 Master与I/O Device Master之间没有一致性，因为I/O Device没有链接到CCI/CMN缓存互联总线上。 多个ACE/CHI Master之间的缓存一致性，是否遵循MESI，要具体情况具体分析，简而言之就是： (1) 如果两个Master都支持带MESI状态位，支持带有MESI信号的读写，那么这两个Master缓存一致性是遵从MESI协议的 (2) 如果有一个Master不支持带MESI状态位，那么这个Master就无法支持带有MESI信号的读写，那么这两个Master缓存一致性是不遵从MESI协议的 (3) Master的MESI状态位，是在该Master的cache的TAG中。 ACE/CHI Master和ACE-lite Master之间的缓存一致性，是不遵从MESI协议的。这主要是因为ACE/CHI Master无法snoop ACE-lite Master的内存，而ACE-lite Master却可以snoop ACE/CHI Master的内存，总得来说，这不是一个完整的MESI协议。 举一个最常见的例子：两个DSU cluster的L3 cache中的TAG中，是有MESI比特位的，这两个DSU通过ACE/CHI 接口发起的读写是带有MESI信号的，所以他们是支持MESI协议的。
再举一个例子，一个DSU cluster 和一个接到SMMU上的DMA，此时正好对应一个是ACE/CHI Master，一个ACE-lite Master，由于DMA/SMMU中并没有MESI状态位，他们也不会发起带有MESI信号的读写，所以这两个Master之间是不支持MESI协议的。