Cache Maintenance-通过set/way对cache进行clean和invalidate操作-汇编代码详解

怼烎@ 2022-08-29 10:56 249阅读 0赞

[ Cache Maintenance-关于cache 清除（invalidate）和清理（clean）操作的基础知识][Cache Maintenance-_cache _invalidate_clean]

对于cache清理清除操作不熟悉的同学可以先看看上面相关的基础知识。

**目录**

代码解析

代码逐行详解

通过CLIDR\_EL1获取可操作的缓存级别数

CLIDR\_EL1寄存器

通过CSSELR\_EL1来指定需要操作的cache level和type

通过CCSIDR\_EL1获取缓存的way 和 set 数量

将level number 、way number以及set number融合到一个寄存器

使用循环和递减操作进行逐个way、逐个set和逐个level的清理清除缓存

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

代码为官方文档中示例代码：

[DEN0024A\_v8\_architecture\_PG.pdf][DEN0024A_v8_architecture_PG.pdf]

先直接上代码：

MRS X0, CLIDR_EL1 
    AND W3, W0, #0x07000000 // Get 2 x Level of Coherence 
    LSR W3, W3, #23 
    CBZ W3, Finished 
    MOV W10, #0              // W10 = 2 x cache level 
    MOV W8, #1               // W8 = constant 0b1
    Loop1: 
    ADD W2, W10, W10, LSR #1 // Calculate 3 x cache level 
    LSR W1, W0, W2           // extract 3-bit cache type for this level
    AND W1, W1, #0x7 
    CMP W1, #2 
    B.LT Skip                // No data or unified cache at this level
    MSR CSSELR_EL1, X10      // Select this cache level 
    ISB                      // Synchronize change of CSSELR
    MRS X1, CCSIDR_EL1       // Read CCSIDR
    ADD W2, W2, #4           // W2 = log2(linelen)-4 
    AND W2, W1, #7           // W2 = log2(linelen)
                                   
    UBFX W4, W1, #3, #10     // W4 = max way number, right aligned 
    CLZ W5, W4               /* W5 = 32-log2(ways), bit position of way in DC operand */
    LSL W9, W4, W5           /* W9 = max way number, aligned to position in DC operand */
    LSL W16, W8, W5          // W16 = amount to decrement way number per iteration
    Loop2: 
    UBFX W7, W1, #13, #15    // W7 = max set number, right aligned 
    LSL W7, W7, W2           /* W7 = max set number, aligned to position in DC operand */
    LSL W17, W8, W2          // W17 = amount to decrement set number per iteration 
    Loop3: 
    ORR W11, W10, W9         // W11 = combine way number and cache number
    ORR W11, W11, W7         // and set number for DC operand
    DC CSW, X11              // Do data cache clean by set and way
    SUBS W7, W7, W17         // Decrement set number
    B.GE Loop3
    SUBS X9, X9, X16         // Decrement way number
    B.GE Loop2
    Skip: 
    ADD W10, W10, #2         // Increment 2 x cache level
    CMP W3, W10 
    DSB                      /* Ensure completion of previous cache maintenance operation */
    B.GT Loop1
    
    Finished:

# 代码解析 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70][]

**整个程序的流程总结如下：**

1.  读取CLIDR\_EL1寄存器，获取缓存级别数（level number），也就是可以操作的缓存总共有多少个级别
2.  写入CSSELR\_EL1寄存器，选择需要操作的寄存器级别以及类型
3.  读取CCSIDR\_EL1寄存器，获取对应寄存器的way number 和 set number
4.  根据获取的level number，way number以及set number，使用循环，逐个level，逐个way以及逐个way对cache line进行清理清除操作

要获取指定缓存的level number，way number以及set number等信息，依赖于对CLIDR、CSSELR以及CCSIDR三个寄存器的读写操作。

相关寄存器的详解参考文章：

[关于cache maintenance 操作的四个寄存器（CTR，CLIDR，CSSELR，CCSIDR）解析][cache maintenance _CTR_CLIDR_CSSELR_CCSIDR]

# 代码逐行详解 #

## 通过CLIDR\_EL1获取可操作的缓存级别数 ##

