内核模式转换答案

【问题标题】：Kernel mode transition内核模式转换
【发布时间】：2012-11-18 15:49:14
【问题描述】：

如果我理解正确，系统空间中的内存添加器只能从内核模式访问。这是否意味着在系统空间中映射的组件执行时必须将处理器切换到内核模式？

例如：虚拟内存管理器是一个经常使用的组件，它被映射到系统空间中。每当 VMM 在用户进程的上下文中运行时（假设它翻译了一个地址），处理器是否必须切换到内核模式？

谢谢，苏雷什。

【问题讨论】：

标签： windows

【解决方案1】：

通常涉及两部分。MMU（内存管理单元）是一个硬件组件，负责从虚拟地址到物理地址的转换。和操作系统VM子系统。

操作系统部分需要在特权模式（也称为内核模式）下运行，并将根据用户空间的需要设置/更改 MMU 中的映射。

例如要请求更多（虚拟）内存，或将文件映射到内存，需要转换到内核模式，VM 子系统可以更改进程的映射。

围绕这一点，通常需要制作大量的技巧 - 例如。将内核的整个地址空间映射到用户进程虚拟空间，但更改其访问权限，使进程无法使用该内存 - 这意味着每当您转换到内核模式时，您都不需要重新加载内核的映射。

【讨论】：

您是否说每当执行驻留在系统空间中的任何代码（无论是 VMM 还是线程调度程序）时，都必须转换到内核模式？谢谢。
是的。请注意，转换内存地址之类的事情是由硬件单元完成的，它不需要执行代码（除非它导致页面错误）
好的，谢谢。我同意翻译地址是由硬件完成的，但它仍然需要访问驻留在系统空间中的页表，对吗？那么，要访问页表，处理器应该切换到内核模式还是完全由硬件处理而不涉及处理器？谢谢。
在 x86 处理器上，这仅在硬件中完成（除非它找不到页表条目，在这种情况下会发出陷阱 - 并且需要内核转换）。
谢谢。我现在明白了。

【解决方案2】：

以虚拟内存管理器为例，它实际上从未在用户空间中运行。为了分配内存，用户模式应用程序调用 Win32 API（例如NTDLL.DLL）到诸如VirtualAlloc 之类的例程。

关于地址转换，这里是其工作原理的摘要（基于 Windows Internals 5th Edition 的内容）。

VMM 使用页表，CPU 使用该页表将虚拟地址转换为物理地址。页表位于系统空间中。每个表包含许多 PTE（页表条目），其中存储了虚拟地址映射到的物理地址。在这里我不会详细介绍，但重点是 VMM 的所有工作都是在系统空间而不是用户空间中执行的。

至于上下文切换——当运行在用户空间的线程需要运行在系统空间时，就会发生上下文切换。由于内存管理器存在于系统空间中，它的线程永远不需要进行上下文切换，因为它已经存在于系统空间中。

抱歉，解释过于简单，这是一个相当复杂的深入讨论话题。我强烈建议您选择一份Windows Internals，因为这听起来对您很有用。

【讨论】：

嗨 jas，我同意 VMM 的工作是在系统空间中执行的。让我们举个例子。假设发生页面错误，并且陷阱处理程序将调用 VMM 中的 MmAccessFault 方法，该方法在导致错误的线程的上下文中运行。但是，MmAccessFault 方法位于系统空间中，如果处理器需要执行它，则处理器需要处于内核模式。所以，问题是，转换是否会在方法被调用之前发生？我确实有一份 Windows Internals（虽然是第 4 版）。谢谢。
即使在页表中有有效地址的情况下，由于页表驻留在系统空间中，由于地址转换发生在用户线程的上下文中，是否需要切换到内核模式？同样，当任何在内核模式下运行的组件在用户模式线程的上下文中运行时，是否需要在它们开始执行之前切换到内核模式？谢谢。
诚然，我无法完全回答您的问题，因为您需要帮助的深度有点超出我的能力范围。我试了一下，但也许知识更渊博的 Windows 专家可以在这里提供帮助。
Windows 将内存分成两部分——在 32 位操作系统上，每个进程都有 2G 的地址空间和映射到所有进程的 2G 地址空间。内核代码位于通用的 2G RAM 中（文件系统缓存、内核数据、分页池、非分页池等也是如此）。内核空间的页面受处理器保护，因此用户模式代码无法访问该内存。当页面错误发生时，处理器切换到内核模式，然后页面变得可访问。如果您需要，我可以更详细地介绍，但 Windows Internals 应该涵盖这一点。
谢谢拉里。我现在更好地理解它了。我正在再次阅读 Windows Internals，如果我有任何问题，我一定会发布。再次感谢您的宝贵时间。