intel - 在硬件中断之前如何处理分支预测错误

Question

特定向量(未屏蔽)发生硬件中断，CPU 检查 IF 标志并将 RFLAGS、CS 和 RIP 压入堆栈，同时后端仍有指令完成，这些指令的分支预测之一被证明是错误的.通常管道会被刷新，前端开始从正确的地址获取，但在这种情况下，一个中断正在进行中。

When an interrupt occurs, what happens to instructions in the pipeline?

我已经阅读了这篇文章，很明显，一个解决方案是立即从管道中刷新所有内容，以免发生这种情况，然后生成将 RFLAGS、CS、RIP 推送到 TSS 中内核堆栈位置的指令；然而，问题出现了，它如何知道与最新架构状态相关联的 (CS:)RIP，以便能够将其推送到堆栈上(假设前端 RIP 现在领先)。这类似于端口 0 上采取的分支执行单元如何知道 (CS:)RIP 的问题，即当采取预测结果错误时应该获取什么——地址是否编码到指令中以及预言？想到trap/exception也会出现同样的问题，CPU需要把当前指令(fault)或者下一条指令(trap)的地址压入内核栈，但是这条指令的地址是怎么算出来的当它在管道中途时 - 这让我相信地址必须被编码到指令中并使用长度信息计算出来，这可能全部在预解码阶段完成..

Answer 1

CPU 可能会丢弃 ROB 的内容，在服务中断之前回滚到最新的退休状态。

飞行中的分支未命中不会改变这一点。取决于 CPU(较旧/较简单)，当中断到达时，它可能已经在回滚到退休状态并由于分支未命中而刷新的过程中。

正如@Hadi 所说，CPU 可以在那时选择退出分支(中断插入 CS:RIP 指向正确的分支目标)，而不是在从中断返回后重新执行它。

但这只有在分支指令已经准备好退出时才有效:没有比分支更旧的指令仍未执行。由于尽早发现分支未命中很重要，因此我假设分支恢复在执行期间发现错误预测时开始，而不是等到它退休时才开始。 (这与其他类型的故障不同:例如 Meltdown 和 L1TF 基于故障负载不触发 #PF 故障处理，直到它达到退休，因此 CPU 确定在真正的执行路径上确实存在故障。您不想开始昂贵的管道刷新，直到您确定它没有处于错误预测或早期故障的阴影中。)

但是由于分支未命中不会出现异常，因此在我们首先确定分支指令是正确路径的一部分之前，可以尽早开始重定向前端。

例如cmp [cache_miss_load], 123/jeq预测错误，但在很长一段时间内不会被发现。然后在那个错误预测的阴影下，一个 cmp eax, 1/je在“错误”的路径上运行并发现了错误预测。通过快速恢复，在更早的错误预测被发现之前，从“正确”路径刷新和提取/解码/执行的 uops 可以开始。

为了保持较低的 IRQ 延迟，CPU 不会倾向于为执行中的指令提供额外的退役时间。此外，任何在存储缓冲区中仍有数据(尚未提交到 L1d)的退役存储必须在中断处理程序提交的任何存储之前提交。但是中断正在序列化(我认为)，并且处理程序中的任何 MMIO 或端口 IO 都可能涉及内存屏障或强有序存储，因此如果它们涉及存储，让更多指令退出会损害 IRQ 延迟。 (一旦存储退出，即使其数据仍在存储缓冲区中，它也肯定需要发生)。

乱序的后端总是知道如何回滚到一个已知良好的退休状态； ROB 的全部内容总是被认为是推测性的，因为任何加载或存储都可能出错，许多其他指令也是如此1。 过去分支的投机并不是特别特别的。

分支的特殊之处在于具有额外的快速恢复跟踪(Nehalem 和更新版本中的分支顺序缓冲区)，因为它们预计会在正常操作期间以不可忽略的频率进行错误预测。见 What exactly happens when a skylake CPU mispredicts a branch?一些细节。尤其是大卫·坎特的名言:

Nehalem enhanced the recovery from branch mispredictions, which has been carried over into Sandy Bridge. Once a branch misprediction is discovered, the core is able to restart decoding as soon as the correct path is known, at the same time that the out-of-order machine is clearing out uops from the wrongly speculated path. Previously, the decoding would not resume until the pipeline was fully flushed.

(这个答案故意非常以英特尔为中心，因为您将其标记为 intel ，而不是 x86 。我假设 AMD 做了类似的事情，并且其他 ISA 的大多数乱序 uarches 可能大致相似。除了内存顺序在内存模型较弱的 CPU 上不会出现错误推测，在这种模型中，允许 CPU 对负载进行明显的重新排序。)

脚注 1:也可以 div ，或任何 FPU 指令(如果 FP 异常未屏蔽)。并且非规范的 FP 结果可能需要微码辅助来处理，即使 FP 异常像默认情况下一样被屏蔽。

在 Intel CPU 上，内存顺序错误推测也可能导致管道核攻击(在较早的加载完成之前推测性地提前完成加载，但在 x86 内存模型表示加载可以取其值之前缓存丢失了其行的副本)。