Caching 处理指令流中的MMU翻译错误-MMU会发生什么情况？

这个问题并不特定于任何CPU实现，但欢迎特定于CPU的回答

我目前正在实现一个完全支持MMU的CPU，出现了一个简单的问题

因此，想象一下指令流（或指令缓存）导致简单TLB未命中的情况。这将触发TLB未命中。现在，如果找不到PTE，将触发一些异常，如“页面翻译错误”。到目前为止，没有问题

现在，为了调用错误处理程序，指令流（或缓存）需要获取异常处理程序代码。为此，它需要在TLB中再次搜索相关的PTE条目，并最终搜索另一个表遍历

再次设想，找不到PTE条目。我们希望调用其他一些异常处理程序

现在，在最后一个异常处理程序上，由于处理程序本身可能找不到或无效，MMU是否在获取和执行处理程序之前被禁用（从而绕过MMU的所有操作，包括Phys-Virt映射），或者是否有其他技术（非致命）来处理这种情况

---

阿尔维

关于真实世界的操作系统，我不能肯定地说这一点，但从查看小内核的一点经验来看，重点似乎总是在于确保页面错误处理程序本身永远不会被调出，并且总是在一个不会引发页面错误的位置。这将确保您的问题中描述的情况永远不会出现

---

一般来说，核心内核代码的某些部分静态地驻留在物理内存中，并具有已知的映射，这似乎是有意义的；但考虑到您一直在尝试编写一个完整的支持虚拟内存的操作系统，我想您应该知道这一点。

我知道有两种方法：

当发生中断/异常时，MMU将自动禁用。因此，必须将故障处理程序（数据中止处理程序）放置在已知的物理地址，不存在虚假的MMU故障。处理程序有责任在从异常返回之前重新启用MMU或处理程序使用本身。那种行为，在现实生活中，真是一种痛苦
例如，“微晶玻璃”拱门就是这样做的

MMU不会自动禁用。诀窍是有两套TLB表。TLB1有内核映射表，TLB0是为一个用户制作的应用映射表。内核和用户应用程序应分别具有适当的链接，以排除彼此之间的虚拟地址重叠。

当用户应用程序执行sh**操作并导致MMU故障时，会发生异常。中止/故障处理程序位于内核内存空间中，因此将使用不同的TLB访问处理程序代码。您应该非常确定内核TLB是正确的：）

如果内核异常处理程序本身生成异常，则存在虚假数据和/或指令中止的可能性
然而，在实践中，“ARM Ax”CPU在执行异常/中断时屏蔽异常/中断。我认为虚假异常不会发生，但我从未在实践中测试过。

看门狗可能会帮你一个忙

---

我的问题实际上是硬件相关的，而不是软件相关的。因此，如果我们不能正确处理故障，唯一的选择似乎是完全重置。我想知道，对于特定场景，是否可以禁用MMU以避免发生这种情况。例如，可以映射（硬）到固件代码。