深度解析：cache的基本概念原理扫盲

骑猪看日落 2024-04-24 14:53 48阅读 0赞

> 引流关键词:缓存,高速缓存,cache, CCI,CMN,CCI-550,CCI-500,DSU,SCU,L1,L2,L3,system cache, Non-cacheable,Cacheable, non-shareable,inner-shareable,outer-shareable, optee、ATF、TF-A、Trustzone、optee3.14、MMU、VMSA、cache、TLB、arm、armv8、armv9、TEE、安全、内存管理、页表…

#### 文章目录 ####

*  1、cache是多级相连的
 *  2、cache一般是和MMU结合在一起使用的
 *  3、硬件架构基础介绍
 *   *   *  3.1 big.LITTLE架构的cache
         *  3.2 DynamIQ架构架构的cache
         *  3.3 缓存一致性总线-CCI
         *  3.4 缓存一致性总线-CMN
         *  3.5 big.LITTLE架构中的cluster interface
         *  3.6 dynamIQ架构中的DSU interface
         *  3.7 架构图示例
 *  4、L1/L2/L3 cache的大小
 *  5、cache的组织形式(index, way, set)
 *  6、cache的种类(VIVT,PIPT,VIPT)
 *  7、cache的分配策略(alocation,write-through, write-back)
 *  8、架构中定义的cache的范围(inner, outer)
 *  9、架构中内存的类型
 *   *  推荐

--------------------

本文转自 周贺贺，baron，代码改变世界ctw，Arm精选， armv8/armv9，trustzone/tee，secureboot，资深安全架构专家，11年手机安全/SOC底层安全开发经验。擅长trustzone/tee安全产品的设计和开发。

## 1、cache是多级相连的 ##

cache是多级的，在一个系统中你可能会看到L1、L2、L3, 当然越靠近core就越小，也是越昂贵。  
一般来说，对于big.LITTLE架构中，在L1是core中，L1又分为L1 data cache和 L1 Instruction cache， L2 cache在cluster中，L3则在BUS总线上。  
![在这里插入图片描述][b6530b1e28ba4bf9a08fa151067e3a17.png]

## 2、cache一般是和MMU结合在一起使用的 ##

很多时候cache都是和MMU一起使用的(即同时开启或同时关闭)，因为MMU页表的entry的属性中控制着内存权限和cache缓存策略等  
![在这里插入图片描述][d3cf4013f6584140ae227321a7473e5c.png]

在ARM架构中，L1 cache都是VIPT的，也就是当有一个虚拟地址送进来，MMU在开始进行地址翻译的时候，Virtual Index就可以去L1 cache中查询了，MMU查询和L1 cache的index查询是同时进行的。如果L1 Miss了，则再去查询L2，L2还找不到则再去查询L3。 注意在arm架构中，仅仅L1 cache是VIPT，L1L2和L3都是PIPT。

![在这里插入图片描述][ae7c8d400fdd42768375b0bc5876818d.png]

## 3、硬件架构基础介绍 ##

**`big.LITTLE`** 架构 和 **`DynamIQ`** 架构 的cache是有区别的

![在这里插入图片描述][84fe278f11134914988766fbb403df61.png]

*  在 **`big.LITTLE`** 架构中，大核小核在不同的cluster中，做为两个不同的ACE或CHI Master，连接到缓存一致性总线上(CCI或CMN)。大核cluster和小核cluster的缓存一致性，也需要通过一致性总线来解决。
 *  到了DynamIQ 架构中，大核和小核都是一个DSU cluster中，一个DSU cluster最多可以支持8个core。如果你的系统是8个core，那么一个DSU就够了，那么系统中也就只有一个ACE或CHI Master，大核和小核之间的一致性，都在DSU cluster内完成了。

#### 3.1 big.LITTLE架构的cache ####

在 **`big.LITTLE`** 的架构中，L1是在core中的，是core私有的；L2是在cluster中的，对cluster中的core是共享的；L3则对所有cluster共享。`big.LITTLE` 的架构的一个cache层级关系图如下所示：  
![在这里插入图片描述][fab26f7eeb1e429f9ac59513240f664d.png]

