此问题并非特定于任何CPU实现，但欢迎特定于CPU的答案 .
我目前正在实现一个完整的MMU启用的CPU，并出现了一个简单的问题 .
因此，想象一下由指令流（或指令缓存）引起的简单TLB未命中的情况 . 这将触发TLB未命中 . 现在，如果未找到PTE，将触发一些异常，如“页面翻译错误” . 到目前为止，完全没问题 .
现在，为了调用错误处理程序，指令流（或缓存）需要获取异常处理程序代码 . 为此，它需要再次搜索TLB中的相关PTE条目，并最终再次搜索表格 .
想象一下，再次找不到PTE条目 . 可以预期会调用其他一些异常处理程序 .
现在，在最后一个异常处理程序上，由于处理程序本身可能找不到或无效，MMU在获取和执行处理程序之前被禁用（从而绕过每个MMU，包括Phys-Virt映射），还是有另一种技术（非致命）处理这种情况？
Alvie
2 回答
我不能肯定地说现实世界的操作系统，但从查看小内核的经验来看，重点似乎始终在于确保页面错误处理程序本身永远不会被分页并始终位于某个位置永远不会引发页面错误 . 这样可以确保您的问题中描述的情况永远不会出现 .
通常，核心内核代码的某些部分静态驻留在具有已知映射的物理内存上似乎是有道理的;但鉴于你无论如何试图编写一个完整的虚拟内存启用操作系统，我猜你会知道这一点 .
我知道有两种方法：
MMU在发生中断/异常时自动禁用 . 因此，故障处理程序（数据中止处理程序）必须放在已知的物理地址上，并且虚假的MMU故障是不可能的 . 在从异常返回或处理程序使用本身之前，处理程序的责任是重新启用MMU . 这种行为，在现实生活中，在屁股上相当痛苦......
例如'Microblaze' arch就是这么做的 .
MMU未自动禁用 . 诀窍是拥有2组TLB表 . TLB1具有内核映射表，TLB0用于用户应用映射表 . 内核和用户应用程序应分别具有相应的链接，以排除彼此之间虚拟地址的重叠 .
当用户应用程序执行sh **并导致MMU故障时，会发生异常 . 中止/故障处理程序位于内核内存空间中，因此将使用不同的TLB访问处理程序代码 . 你应该确定内核TLB是正确的:)
如果内核异常处理程序本身生成异常，则存在虚假数据和/或指令中止的可能性 .
但实际上，例如，"ARM-Ax" CPU会在执行时屏蔽异常/中断 . 我认为虚假异常不会发生，但我在实践中从未测试过 .
好的HW看门狗可能会帮到你...