x86 - 存储缓冲区和行填充缓冲区如何相互作用？

Question

我正在阅读 MDS 攻击论文 RIDL: Rogue In-Flight Data Load .他们讨论了 Line Fill Buffer 如何导致数据泄漏。有About the RIDL vulnerabilities and the "replaying" of loads讨论漏洞利用的微架构细节的问题。

阅读该问题后，我不清楚的一件事是，如果我们已经有了存储缓冲区，为什么还需要行填充缓冲区。

John McCalpin 在 How does WC-buffer relate to LFB? 中讨论了存储缓冲区和行填充缓冲区是如何连接的在英特尔论坛上，但这并没有真正让我更清楚。

For stores to WB space, the store data stays in the store buffer until after the retirement of the stores. Once retired, data can written to the L1 Data Cache (if the line is present and has write permission), otherwise an LFB is allocated for the store miss. The LFB will eventually receive the "current" copy of the cache line so that it can be installed in the L1 Data Cache and the store data can be written to the cache. Details of merging, buffering, ordering, and "short cuts" are unclear.... One interpretation that is reasonably consistent with the above would be that the LFBs serve as the cacheline-sized buffers in which store data is merged before being sent to the L1 Data Cache. At least I think that makes sense, but I am probably forgetting something....

我最近才开始阅读乱序执行，所以请原谅我的无知。这是我关于商店如何通过商店缓冲区和行填充缓冲区的想法。

存储指令在前端被调度。

它在存储单元中执行。

存储请求被放入存储缓冲区(地址和数据)

一个无效的读请求从存储缓冲区发送到缓存系统

如果未命中 L1d 缓存，则请求将放入行填充缓冲区

行填充缓冲区将无效读取请求转发到 L2

某些缓存收到无效读取并发送其缓存行

存储缓冲区将其值应用于传入的缓存行

嗯？行填充缓冲区将条目标记为无效

问题

如果存储缓冲区已经存在，我们为什么还需要行填充缓冲区来跟踪超出的存储请求？

我的描述中事件的顺序是否正确？

Answer 1

Why do we need the Line Fill Buffer if the store buffer already exists to track outsanding store requests?

存储缓冲区用于按顺序跟踪存储，无论是在它们退休之前还是在它们退休之后但在它们提交到 L1 缓存之前。从概念上讲，存储缓冲区是一个完全本地的东西，它并不真正关心缓存未命中。商店缓冲区处理各种大小的各个商店的“单位”。像 Intel Skylake 这样的芯片有 store buffers of 50+ entries .
行填充缓冲区主要处理 L1 缓存中未命中的加载和存储。本质上，它是从 L1 缓存到内存子系统其余部分的路径，并处理缓存行大小的单位。如果 L1 缓存中的加载或存储命中，我们不希望 LFB 参与其中。像 Skylake 这样的英特尔芯片的 LFB 条目要少得多，可能只有 10 到 12 个。

Is the ordering of events correct in my description?

很接近了。以下是我如何更改您的列表:

存储指令被解码并拆分为存储数据和存储地址微指令，它们被重命名、调度并为它们分配了存储缓冲区条目。

store uops 以任何顺序或同时执行(这两个子项可以以任一顺序执行，主要取决于哪个首先满足其依赖关系)。

存储数据 uop 将存储数据写入存储缓冲区。

存储地址 uop 执行 V-P 转换并将地址写入存储缓冲区。

在所有旧指令都已停用的某个时刻，存储指令将停用。这意味着指令不再是推测性的，并且结果可以是可见的。此时，该商店仍保留在商店缓冲区中，称为高级商店。

存储现在等待直到它位于存储缓冲区的头部(它是最旧的未提交存储)，此时它将提交(变为全局可观察)到 L1，如果相关的缓存线存在于 L1 中MESIF 修改或独占状态。 (即该核心拥有线路)

如果该行不存在于所需状态(完全丢失，即缓存未命中，或存在但处于非排他状态)，则必须从内存子系统:如果尚未分配，则为整行分配一个 LFB。这就是所谓的所有权请求(RFO)，这意味着内存层次结构应该return the line处于适合修改的独占状态，而不是仅适合读取的共享状态(这会使任何其他私有(private)缓存中存在的行的副本无效)。

将 Shared 转换为 Exclusive 的 RFO 仍必须等待响应以确保所有其他缓存已使其副本无效。对这种无效的响应不需要包含数据的副本，因为该缓存已经有一个。它仍然可以称为 RFO；重要的部分是在修改一行之前获得所有权。
6. 在未命中的情况下，LFB 最终会返回该行的全部内容，该内容已提交给 L1，挂起的存储现在可以提交 3。
这是该过程的粗略近似。某些或所有芯片上的某些细节可能有所不同，包括不太了解的细节。
作为一个示例，在上述顺序中，直到商店到达商店队列的头部时才提取商店未命中行。实际上，商店子系统可能会实现一种 RFO 预取，其中检查商店队列是否有即将到来的商店，如果 L1 中不存在这些行，则提前启动请求(对 L1 的实际可见提交仍然必须在顺序，在 x86 上，或至少“好像”按顺序)。
因此，请求和 LFB 的使用可能最早在第 3 步完成时发生(如果 RFO 预取仅在商店退出后才适用)，或者甚至可能早在 2.2 完成时发生，如果初级商店受到预取。
作为另一个例子，步骤 6 描述了从内存层次结构返回并提交到 L1 的行，然后存储提交。有可能挂起的存储实际上与返回的数据合并，然后写入 L1。即使在未命中的情况下，存储也可能离开存储缓冲区并在 LFB 中等待，从而释放一些存储缓冲区条目。

1 在 L1 缓存中命中的存储的情况下，建议实际上涉及 LFB:每个存储在提交到缓存之前实际上进入组合缓冲区(可能只是一个 LFB)，这样一系列针对相同缓存行的存储组合在缓存中，并且只需要访问 L1 一次。这尚未得到证实，但在任何情况下，它都不是 LFB 主要用途的一部分(更明显的是，我们甚至无法真正判断它是否正在发生)。
2 在之前和退休之前保存商店的缓冲区可能是两种完全不同的结构，具有不同的大小和行为，但在这里我们将它们称为一种结构。
3 所描述的场景涉及在存储缓冲区的头部等待直到相关行返回的存储未命中。另一种情况是将存储数据写入用于请求的 LFB，并且可以释放存储缓冲区条目。这可能允许在发生未命中时处理一些后续存储，但要遵守严格的 x86 排序要求。这可能会增加商店 MLP。