Intel 处理器可以延迟 TLB 失效吗？
参考 Intel 的软件开发人员手册（订购号：325384-039US，2011 年 5 月），第 4.10.4.4 节“延迟失效”描述了 TLB 条目失效的潜在延迟，这可能会在访问其分页结构条目的内存时导致不可预测的结果已被更改。
手册说... “在某些情况下，所需的失效可能会延迟。软件开发- 操作员应该明白，在分页结构条目的修改之间 和执行第 4.10.4.2 节中建议的无效指令， 处理器可以使用基于旧值或新值的转换 分页结构条目。以下项目描述了一些潜在的后果 延迟失效的顺序： 如果修改分页结构条目以将 R/W 标志从 0 更改为 1，则写入 访问由该条目控制转换的线性地址可能或 可能不会导致页错误异常。”
让我们假设一个简单的情况，其中页结构条目被修改为线性地址（r/w 标志从 0 翻转到 1），然后相应的TBL 失效指令被立即调用，我的问题是——作为 TLB 延迟失效的结果，即使在调用 TLB 失效之后，也可能对相关线性地址进行写访问。 没有错误（页错误）？
还是只有在页结构发生变化的线性地址没有发出“无效”指令时，“延迟无效”才会导致不可预测的结果？
This in reference to InteI's Software Developer’s Manual (Order Number: 325384-039US May 2011), the section 4.10.4.4 "Delayed Invalidation" describes a potential delay in invalidation of TLB entries which can cause unpredictable results while accessing memory whose paging-structure entry has been changed.
The manual says ...
"Required invalidations may be delayed under some circumstances. Software devel-
opers should understand that, between the modification of a paging-structure entry
and execution of the invalidation instruction recommended in Section 4.10.4.2, the
processor may use translations based on either the old value or the new value of the
paging-structure entry. The following items describe some of the potential conse-
quences of delayed invalidation:
If a paging-structure entry is modified to change the R/W flag from 0 to 1, write
accesses to linear addresses whose translation is controlled by this entry may or
may not cause a page-fault exception."
Let us suppose a simple case, where a page-strucure entry is modified (r/w flag is flipped from 0 to 1) for a linear address and after that the corresponding TBL invalidation instruction is called immediately. My question is--as a consiquence of delayed invalidation of TLB s it possible that even after calling invalidation of TLB a write access to the linear address in question doesn't fault (page fault)?
Or is the "delayed invalidation" can only cause unpredictable results when "invalidate" instruction for the linear address whose page-structure has changed has not been issued?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
TLB 显然不会因 CR3 更改而取消缓存。 TLB 条目用地址空间的唯一标识符进行标记，并保留在 TLB 中，直到它们被错误的进程触及（在这种情况下，TLB 条目被丢弃）或地址空间被恢复（在这种情况下， TLB 在地址空间更改时得以保留）。
这一切对于 CPU 来说都是透明发生的。您的程序（或操作系统）不应该能够区分这种行为与 TLB 实际上因 TLB 失效而失效之间的区别，除非通过：
解决方案是：
请注意，这确实是未定义的行为。转换到 SMM 可能会使 TLB 失效，也可能不会，从而导致竞争条件。不要依赖这种行为。
TLBs are transparently optimisitically not uncached by CR3 changes. TLBs entries are marked with a unique identifier for the address-space and are left in the TLB until they are either touched by the wrong process (in which case the TLB entry is trashed) or the address-space is restored (in which case the TLB was preserved over the address-space changing).
This all happens transparently to the CPU. Your program (or OS) shouldn't be able to tell the difference between this behaviour and the TLB being actually invalidated by a TLB invalidation except via:
The solution to this is to either:
Note that this is genuinely undefined behaviour. Transitioning to SMM can invalidate the TLB, or might not, leaving this open to a race-condition. Don't depend on this behaviour.