问题描述
我想了解当我们想为特定的虚拟内存地址分配一些值时操作系统的工作方式.
I'm trying to understand how does an operating system work when we want to assign some value to a particular virtual memory address.
我的第一个问题是MMU是否处理CPU和RAM之间的所有内容.这是真的?从可以从Wikipedia读取的内容来看，我会这样说:
My first question concerns whether the MMU handles everything between the CPU and the RAM. Is this true? From what one can read from Wikipedia, I'd say so:
如果是这种情况，例如，如何告诉MMU我想要获得8个字节，64个或128个字节?那写作呢?
If that is the case, how can one tell the MMU I want to get 8 bytes, 64 or 128bytes, for example? What about writing?
如果不是这种情况，我猜MMU只是将虚拟地址转换为物理地址?
If that is not the case, I'm guessing the MMU just translates virtual addresses to physical ones?
当MMU检测到将发生所谓的页面错误时，会发生什么?我想它必须告诉CPU，以便CPU将页面本身从磁盘加载，还是MMU能够做到这一点?
What happens when the MMU detects there will be what we call a page-fault? I guess it has to tell it to the CPU so the CPU loads the page itself off disk, or is the MMU able to do this?
谢谢
推荐答案
极乐世界，
我将尝试一个一个地回答您的问题，但请注意，将您的OS入门课程或计算机体系结构入门课程作为教科书可能是一个好主意.
I'll attempt to answer your questions one by one but note, it might be a good idea to get your hands on a textbook for an OS course or an introductory computer architecture course.
MMU由一些硬件逻辑和状态组成，其目的实际上是产生一个物理地址并向/从存储控制器提供/接收数据.实际上，内存转换工作是通过协作硬件和软件(OS)机制(至少在现代PC中)来完成的.一旦获得了物理地址，CPU就基本上完成了其工作，现在将地址通过总线发送出去，该总线有时连接到实际的存储芯片.在许多系统中，此总线称为前端总线(FSB)，该总线又连接到内存控制器.该控制器获取CPU提供的物理地址，并使用它与DRAM芯片进行交互，最终提取出存储阵列中正确行和列中的位.然后将数据发送回CPU，CPU现在可以对其进行操作.请注意，在此描述中我不包括缓存.
The MMU consists of some hardware logic and state whose purpose is, indeed, to produce a physical address and provide/receive data to and from the memory controller. Actually, the job of memory translation is one that is taken care of by cooperating hardware and software (OS) mechanisms (at least in modern PCs). Once the physical address is obtained, the CPU has essentially done its job and now sends the address out on a bus which is at some point connected to the actual memory chips. In many systems this bus is called the Front-Side Bus (FSB), which is in turn connected to a memory controller. This controller takes the physical address supplied by the CPU and uses it to interact with the DRAM chips, and ultimately extract the bits in the correct rows and columns of the memory array. The data is then sent back to the CPU, which can now operate on it. Note that I'm not including caching in this description.
因此，不，MMU不会直接与RAM交互，我认为这是指物理DRAM芯片.而且，您无法告诉MMU您想要8个字节，24个字节或其他任何内容，您只能为其提供一个地址.可以获取多少字节取决于您所使用的计算机以及它是字节寻址还是字寻址.
So no, the MMU does not interact directly with RAM, which I assume you are using to mean the physical DRAM chips. And you cannot tell the MMU that you want 8 bytes, or 24 bytes, or whatever, you can only supply it with an address. How many bytes that gets you depends on the machine you're on and whether it's byte-addressable or word-addressable.
您的最后一个问题促使我提醒您:MMU实际上是CPU的一部分-它位于同一硅芯片上(尽管并非总是如此).
Your last question urges me to remind you: the MMU is actually a part of the CPU--it sits on the same silicon die (although this was not always the case).
现在，让我们以页面错误为例.假设我们的用户级应用程序想要像您所说的那样设置someAddress = 10，我将逐步介绍它.假设someAddress为0xDEADBEEF，现在暂时忽略缓存.
Now, let's take your example with the page fault. Suppose our user-level application wants to, like you said, set someAddress = 10, I'll take it in steps. Let's assume someAddress is 0xDEADBEEF and let's ignore caches for now.
1)应用程序向0xsomeAddress发出存储指令，该指令在x86中可能类似于
1) The application issues a store instruction to 0xsomeAddress, which, in x86 might look something like
mov %eax, 0xDEADBEEF
其中10是eax寄存器中的值.
where 10 is the value in the eax register.
2)在这种情况下，0xDEADBEEF是虚拟地址，必须进行转换.在大多数情况下，虚拟到物理地址的转换将在称为转换后备缓冲区(TLB)的硬件结构中提供，该结构将非常快速地向我们提供此转换.通常，它可以在一个时钟周期内完成此操作.如果转换是在TLB中进行的，称为TLB命中，则可以立即继续执行(即，将对应于0xDEADBEEF的物理地址和值10发送到要写入的存储控制器).
2) 0xDEADBEEF in this case is a virtual address, which must be translated. Most of the time, the virtual to physical address translation will be available in a hardware structure called the Translation Lookaside Buffer (TLB), which will provide this translation to us very fast. Typically, it can do so in one clock cycle. If the translation is in the TLB, called a TLB hit, execution can continue immediately (i.e. the physical address corresponding to 0xDEADBEEF and the value 10 are sent out to the memory controller to be written).
3)但是，让我们假设翻译在TLB中不可用(称为TLB未命中).然后，我们必须在页表中找到转换，页表是内存中的结构，其结构由硬件定义并由OS管理.它们仅包含将虚拟地址映射到物理地址(更准确地说，是将虚拟页码映射到物理页码)的条目.但是这些结构也驻留在内存中，因此必须具有地址！硬件包含一个名为cr3的特殊寄存器，其中包含当前页表的物理地址.我们可以使用我们的虚拟地址来索引该页表，因此硬件将获取cr3中的值，通过添加偏移量来计算地址，然后进入内存以获取页表项(PTE).该PTE将(希望地)包含对应于0xDEADBEEF的物理地址，在这种情况下，我们将此映射放在TLB中(因此我们不必再次遍历页表)并继续前进.
3) Let's suppose though, that the translation wasn't available in the TLB (called a TLB miss). Then we must find the translation in the page tables, which are structures in memory whose structure is defined by the hardware and managed by the OS. They simply contain entries that map a virtual address to a physical one (more accurately, a virtual page number to a physical page number). But these structures also reside in memory, and so must have addresses! The hardware contains a special register called cr3 which contains the physical address of the current page table. We can index into this page table using our virtual address, so the hardware takes the value in cr3, computes an address by adding an offset, and goes off to memory to fetch the page table entry (PTE). This PTE will (hopefully) contain the physical address corresponding to 0xDEADBEEF, in which case we put this mapping in the TLB (so we don't have to walk the page table again) and continue on our way.
4)但是，哦，不！如果页表中没有0xDEADBEEF的PTE，该怎么办?这是页面错误，这是操作系统起作用的地方.我们从页表中取出的PTE存在，因为(假设)它是一个有效的访问内存地址，但是OS尚未为其创建VA-> PA映射，因此它应该进行一些设置表示它无效.对硬件进行编程的方式是，当它在访问时看到此无效位时，它将生成异常，在这种情况下为页面错误.
4) But oh no! What if there is no PTE in the page tables for 0xDEADBEEF? This is a page fault, and this is where the Operating System comes into play. The PTE we got out of the page table existed, as in it was (let's assume) a valid memory address to access, but the OS had not created a VA->PA mapping for it yet, so it would have had a bit set to indicate that it is invalid. The hardware is programmed in such a way that when it sees this invalid bit upon an access, it generates an exception, in this case a page fault.
5)异常导致硬件通过跳转到一个众所周知的位置(一段称为处理程序的代码)来调用操作系统.可以有许多异常处理程序，而页面错误处理程序就是其中之一.页面错误处理程序将知道导致错误的地址，因为它存储在某个地方的寄存器中，因此将为我们的虚拟地址0xDEADBEEF创建一个新的映射.它将通过分配物理内存的空闲页，然后说"VA x和VA y之间的所有虚拟地址都将映射到此新分配的物理内存页中的某个地址"来做到这一点. 0xDEADBEEF将在该范围内的某个位置，因此映射现在已安全地存在于页表中，并且我们可以重新启动导致页错误(mov)的指令.
5) The exception causes the hardware to invoke the OS by jumping to a well known location--a piece of code called a handler. There can be many exception handlers, and a page fault handler is one of them. The page fault handler will know the address that caused the fault because it's stored in a register somewhere, and so will create a new mapping for our virtual address 0xDEADBEEF. It will do so by allocating a free page of physical memory and then saying "all virtual addresses between VA x and VA y will map to some address within this newly allocated page of physical memory". 0xDEADBEEF will be somewhere in that range, so the mapping is now securely in the page tables, and we can restart the instruction that caused the page fault (the mov).
6)现在，当我们再次浏览页表时，我们将找到一个映射，并且拉出的PTE将具有一个不错的物理地址，即我们要存储的地址.我们将其值10提供给内存控制器，我们就完成了！
6) Now, when we go through the page tables again, we will find a mapping and the PTE we pull out will have a nice physical address, the one we want to store to. We provide this with the value 10 to the memory controller and we're done!
缓存将大大改变这个游戏，但是我希望这可以说明分页的工作方式.同样，查看一些OS/计算机体系结构书籍将对您大有裨益.我希望这很清楚.
Caches will change this game quite a bit, but I hope this serves to illustrate how paging works. Again, it would benefit you greatly to check out some OS/Computer Architecture books. I hope this was clear.
这篇关于MMU是否在操作系统和物理内存之间进行所有中介，还是仅是地址转换器?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！