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