2

这参考了 InteI 的软件开发人员手册（订单号：325384-039US 2011 年 5 月），第 4.10.4.4 节“延迟无效”描述了 TLB 条目无效的潜在延迟，这可能在访问其分页结构条目的内存时导致不可预测的结果已经变了。

手册说……“在某些情况下，所需的失效可能会延迟。软件开发人员应该明白，在修改分页结构条目和执行第 4.10.4.2 节中推荐的失效指令之间，处理器可以使用转换基于分页结构条目的旧值或新值。以下项目描述了延迟失效的一些潜在后果： 如果修改分页结构条目以将 R/W 标志从 0 更改为 1，对由该条目控制其翻译的线性地址的写访问可能会也可能不会导致页面错误异常。 ”

让我们假设一个简单的情况，其中针对线性地址修改了页面结构条目（r/w 标志从 0 翻转到 1），然后立即调用相应的 TBL 无效指令。我的问题是——作为 TLB 延迟失效的结果，即使在调用 TLB 失效后，对相关线性地址的写访问也不会出错（页面错误）？

还是说“延迟失效”只能在页面结构发生变化的线性地址的“失效”指令没有发出时才会导致不可预知的结果？

4

1 回答 1

1

TLB 透明地乐观地不会因 CR3 更改而取消缓存。TLB 条目用地址空间的唯一标识符标记并留在 TLB 中，直到它们被错误的进程触及（在这种情况下 TLB 条目被丢弃）或地址空间被恢复（在这种情况下TLB 在地址空间更改时被保留）。

这一切都对 CPU 透明地发生。您的程序（或操作系统）不应该能够区分此行为与 TLB 实际被 TLB 失效而失效之间的区别，除非通过以下方式：

  • A）时间 - 即 TLB 乐观地不取消缓存更快（这就是他们这样做的原因）
  • B) 在某些极端情况下，这种行为有些不确定。如果您修改您所在的代码页或触摸刚刚更改的内存，则 TLB 的旧值可能仍然存在（即使在 CR3 更改后）。

解决方案是：

  • 1) 通过 invlpg 指令强制更新 TLB。这会清除 TLB 条目，在下一次触摸页面时触发 TLB 读入。
  • 2) 通过 CR0 寄存器禁用和重新启用分页。
  • 3) 通过 CR0 中的缓存禁用位或在 TLB 的所有页面上将所有页面标记为不可缓存（标记为不可缓存的 TLB 条目在使用后会自动清除）。
  • 4) 改变代码段的模式。

请注意，这是真正未定义的行为。过渡到 SMM 可能会使 TLB 无效，也可能不会，从而使这种情况处于竞争状态。不要依赖这种行为。

于 2012-05-15T20:36:58.560 回答