#### 3.2 DynamIQ架构架构的cache ####

在 `dynamIQ` 的架构中，L1和L2都在core中的，都是core私有的；L3则是在cluster中的，对cluster中的core是共享的；如有L3或system cache，则是所有cluster共享。dynamIQ的架构的一个cache层级关系图如下所示。  
注意，一般来说一个DSU Cluster就可以做到支持8个core，以下只是举一个极端的例子，在硬件设计时，我非要放置两个DSU cluster 可不可以？两个DSU Cluster做为两个ACE Master连接到了CCI一致性总线上。  
![在这里插入图片描述][ecb61dae1533413683ab34b7ec00e0c8.png]

#### 3.3 缓存一致性总线-CCI ####

用于ACE Master缓存一致性总线有 `CCI-550`、`CCI-500`、`CCI-400`。  
![在这里插入图片描述][110366bf94b24090bc9e74e8927964f8.png]

它的主要作用是可以互联多个`ACE Master`、`ACE-lite` `Master`，然后通过ACE接口协议，做到多个Master之间的缓存一致性。CCI最多支持2个`ACE Master`，共计支持8个`ACE Master`\+`ACE-lite Master`。  
所以呢，如果是big.LITTLE架构的，那么最多支持两个cluster互联，每个cluster 8个core，所以最多支持8个core；如果是dynamIQ架构的，那么最多支持两个DSU cluster互联，每个cluster 8个core，所以最多支持16个core

#### 3.4 缓存一致性总线-CMN ####

用于CHI Master缓存一致性总线有CMN-700、CMN-600.  
![在这里插入图片描述][e3756c924d444d69b3bc7106b24e68e8.png]

它的主要作用是可以互联多个`CHI Master`、`ACE-lite` `Master`，然后通过CHI接口协议，做到多个Master之间的缓存一致性。CCI-600最多支持8个 `CHI Master` ，共计支持8个`CHI Master` \+ `ACE-lite Master`。

![在这里插入图片描述][6cff0306f8ce427186094da016e8a790.png]

#### 3.5 big.LITTLE架构中的cluster interface ####

在`big.LITTLE`架构中，cluster连接到一致性总线的接口，可以是ACE，也可以是CHI，所以big.LITTLE cluster既可以做为ACE Master连接到总线，也可以做为CHI Master连接到总线。

![在这里插入图片描述][4530c4b8e0724093aeae8d8f79c8a688.png]

#### 3.6 dynamIQ架构中的DSU interface ####

2017年引入dynamIQ架构， 在DSU(dynamIQ Share Unit)规范中，连接到一致性总线的接口，可以是ACE，也可以是CHI，所以DSU cluster既可以做为ACE Master连接到总线，也可以做为CHI Master连接到总线。  
![在这里插入图片描述][5f0b7537b4864c5198c8d6ba92aa4717.png]

而在DSU-110中， 连接到一致性总线的接口可以是CHI ,但不再有ACE了。如果你使用的是DSU-110，DSU Cluster做为CHI Master了，那么你一定是采用CMN的总线互联方式。

![在这里插入图片描述][2572680b35d447a6b24ccaccf237ea43.png]

#### 3.7 架构图示例 ####

所以呢，你看到的系统架构图(也是近几年最常用的)，可能是下面这个样子的，所有的core都在一个DSU cluster中，所有core共享L3 cache，DSU接到CCI或CMN缓存互联一致性总线上，可以和其它ACE-Lite Master(如 GPU)共享缓存数据  
![在这里插入图片描述][a9d74a9e3e224de5832edfbec68bd348.png]

当然了，举个稍微极端的例子，如下连接架构图也不是不可能，系统中有两个DSU cluster，DSU接到CCI或CMN缓存互联一致性总线上。

![在这里插入图片描述][81a0188c18b84174984219e707521e0c.png]

