ARM架构下如何使用break-before-make规则安全地动态更改MMU 页表条目（ translation table entries）

我们在使用ARM MMU一般会遵循如下流程：

1. 配置TTBR、TCR 和MAIR等MMU配置寄存器。
2. 配置页表 pagetable，VA 和PA的映射关系，地址空间属性等等。
3. 使能MMU和cache。

即先配置好pagetable再使能MMU和cache，在MMU和cache使能之后，如果想要在程序运行时，动态改变page table或者称为translation table，需要遵循一定的规则（break-before-make）才能保证其安全性和可靠性。

改变pagetable不仅仅是改变VA 和PA的映射关系，地址空间属性，它还包括：

• 改变内存类型，sharable属性以及cacheable属性。
• IA（Input Address）和OA（Output Address）的映射关系发生改变。在VA（virtual Address）到PA（Physical Address）的转换过程中，可能存在多级页表的转换，每一次转换都是一次IA到OA的的转换。
• 改变了OA地址空间的写权限。
• 页表描述符的bit[51] ，Dirty Bit Modifier (DBM)为1，使能了硬件更新dirty 状态的功能。
• 改变了页表的大小。从一个小页表改成一个大页表，比如用Block descriptor替换 stage 2 Table descriptor。从一个大页表改成一个小页表，比如用Table descriptor替换成stage 2 Table descriptor。
• 创建了一个全局的页表条目，可能会覆盖掉在TLB中的非全局页表条目。

比如在一个单核多线程的系统中，MMU和cache被使能，一个线程正在读写某段地址空间，如果此时另外一个线程想要改变这段空间的pagetable，我们要确保新的page table和旧的page table不会同时起作用，换句话说，所有线程在任意时刻，要么全部使用新的page table，要么全部使用旧的page table。不然可能会出现在TLB中可能存在多个指向相同地址的TLB条目的问题。不仅如此，TLB中缓存的是老旧的page table 条目，事实上真实内存中的page table条目已经发生改变，这会导致：

• 影响 cache coherency
• 打断单拷贝的原子性属性（ single-copy atomicity properties）
• 打断了程序和数据顺序（ordering）保证，或者是单核处理器场景。
• Exclusive monitor的状态机被重置，导致Exclusive access失败。

如何避免这种现象发生呢？ ARM架构强烈建议使用 break-before-make规则来保证在多线程甚至是多核场景下的 page table一致性，break-before-make实际上就是生效前先禁止原则，它有如下步骤：

1. 先将页表中老旧的页表条目（old translation table entry）用无效的条目来替代，也就是先将该转换关系给禁止。
2. 执行一个 DSB 内存屏障指令，以确保该替换操作生效。
3. 针对该 页表条目执行一个广播的TLB invalidate 指令，将TLB中缓存的旧页表条目信息删除。
4. 执行一个 DSB 内存屏障指令，以确保TLB invalidate指令操作生效。
5. 然后将新的页表条目写入。
6. 执行一个 DSB 内存屏障指令，以确保新的页表条目更新成功。

使用 break-before-make的方式在程序运行时动态更新页表，虽然可以一定程度上保证单核多线程场景下的安全性，但仍需要注意以下两点：

• 不要动态改变当前正在执行的代码所在的地址空间的页表。比如，更改页表的代码程序正在地址空间0xA000到0xB000上执行，而更改页表条目的对象地址空间正是0xA000到0xB000，此时就算使用break-before-make也无法保证程序的安全性。
• 尽量不要动态改变当前正在访问的数据空间的页表，尤其是在多核多线程系统下，如果多核共用一个page table，此时不仅要使用break-before-make方式，还要考虑多核间的同步问题。