Zynq-7000，APU – MVA可能无法在内部可共享内存区域成功进行缓存线维护操作

描述

在某些定时情况下，针对内部可共享内存区域的MVA数据或统一高速缓存行维护操作可能无法进行到系统的一致性点或统一点。这可能会影响自修改代码。出现此问题时，两个处理器在SMP模式下工作，并启用CP15维护操作的广播。这个问题有一个已知的解决方法。

解

在某些定时情况下，MVA针对内部可共享内存区域的数据或统一高速缓存行维护操作可能无法进行到系统的一致性点或统一点。这可能会影响自修改代码。

出现此问题时，两个处理器在SMP模式下工作，并启用CP15维护操作的广播。

以下方案说明了问题的发生方式：

一个CPU通过MVA执行数据或统一缓存行维护操作，目标是本地脏的内存区域。

第二个CPU在同一时间范围内发出针对该相同内存位置的内存请求。

可能发生竞争条件，导致高速缓存操作未执行到指定的Point，Coherency或Unification。

以下维护操作受到影响：

DCIMVAC：通过MVA将数据或统一缓存行无效为PoC
DCCMVAC：通过MVA清理数据或统一缓存线到PoC
DCCMVAU：通过MVA清理数据或统一缓存线到PoU
DCCIMVAC：通过MVA清理和无效数据或统一缓存线到PoC

当第二个CPU执行以下任一操作时，可能会出现此问题：

任何Load指令产生的读取请求;负载可以是推测性的。
任何Store指令产生的写请求。
由PLD指令产生的数据预取; PLD可以是推测性的。

影响细节

由于不能确保将高速缓存维护操作执行到统一点或连贯点，因此陈旧数据可以保留在数据高速缓存中，并且对于应该已经获得可见性的其他高速缓存代理不可见。
因此，自修改代码可能会失败，写入数据高速缓存的新代码序列未被指令高速缓存看到。

请注意，数据在L1数据端保持一致。从Cortex-A9 MP-Core集群中的其他处理器或从ACP读取的任何数据都将看到正确的数据。同样，来自同一高速缓存行上的Cortex-A9 MP-Core集群中的另一个处理器或来自ACP的任何写入都不会导致数据丢失导致的数据损坏。

请注意，用于自修改代码的内存区域上的错误共享极不可能存在。因此，针对与触发该问题所需的定时窗口内发生的高速缓存操作相同的高速缓存行的写入操作可能不代表真实情况。因此，在自修改代码的情况下触发的问题可能仅限于读操作是推测性加载或盲PLD指令的结果。

此外，从一致性域外部向代理生成数据可能会失败;特别是，当外部DMA引擎完成时，可能没有使高速缓存维护操作的数据目标可见。同样，也很难存在由外部代理（如DMA引擎）访问的内存区域上的错误共享。因此，在为外部DMA代理生成数据时触发的问题可能仅限于读操作是推测性加载或盲PLD指令的结果。

解决方法细节

要解决此问题，ARM建议实施以下内容：

确保自修改代码和要清理到外部代理（如DMA引擎）的数据不存在错误共享（在高速缓存行大小对齐上）。

将未记录的SCU诊断控制寄存器中的位0置于PERIPHBASE地址的偏移0x30处。设置此位将禁用迁移位功能。这迫使脏缓存行被驱逐到较低内存子系统，这是一致性点和另一个处理器读取时的统一点

在缓存维护操作之前插入DSB指令。请注意，如果缓存维护操作在没有其他内存操作的循环内执行，则ARM仅建议在进入循环之前添加DSB。

这将降低发生此问题的可能性，但不会消除它。因此，Xilinx提出了另一种解决问题的方法。在这个解决方法中，执行双重刷新操作：

STR> DSB> DCC_MVA> DSB> DCC_MVA