> MRS X0, CLIDR\_EL1 **//读取CLIDR\_EL1的数据到X0**  
> AND W3, W0, \#0x07000000 **// 读取X0的\[26:24\]字段到W3，此字段为LoC，表示可操作的总的级别数**   
> LSR W3, W3, \#23 **// 算术右移23位，注意不是24位，所以此时W3中保存的结果应该是cache level number 的2倍**  
> CBZ W3, Finished **// 如果可操作的cache level数为0，说明没有需要清理清除的cache，直接跳转到程序结束**  
> MOV W10, \#0 **// W10为cache level 的步进值**   
> MOV W8, \#1 **// W8为常数1**

**0x07000000的二级制编码**

![20210802093644275.png][]

## CLIDR\_EL1寄存器 ##

**Get cache level and type**

![20210730175111692.png][]

*  **LoC**：the last level of cache that must be cleaned or invalidated
 *  **Ctype字段解析**：

![20210730175120101.png][]

## 通过CSSELR\_EL1来指定需要操作的cache level和type ##

> Loop1:  
> ADD W2, W10, W10, LSR \#1   **// W2 = W10 + W10 / 2，联系上下文可知：W10的取值为：0，2，4，...，所以W2的取值为0，3，6，...,**  
> LSR W1, W0, W2 **// W2为3的倍数，是为了方便取对应level的Ctype**  
> AND W1, W1, \#0x7  **// 取出对应的Ctype，Ctype字段为3位**  
> CMP W1, \#2 **// 与2作比较，通过上面的Ctype字段解析可知，Ctype小于2时，只有指令缓存或者无缓存**  
> B.LT Skip **// 如果此level中没有数据缓存或者统一缓存，直接跳过，检查next level的缓存**  
> MSR CSSELR\_EL1, X10 **// 使用X10（将W10扩充到64位）来选择需要操作的cache level和type，X10的取值为：0b0000,0b0010,0b0100,...，通过bit\[0\]来选择cache type，bits\[3:1\]来选择cache level**

**CSSELR\_EL1寄存器：**

![20210730175140592.png][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 1][]

![20210730175144695.png][]

**由于X10的取值为：0b0000,0b0010,0b0100，...。**

**所以InD字段始终为0，始终指定数据缓存或统一缓存为操作对象。**

**X10的\[3:1\]表示指定的cache level，右上可知，每次选择的cache level 为：0b000,0b001,0b010。从Level 1逐级递增。**

## 通过CCSIDR\_EL1获取缓存的way 和 set 数量 ##

> ISB // 数据屏障，同步上下文  
> MRS X1, CCSIDR\_EL1 // 读取CCSIDR到X1  
> ADD W2, W2, \#4 // W2 = log2(linelen)-4   
> AND W2, W1, \#7 // W2 = log2(linelen)，获取cache line size   
> UBFX W4, W1, \#3, \#10 // 抽取W1的\[12:3\]，保存到W4，W4 = max way number, right aligned   
> CLZ W5, W4 **// CLZ计算出需要左移的位数，使得W9的最高位为1，有效位为\[31:22\]**  
> LSL W9, W4, W5 /\* W9 = max way number, aligned to position in DC operand \*/  
> LSL W16, W8, W5 // W16 = 移位后的每次迭代中way递减的数值，该数值本来为1，由于原数值W4左移了W5位，所以递减的步进值也要左移W5位  
> Loop2:  
> UBFX W7, W1, \#13, \#15 // W7 = max set number, right aligned ，抽取W1的\[27:13\]，表示最大的set number
> 
> //原数值W7左移W2位，W2为line size，所以递减的步进值也需要左移W2位  
> LSL W7, W7, W2  /\* W7 = max set number, aligned to position in DC operand \*/  
> LSL W17, W8, W2 // W17 = amount to decrement set number per iteration

**Get way and set number** \- 寄存器示例：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 2][]

此时的CCSIDR\_EL1的值为0x7007E03A，对应的二进制编码：

![20210730175200309.png][]

CCSIDR\_EL1的字段解析：

![20210730175205697.png][]

由上可知：Level 1缓存的Data 缓存和Unified缓存中有0x40（64）个set，0x8（8）个way，每个cache line的大小为16个字（word）= 64 个字节（byte）

## 将level number 、way number以及set number融合到一个寄存器 ##