事实上big.LITTLE架构的cluster，也是可以做为CHI Master。下面这种超极端的例子，技术理论上也是可行的(当然可能不会有人用)。

![在这里插入图片描述][d6622a0ddfa947c08da59a525d85f375.png]

## 4、L1/L2/L3 cache的大小 ##

可以参考ARM文档，

*  对于`big.LITTLE`架构的core，其cache大小基本是固定的。
 *  对于`dynamIQ`架构的core，其L1和L2 cache大小基本是固定的。但对于L2 cache 则是可选择可配置的

另外查阅DSU TRM文档，可以看到L3 Cache可以配置 0 - 16MB的大小。  
![在这里插入图片描述][59db0703eda5414183117a77967f17cd.png]

## 5、cache的组织形式(index, way, set) ##

cache的组织形式有：

*  全相连
 *  直接相连
 *  多路组相连（如4路组相连）  
    ![在这里插入图片描述][b9a15693c3b54621a535614ad957f4ae.png]

在一个core中一个架构中一个SOC中，所有cache的组织形式并不是都一样的。即使L1 D-cache和L1 I-cache的组织形式，也都可能不是一样的的。 具体的组织形式是怎>样的，需要查询你的core trm手册。

> 例如我们查询到Cortex-A53的cache信息如下：
> 
> L1 I-Cache
> 
>  *  可配:8KB, 16KB, 32KB, or 64KB
>  *  cacheline:64bytes
>  *  2路组相连
>  *  128-bit的读L2 memory的接口
> 
> **L1 D-Cache**
> 
>  *  可配:8KB, 16KB, 32KB, or 64KB
>  *  cacheline:64bytes
>  *  4路组相连
>  *  256-bit的写L2 memory的接口
>  *  128-bit的读L2 memory的接口
>  *  64-bit的读L1到datapath
>  *  128-bit的写datapath到L1
> 
> **L2 cache**
> 
> 可配置的: 128KB, 256KB, 512KB, 1MB and 2MB.
> 
>  *  cacheline:64bytes
>  *  Physically indexed and tagged cache（PIPT）  
>     \-16路组相连的结构

因为有了多路组相连这个cache，所以也就有了一些术语概念：

*  index ： 用白话理解，其实就是在一块cache中，一行一行的编号(事实是没有编号/地址的)
 *  Set ：用index查询到的cache line可能是多个，这些index值一样的cacheline称之为一个set
 *  way：用白话来说，将cache分成了多个块（多路），每一块是一个way
 *  cache TAG ：查询到了一行cache后，cachelne由 TAG + DATA组成
 *  cache Data ：查询到了一行cache后，cachelne由 TAG + DATA组成
 *  cache Line 和 entry 是一个概念

![在这里插入图片描述][1fcd929f248f486bbeff5942f40c7f60.png]

## 6、cache的种类(VIVT,PIPT,VIPT) ##

cache一般是有如下种类；

*  PIPT
 *  VIVT
 *  VIPT  
    在一个core中一个架构中一个SOC中，你所使用的cache是哪种类型的，都是固定的，是软件改不了的。 在ARM架构中，一般L1 cache都是VIPT的，其余的都是PIPT的。  
    VIPT和PIPT的原理，基本也都是一样的，只是硬件查询时稍微有一丁点的区别，在后续讲cache查询时会再次介绍。

那么，你还学什么VIVT？你为什么还要去理解VIVT的原理？你为什么还要去分析cache同名、重名的问题？ 这样的问题，在armv7/armv8/armv9架构中都是不存在的

## 7、cache的分配策略(alocation,write-through, write-back) ##

