存储缓冲区和行填充缓冲区如何相互影响？

Question

我正在阅读MDS攻击文件RIDL: Rogue In-Flight Data Load。他们讨论了行填充缓冲区如何导致数据泄漏。 About the RIDL vulnerabilities and the "replaying" of loads问题讨论了漏洞利用的微体系结构细节。

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

[约翰·麦卡宾（John McCalpin）在英特尔论坛上的 How does WC-buffer relate to LFB?中讨论了存储缓冲区和行填充缓冲区的连接方式，但这对我来说并没有使事情变得更清楚。

对于到WB空间的商店，商店数据将保留在商店缓冲区中，直到商店退役之后。退役后，数据可以写入L1数据高速缓存（如果该行存在并且具有写许可权），否则将为存储未命中分配一个LFB。 LFB最终将接收高速缓存行的“当前”副本，以便可以将其安装在L1数据高速缓存中，并且可以将存储数据写入高速缓存。合并，缓冲，排序和“快捷方式”的详细信息尚不清楚....与上述情况相当吻合的一种解释是，LFB用作高速缓存行大小的缓冲区，存储数据在发送之前被合并到其中L1数据缓存。至少我认为这是有道理的，但我可能会忘记一些东西。

我最近才开始阅读乱序执行记录，请原谅我的无知。这是我对存储如何通过存储缓冲区和行填充缓冲区的想法。

1. 存储指令在前端被调度。

它在存储单元中执行。

将存储请求放入存储缓冲区（地址和数据）

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

如果它错过了L1d缓存，则将请求放入行填充缓冲区中

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

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

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

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

---

问题

1. 如果商店缓冲区已经存在以跟踪出库请求，为什么我们需要行填充缓冲区？
2. 事件的顺序在我的描述中是否正确？

我正在阅读MDS攻击论文RIDL：Rogue飞行中数据加载。他们讨论了行填充缓冲区如何导致数据泄漏。有“关于RIDL”漏洞和“正在重放...”>

如果商店缓冲区已经存在以跟踪出库请求，为什么我们需要行填充缓冲区？

存储缓冲区用于按顺序跟踪它们退出的[[before

，并且在它们退出后但在提交到L1高速缓存之前）。从概念上讲，存储缓冲区是一个完全本地的东西，实际上并不关心高速缓存未命中。存储缓冲区以各种大小的单个存储的“单位”进行交易。像Intel Skylake这样的芯片都有store buffers of 50+ entries。

行填充缓冲区主要处理

both

加载并将该miss丢失存储在L1高速缓存中。本质上，它是从L1高速缓存到其余内存子系统的路径，并以高速缓存行大小的单位进行交易。如果加载或存储命中L1缓存1，我们不希望LFB参与其中。诸如Skylake之类的英特尔芯片的LFB条目要少得多，可能为10到12。

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

非常接近。这是我要更改您的列表的方式：

[一条存储指令被解码并分成存储数据和存储地址单元，它们被重命名，安排并为其分配了存储缓冲区条目。
1. 存储库以任何顺序执行（两个子项目可以以任何顺序执行，这主要取决于首先满足其依赖关系的哪个）。
2. 存储数据uop将存储数据写入存储缓冲区。
   1. 商店地址uop进行V-P转换并将地址写入商店缓冲区。
   2. 在所有较旧的指令都已退休时，存储指令
   3. 退休
   。这意味着该指令不再是推测性的，并且可以使结果可见。此时，存储区仍保留在存储缓冲区中，称为senior
存储区。

现在，存储将一直等待，直到它位于存储缓冲区的最前面（这是最早的未提交存储），此时，如果关联的缓存行存在于L1中，它将提交（成为全局可观察到的）L1。 L1。

如果该行是

不存在

（存储L1高速缓存未命中），则该行必须从内存子系统中获得：如果尚未分配整个行，则会为整个行分配一个LFB。这是所谓的request for owner（RFO）请求，这意味着内存层次结构应将return the line设置为适合修改的排他状态，而不是仅适合于读取的共享状态（这会使副本无效其他专用缓存中存在的行数）。在未命中情况下，LFB最终返回了该行的全部内容，该内容已提交给L1，并且挂起的存储现在可以提交了。

这是该过程的粗略近似。在某些或所有芯片上，某些细节可能会有所不同，包括尚未完全了解的细节。

作为一个示例，以上述顺序，直到商店到达商店队列的开头才获取商店未命中行。实际上，商店子系统可以实现一种

RFO prefetch

类型，其中检查商店队列中是否有即将到来的商店，并且如果L1中不存在这些行，则提早开始请求（对L1的实际可见提交仍会必须按顺序发生在x86上，或者至少“好像”按顺序发生。]因此，请求和LFB使用可能最早在第3步完成时发生（如果RFO预取仅在商店退役后才适用），或者甚至在2.2结束时发生，如果初级商店需要预取。

作为另一个示例，步骤6描述了从内存层次结构返回并被委托给L1的行，然后存储提交。实际上，挂起的存储实际上可能与返回的数据合并，然后将其写入L1。即使在未命中的情况下，存储也有可能离开存储缓冲区，而只是在LFB中等待，从而释放了一些存储缓冲区条目。

---

1

对于在L1缓存中命中的存储，有一个[[suggestion实际涉及LFB：每个存储实际上都进入一个合并缓冲区（可能只是一个LFB）在提交给高速缓存之前，将针对同一高速缓存行的一系列存储合并到高速缓存中，只需要访问一次L1。这还没有得到证明，但是无论如何，它实际上并不是LFB主要用途的一部分（从我们甚至无法真正确定它是否正在发生的事实中可以明显看出）。

Answer 1

如果商店缓冲区已经存在以跟踪出库请求，为什么我们需要行填充缓冲区？