> Loop3:  
> ORR W11, W10, W9 // W10中保存的是当前level number乘以2的值，W9中保存的是经过移位后的way number，通过“或”运算，将两个值融合到W11中  
> ORR W11, W11, W7 // 再将移位后的set numbe放入W11中

W11此时包含了level number 、way number以及set number等三个数据，示意图如下：

![20210730175231558.png][]

## 使用循环和递减操作进行逐个way、逐个set和逐个level的清理清除缓存 ##

> DC CSW, X11 // 通过传入set number和way number 进行 data cache 的clean操作  
> SUBS W7, W7, W17 // 对 set number递减  
> B.GE Loop3 // 确保当前way下的所有的set都被clean一遍  
> SUBS X9, X9, X16 // 对way number递减  
> B.GE Loop2  // 确保所有的way都被clean一遍  
> Skip:  
> ADD W10, W10, \#2 // 对cache level递增，开始操作下一级cache  
> CMP W3, W10 //是否所有可用的cache都clean了一遍  
> DSB /\* 数据缓存 \*/  
> B.GT Loop1 //如果当前还有其他等级的cache未清理，继续跳转

以上循环的伪代码如下：

> for(l = 1; l <= Levels; l++)
> 
>  for(w = Ways; w>0; w--)
> 
>  for(s = Sets; s >0; s--)
> 
> **clean( level(l) + set(s) + way(w) )**

经过这三个for循环，就可以遍历所有级别、所有way、以及所有set中的cache line。注意，无论是基于VA还是基于way和set的清理清除操作，操作对象的最小单位都是cache line。

The cache maintenance instructions by set/way can clean or invalidate, or both, the entirety of one or more levels of cache attached to a PE

set/way的缓存维护指令可以清除或使连接到PE的一个或多个级别的缓存全部失效，或者两者都失效.

Since the set/way instructions are performed only locally, there is no guarantee of the **atomicity** of cache maintenance between different PEs,even if those different PEs are each executing the same cache maintenance instructions at the same time.

即使这些不同的PE在同一时间执行相同的缓存维护指令由于set/way指令仅在本地执行，因此无法保证不同pe之间的cache维护的原子性

*  Arm strongly discourages the use of set/way instructions to manage coherency in coherent systems
    
     *  Arm强烈反对使用set/way指令来管理一致性系统中的一致性
 *  maintenance by set/way does not happen on multiple PEs,
 *  cannot be made to happen atomically for each address on each PE.
    
     *  set/way维护不会发生在多个PE上，也不能对每个PE上的每个地址进行原子化维护。

[Cache Maintenance-_cache _invalidate_clean]: https://blog.csdn.net/luolaihua2018/article/details/119251006
[DEN0024A_v8_architecture_PG.pdf]: https://winddoing.github.io/downloads/arm/DEN0024A_v8_architecture_PG.pdf
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70]: /images/20220829/b4c5ac685fa5451797e8d2eafc36d738.png
[cache maintenance _CTR_CLIDR_CSSELR_CCSIDR]: https://blog.csdn.net/luolaihua2018/article/details/119271704
[20210802093644275.png]: /images/20220829/fcc30f7f939043d1a4a2bd370385cffb.png
[20210730175111692.png]: /images/20220829/9421b652c2e34792871efc56bcce9cab.png
[20210730175120101.png]: /images/20220829/b9fb299b55fb498caa9c9eb7aeca9287.png
[20210730175140592.png]: /images/20220829/053c833912c94fe093e051d2c7228b14.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 1]: /images/20220829/00953cb89c324ed1b142bbaf97a60234.png
[20210730175144695.png]: /images/20220829/460d5cfef67f414d9486a9a0c7493c33.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b2xhaWh1YTIwMTg_size_16_color_FFFFFF_t_70 2]: /images/20220829/3f3c67d3125d48149aaf2e8cd3c89935.png
[20210730175200309.png]: /images/20220829/20a199348bab43969842bfd2e48dcdf9.png
[20210730175205697.png]: /images/20220829/c2867d694ae24ec2a3e0afbcc915a673.png
[20210730175231558.png]: /images/20220829/cfb0dec1a9bf4e32bee6e7ccd6895f74.png