*  **读分配(read allocation)**  
    当CPU读数据时，发生cache缺失，这种情况下都会分配一个cache line缓存从主存读取的数据。默认情况下，cache都支持读分配。
 *  **写分配(write allocation)**  
    当CPU写数据发生cache缺失时，才会考虑写分配策略。当我们不支持写分配的情况下，写指令只会更新主存数据，然后就结束了。当支持写分配的时候，我们首先从主存中加载数据到cache line中（相当于先做个读分配动作），然后会更新cache line中的数据。
 *  **写直通(write through)**  
    当CPU执行store指令并在cache命中时，我们更新cache中的数据并且更新主存中的数据。cache和主存的数据始终保持一致。
 *  **写回(write back)**  
    当CPU执行store指令并在cache命中时，我们只更新cache中的数据。并且每个cache line中会有一个bit位记录数据是否被修改过，称之为dirty bit（翻翻前面的图片，cache line旁边有一个D就是dirty bit）。我们会将dirty bit置位。主存中的数据只会在cache line被替换或者显示的clean操作时更新。因此，主存中的数据可能是未修改的数据，而修改的数据躺在cache中。cache和主存的数据可能不一致

![在这里插入图片描述][00cd5f57182f45abb49989c23b02095c.png]

## 8、架构中定义的cache的范围(inner, outer) ##

对于cacheable属性，inner和outer描述的是cache的定义或分类。比如把L1/L2看做是inner cache，把L3看做是outer cache。

通常，内部集成的cache属于inner cache，外部总线AMBA上的cache属于outer cache。例如:

*  对于big.LITTLE架构（A53为例)中，L1/L2属于inner cache，如果SOC上挂了L3的话，则其属于outer cache
 *  对于DynamIQ架构（A76为例)中，L1/L2/L3属于inner cache，如果SOC上挂了System cache（或其它名称）的话，则其属于outer cache

然后我们可以对每类cache进行单独是属性配置，例如：

*  配置 inner Non-cacheable 、配置 inner Write-Through Cacheable 、配置 inner Write-back Cacheable
 *  配置 outer Non-cacheable 、配置 outer Write-Through Cacheable 、配置 outer Write-back Cacheable  
    ![在这里插入图片描述][d12ee1be6f5f4c7a98da1adbc64ebce2.png]

对于shareable属性，inner和outer描述的是cache的范围。比如inner是指L1/L2范围内的cache，outer是指L1/L2/L3范围内的cache

![在这里插入图片描述][94d764912acf4ced84173a38862e60c2.png]

## 9、架构中内存的类型 ##

在arm架构中，将物理内存分成了device和normal两种类型

![在这里插入图片描述][34a6bcbe93634195bfe286e914684157.png]

而是每种的内存下(device和normal)又分出了多种属性。ARM提供一个MAIR寄存器, 将一个64位的寄存器分成8个attr属性域，每个attr属性域有8个比特，可配置成不同的内存属性。  
也就是说，在一个arm core，最多支持8中物理内存类型。  
![在这里插入图片描述][d3ff2a3ba0774d9ea3ae7e175d57069f.png]

而我们在MMU使用的页表的entry中的属性位中，BIT\[4:2\]占3个比特，表示index，其实就是指向MAIR寄存器中的attr。  
（Attribute fields in stage 1 VMSAv8-64 Block and Page descriptors）

![在这里插入图片描述][4efea1acfc484106acebbb8838f1cd72.png]

> **PBHA**, bits\[62:59\] ：for FEAT\_HPDS2  
> **XN or UXN**, bit\[54\] ： Execute-never or Unprivileged execute-never  
> **PXN**, bit\[53\] ：Privileged execute-never  
> **Contiguous**, bit\[52\] ： translation table entry 是连续的，可以存在一个TLB Entry中  
> **DBM**, bit\[51\] ：Dirty Bit Modifier  
> **GP**, bit\[50\] ：for FEAT\_BTI  
> **nT**, bit\[16\] ：for FEAT\_BBM  
> **nG**, bit\[11\] ：缓存在TLB中的翻译是否使用ASID标识  
> **AF**, bit\[10\] ： Access flag, AF=0后，第一次访问该页面时，会将该标志置为1. 即暗示第一次访问  
> **SH**, bits\[9:8\] ：shareable属性  
> **AP**\[2:1\], bits\[7:6\] ：Data Access Permissions bits,  
> **NS**, bit\[5\] ：Non-secure bit  
> **AttrIndx\[2:0\], bits\[4:2\]**

