Zynq-7000 SoC，APU – 当CPU和ACP访问相同的高速缓存行时，SMP模式下可能发生系统死锁

描述

在非常罕见的情况下，一些ACP请求处于危险状态并且CPU的多个完整高速缓存行写入会导致SCU中的仲裁问题，从而导致处理器死锁。对于要发生的情况，CPU必须在SMP模式和相干存储器区域中运行，而一个CPU在与另一个CPU读取相同的高速缓存行几乎同时写入高速缓存行，并且ACP也发出了请求到缓存行。

该问题影响SMP系统并且非常不可能，因为时序窗口非常小并且三个请求都以一个高速缓存行为中心。如果在操作系统中无法避免这种情况，则可以设置控制位，以便不会出现问题。

解

在非常罕见的情况下，一些ACP请求处于危险状态，来自两个处理器的完整缓存行写入可能导致SCU中的仲裁问题，从而导致处理器死锁。

当两个处理器在SMP模式下工作并在相干存储器区域（回写共享）时，会遇到此问题。两个处理器需要执行完整的高速缓存行写入，并且ACP需要执行对某些处理器请求有危险的相干请求。

下面的示例描述了可能导致死锁的一种情况：

CPU0在地址A执行完整的高速缓存行写入（此写入在SCU中存在危险，表示其他CPU或ACP已在执行对此高速缓存行的访问）。
然后CPU0在地址B执行完整的高速缓存行写入。
然后CPU0在地址C执行读取请求（此读取在SCU中存在危险，其中来自下面提到的CPU1的第二个请求）。

大约在同一时间：

CPU1在地址D执行完整的高速缓存行写入（此写入在SCU中存在危险，表示其他CPU或ACP已在执行对此高速缓存行的访问）
CPU1在地址C执行完整的高速缓存行写入
CPU1在地址B执行读取请求（此读取在SCU中存在危险，其中来自上述CPU0的第二个请求）

最后：

ACP在地址B执行读取或写入请求（此请求与CPU1的第3个请求有关）

在这种情况下，在极少数情况下，所有请求者（CPU0，CPU1和ACP）最终可能最终处于危险之中。 SCU中的伪循环仲裁可能最终仍然停留在ACP上，因此CPU和ACP请求都无法前进，导致系统死锁。

影响细节

影响很小。当它发生时，问题会导致系统死锁。值得注意的是，导致此死锁的情况非常罕见：它需要两个处理器编写完整的一致高速缓存行，而不需要任何信号量，以及ACP访问相同的行;这意味着后面这些访问不是确定性的。除了可以发生缺陷的微架构时序条件的极端罕见之外，这解释了为什么预计该问题不会在实际系统中引起任何重大故障。

解决方法细节

通过设置CP15 c15 0 c0 1中未记录的诊断控制寄存器的第21位，可以解决此问题。

该位只能以安全状态写入，具有以下读/修改/写代码序列：

MRC p15,0，rt，c15，c0,1
ORR rt，rt，＃0x200000
MCR p15,0，rt，c15，c0,1

设置此位后，将禁用总线接口单元中的直接驱逐优化，从而防止发生故障。

设置此位可能会阻止处理器在执行完整缓存行写入的密集流程时利用全部带宽，并且系统中可能会出现轻微的性能下降。

请注意，如果已在未记录的诊断控制寄存器中设置了以下两位中的任何一位，则不会发生故障：

bit 23禁用Read-Allocate模式
bit 22禁用Write Allocate Wait模式