处理指令流中的MMU转换错误- MMU会发生什么？

Question

这个问题并不是特定于任何CPU实现的，但欢迎针对CPU的答案。

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

因此，想象一下由指令流(或指令缓存)导致的简单TLB未命中的情况。这将触发TLB未命中。现在，如果没有找到PTE，就会触发一些异常，比如“页面转换错误”。到目前为止，没有任何问题。

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

假设再一次没有找到PTE条目。人们期望调用一些其他的异常处理程序。

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

阿尔维

Answer 1

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

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

Answer 2

我有两种方式知道：

发生中断/异常时，

1. 内存管理单元自动禁用。因此，故障处理程序(数据中止处理程序)必须放置在已知物理地址上，并且不存在虚假的MMU故障。这是处理程序在从异常返回之前重新启用MMU或处理程序使用本身的责任。这种行为，在现实生活中，是一个很痛苦的问题...

例如，'Microblaze‘arch就是这样做的。

• 内存管理单元不会自动禁用。诀窍是有2组TLB表。TLB1有内核映射表，TLB0是为用户应用制作的映射表。内核和用户应用程序应该分别具有适当的链接，以排除彼此之间的虚拟地址重叠。

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

如果内核异常处理程序本身生成异常，则存在虚假数据和/或指令中止的可能性。

然而，在实践中，例如，"ARM-Ax“CPU在执行异常/中断时会屏蔽这些异常/中断。我认为虚假异常不会发生，但我从未在实践中测试过这一点。

HW watchdog可能会帮你个忙。