也就是说，页表的每一个entry中，都指向MAIR寄存器中的一个属性域。也就是页表的每一个entry都配置了一种内存类型。 如下所示，便很好的展示了，MMU页表的每一个page descriptor(也叫entry)都指向一个内存属性类型。  
![在这里插入图片描述][7884805ce97b4233a70d077e300bd273.png]

### 推荐 ###

*  [ARMv8/ARMv9架构从入门到精通][ARMv8_ARMv9] \--博客专栏
 *  [《Armv8/Armv9架构从入门到精通 第二期》][Armv8_Armv9_] \--大课程
 *  [8天入门ARM架构][8_ARM] \--入门课程

[b6530b1e28ba4bf9a08fa151067e3a17.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/c66bd33ed31b4682b8267da3994a0ad3.png
[d3cf4013f6584140ae227321a7473e5c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/cf0a40c6a2e6467bb6b6e37410662701.png
[ae7c8d400fdd42768375b0bc5876818d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/4a8f8efd66d54969b0f1f21dba5a1a7b.png
[84fe278f11134914988766fbb403df61.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/620071b34eab472592b86a5bbb9a0b6a.png
[fab26f7eeb1e429f9ac59513240f664d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/610fa10037d34de09e7d9b957f6b27ad.png
[ecb61dae1533413683ab34b7ec00e0c8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/364c2fd81c3c49eda160624a01e31c4f.png
[110366bf94b24090bc9e74e8927964f8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/0f40a935617c4593980aaf444bd53c65.png
[e3756c924d444d69b3bc7106b24e68e8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/56b3237b8a9a49d2817cdbfcc358192d.png
[6cff0306f8ce427186094da016e8a790.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/9494d42d99b84cc38119bc4c563c7182.png
[4530c4b8e0724093aeae8d8f79c8a688.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/8fa1284510804e5bb4ca453fd03d8e40.png
[5f0b7537b4864c5198c8d6ba92aa4717.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/b55d5b839ae846d7ad9c3aa345c69659.png
[2572680b35d447a6b24ccaccf237ea43.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/b0d7a811ccaa47368061c2cbbd27d8fc.png
[a9d74a9e3e224de5832edfbec68bd348.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/a22b612604ad434cbc635ad5ab8acbdf.png
[81a0188c18b84174984219e707521e0c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/88ab3d6e897b4752b8fb3c6352a501c1.png
[d6622a0ddfa947c08da59a525d85f375.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/5d8775e240604d0fb72b670bd403ca9e.png
[59db0703eda5414183117a77967f17cd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/708bcd2aaaeb473c820ba0badadd45a4.png
[b9a15693c3b54621a535614ad957f4ae.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/7393088d615049d3b4e8cd47d7b36757.png
[1fcd929f248f486bbeff5942f40c7f60.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/8afc362834114abf9e8684e59e2b1381.png
[00cd5f57182f45abb49989c23b02095c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/d8ee9847c81d4f08b6348b106cd9bc45.png
[d12ee1be6f5f4c7a98da1adbc64ebce2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/2681170d07e84c94ae037bfe200593b6.png
[94d764912acf4ced84173a38862e60c2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/d6478789137d45efaf46d5dc4b4cdb96.png
[34a6bcbe93634195bfe286e914684157.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/83cabc85798547f4b0531a2c75f377eb.png
[d3ff2a3ba0774d9ea3ae7e175d57069f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/bedb06607d054420bff0fdf5b762be36.png
[4efea1acfc484106acebbb8838f1cd72.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/928711d543a141619777179222975e09.png
[7884805ce97b4233a70d077e300bd273.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/1a4b70df85c3434c8145a24ddff2fe43.png
[ARMv8_ARMv9]: https://blog.csdn.net/weixin_42135087/article/details/107035789
[Armv8_Armv9_]: https://edu.csdn.net/course/detail/38591
[8_ARM]: https://edu.csdn.net/course/detail/39348