操作系统内存隔离
我正在尝试编写一个非常薄的虚拟机管理程序，它具有以下限制：
- 一次仅运行一个操作系统（即没有操作系统并发，没有硬件共享，无法切换到另一个操作系统）
- 它应该能够仅隔离 RAM 的某些部分（在操作系统后面进行一些内存转换 - 假设我有 6GB RAM，我希望 Linux / Win 不要使用前 100MB，仅查看 5.9MB 并在不知道是什么的情况下使用它们在后面）
我搜索了互联网，但在这个具体问题上几乎没有发现任何内容，因为我想保持尽可能少的开销（当前的虚拟机管理程序实现不符合我的需求）。
I am trying to write a very thin hypervisor that would have the following restrictions:
- runs only one operating system at a time (ie. no OS concurrency, no hardware sharing, no way to switch to another OS)
- it should be able only to isolate some portions of RAM (do some memory translations behind the OS - let's say I have 6GB of RAM, I want Linux / Win not to use the first 100MB, see just 5.9MB and use them without knowing what's behind)
I searched the Internet, but found close to nothing on this specific matter, as I want to keep as little overhead as possible (the current hypervisor implementations don't fit my needs).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您正在寻找的东西已经存在于硬件中！
它称为 IOMMU[1]。基本上，就像页表一样，在执行的指令和实际的物理硬件之间添加一个转换层。
AMD 称之为 IOMMU[2]，Intel 称之为 VT-d（请谷歌：“intel vt-d”，我还不能发布两个以上的链接）。
[1] http://en.wikipedia.org/wiki/IOMMU
[2] http://developer.amd.com/documentation/articles/pages/ 892006101.aspx
What you are looking for already exists, in hardware!
It's called IOMMU[1]. Basically, like page tables, adding a translation layer between the executed instructions and the actual physical hardware.
AMD calls it IOMMU[2], Intel calls it VT-d (please google:"intel vt-d" I cannot post more than two links yet).
[1] http://en.wikipedia.org/wiki/IOMMU
[2] http://developer.amd.com/documentation/articles/pages/892006101.aspx
这里有一些建议/提示，它们必然有些不完整，因为从头开始开发虚拟机管理程序是一项复杂的任务。
首先让您的虚拟机管理程序“兼容多重引导”。这将使其能够作为引导加载程序配置文件中的典型条目驻留，例如 /boot/grub/menu.lst 或 /boot/grub/grub.cfg。
您希望在内存顶部留出 100MB，例如从 5.9GB 到 6GB。既然您提到了 Windows，我假设您对 x86 架构感兴趣。 x86 的悠久历史意味着最初的几兆字节充满了各种遗留设备的复杂性。网络上有大量关于 640K 和 1MB 之间“漏洞”的材料（网络上有大量信息详细说明了这一点）。较旧的 ISA 设备（其中许多仍然存在于现代系统的“超级 I/O 芯片”中）仅限于对前 16 MB 物理内存执行 DMA。如果您尝试了解 Windows 或 Linux 及其与前几 MB RAM 的关系，您将面临更多的复杂性。一旦你有了可以启动的东西，就把它保存起来。
随着物理地址接近 4GB（2^32，因此基本 32 位架构上的物理内存限制），事情再次变得复杂，因为许多设备都被内存映射到该区域。例如（参考另一个答案），Intel 以其 VT-d 技术提供的 IOMMU 倾向于将其配置寄存器映射到以 0xfedNNNNN 开头的物理地址。
对于具有多个处理器的系统来说更是如此。我建议您从单处理器系统开始，从 BIOS 中禁用其他处理器，或者至少手动配置您的来宾操作系统以不启用其他处理器（例如，对于 Linux，包括“nosmp”
在内核命令行上——例如，在 /boot/grub/menu.lst 中）。
接下来了解一下“e820”地图。网络上同样有大量材料，但也许最好的起点是启动 Linux 系统并查看输出“dmesg”顶部附近。这就是 BIOS 与操作系统进行通信的方式，其中哪些部分的物理内存空间被“保留”给设备或其他特定于平台的 BIOS/固件使用（例如，在仅具有 USB I/O 端口的系统上模拟 PS/2 键盘） ）。
虚拟机管理程序向来宾操作系统“隐藏”其 100MB 的一种方法是向系统的 e820 映射添加一个条目。一种快速但肮脏的开始方法是使用 Linux 内核命令行选项“mem=”或 Windows boot.ini / bcdedit 标志“/maxmem”。
还有更多细节和您可能会遇到的事情（例如，x86 处理器在首次加电时以 16 位模式开始），但如果您对此处列出的内容做一些功课，那么希望您会在更好地提出后续问题。
Here are a few suggestions / hints, which are necessarily somewhat incomplete, as developing a from-scratch hypervisor is an involved task.
Make your hypervisor "multiboot-compliant" at first. This will enable it to reside as a typical entry in a bootloader configuration file, e.g., /boot/grub/menu.lst or /boot/grub/grub.cfg.
You want to set aside your 100MB at the top of memory, e.g., from 5.9GB up to 6GB. Since you mentioned Windows I'm assuming you're interested in the x86 architecture. The long history of x86 means that the first few megabytes are filled with all kinds of legacy device complexities. There is plenty of material on the web about the "hole" between 640K and 1MB (plenty of information on the web detailing this). Older ISA devices (many of which still survive in modern systems in "Super I/O chips") are restricted to performing DMA to the first 16 MB of physical memory. If you try to get in between Windows or Linux and its relationship with these first few MB of RAM, you will have a lot more complexity to wrestle with. Save that for later, once you've got something that boots.
As physical addresses approach 4GB (2^32, hence the physical memory limit on a basic 32-bit architecture), things get complex again, as many devices are memory-mapped into this region. For example (referencing the other answer), the IOMMU that Intel provides with its VT-d technology tends to have its configuration registers mapped to physical addresses beginning with 0xfedNNNNN.
This is doubly true for a system with multiple processors. I would suggest you start on a uniprocessor system, disable other processors from within BIOS, or at least manually configure your guest OS not to enable the other processors (e.g., for Linux, include 'nosmp'
on the kernel command line -- e.g., in your /boot/grub/menu.lst).
Next, learn about the "e820" map. Again there is plenty of material on the web, but perhaps the best place to start is to boot up a Linux system and look near the top of the output 'dmesg'. This is how the BIOS communicates to the OS which portions of physical memory space are "reserved" for devices or other platform-specific BIOS/firmware uses (e.g., to emulate a PS/2 keyboard on a system with only USB I/O ports).
One way for your hypervisor to "hide" its 100MB from the guest OS is to add an entry to the system's e820 map. A quick and dirty way to get things started is to use the Linux kernel command line option "mem=" or the Windows boot.ini / bcdedit flag "/maxmem".
There are a lot more details and things you are likely to encounter (e.g., x86 processors begin in 16-bit mode when first powered-up), but if you do a little homework on the ones listed here, then hopefully you will be in a better position to ask follow-up questions.