Mips TLB miss异常

最近分析龙芯KVM的实现,顺便又粗看了遍MIPS的手册,跟KVM相关的主要模块包括:

  1. CPU虚拟化
  2. 内存虚拟化
  3. IO虚拟化

目前龙芯上CPU虚拟化跟标准内核差异不大,需要软硬件配合支持,目前龙芯整体能支持。 内核虚拟化是龙芯KVM方案的关键,直接决定了性能,这也是本文的源头。 IO虚拟化,目前龙芯由于没有自己的桥片,很难做什么,主要基于KVM中现有的virtio(半虚拟化),这里也不关注。

结构化TLB

龙芯的内存管理机制,最核心的莫过于MIPS中结构化TLB的相关处理。

MIPS的MMU架构

通常,处理器的MMU架构分两类:

  1. 结构化页表。这也是X86和PowerPC使用的方式。就是我们熟悉的:基于页表来做虚拟地址到物理地址的映射,当然,这种方式下,也存在TLB,但仅作为页表的缓存。地址翻译过程描述为:当CPU需要做访存操作时,MMU先在TLB中查询相应条目,如果没找到,就从页表中查找。如果页表中找到,则填充TLB,如果没找到,则触发缺页异常。这一整套操作都由MMU硬件完成。

  2. 结构化TLB。这是MIPS使用的方式。核心思想是:所有的地址翻译都经过TLB完成。结构化TLB中也存在页表,但这基本由软件(操作系统内核)使用和维护;地址翻译过程描述为:当CPU需要做访存操作时,MMU从TLB中查找,当TLB中没找到时,直接触发TLB Miss(也叫TLB Refill)异常,TLB Miss异常处理中(内核实现),完成TLB的填充,通常的实现为:也维护X86中类似的页表,从页表中取相应的条目,填充到TLB中,其中还涉及更复杂的二次异常的逻辑,后面单独介绍。TLB的填充操作完全由软件负责,当然,硬件层面有一些辅助,用于提升性能,后面单独介绍。如此设计,利弊明显。

  • 好处:硬件设计简单,软件实现灵活性大。
  • 坏处:性能可能不足(还是要分场景)?

TLB Miss中Page Fault

如前所述,结构化TLB中,当TLB中不存在映射时,从页表中找。那么,当页表中也不存在,此时该怎么办?换句话说,页表中的条目是从哪里来的?显然硬件不会自动生成。

这里需要明确:

  • MIPS硬件实现上,没有X86中对应的缺页异常
  • MIPS MMU硬件不会去查页表,只会查TLB
  • 页表内容显然需要软件来维护。

MIPS Exception

MIPS中的异常(Exception,翻译可能有不同)分为两类:

  1. 高优先级。即需要尽快处理的异常,每种异常都有一个专用的固定的异常入口,因此可以得到快速处理。包含3种:
    • NMI、启动、重启
    • TLB Refill,即TLB Miss异常。
    • Cache Error
  2. 普通优先级。即General Exception,也称其它异常,即除上述高优先级异常之外的所有异常(由CP0的STATUS寄存器[6:2]区分,也称ExcCode),都归属于此类,如中断、TLB Load/Store/Modify异常、系统调用等,此类异常对应同一个异常入口地址(处理接口),然后在该处理接口中根据不同的异常类型,调用不同的处理接口,相当于将事件进行了二次转发处理,所以,相对于前面的高优先级异常,处理较慢。

多数情形下(非嵌套),异常处理其实就相当于一个伴随模式切换的过程调用。异常的处理流程描述为:

  1. 异常发生后,MIPS置CP0寄存器Status[EXL] = 1,并将当前PC值存入EPC(Exception PC,即指向发生异常的指令)。

  2. 从当前指令流跳转到异常处理接口。

  3. MIPS硬件不负责保存上下文,因此需要软件先保存上下文。

  4. 异常处理完成后,同样由软件负责恢复上下文,再执行指令eret,从异常返回。

  5. eret所作的操作为:将EPC/ErrorEPC的值置入PC,同时清除CP0_Status寄存器的EXL位。MIPS下,当Status寄存器的EXL(exception)位为1,即表示处理器进入异常处理,处于特权模式下。

需要注意:当在异常处理过程中(Status[EXL] = 1),又出现新异常时,CPU将不会重新设置EPC和CAUSE[BD],当新异常处理完成后,由于EPC之前没有重置,就直接返回到发生异常原始指令处,在TLB Refill的情况下,通常返回用户态。

页表如何维护?

这是一个关键而且难以理解问题,每个进程都有自己独立的虚拟地址空间,即每个进程都需要页表,在X86中,MMU可以直接使用页表(页目录地址写到CR3寄存器中就可以了),还可以通过page fault来动态按需创建更新页表项,但MIPS中没有这样的机制,怎么办?

  • 预先映射?即事先将页表创建好,即静态方式,那么映射2G的用户态地址空间就需要4M大小的内存。现在内存不值钱,多的是?但实际上进程实际使用的内存远比虚拟内存小,这样浪费就有点过分了。

  • 使用虚拟地址,动态分配?主流MIPS中确实是这样实现的。但这其中涉及一些关键问题:

    • 页表使用的虚拟地址也需要做地址映射,而MIPS中,是基于TLB映射,而如果TLB中此时不存在此映射,显然会再次触发(由硬件触发)TLB Miss异常,说再次,是因为我们当前已经在TLB Miss异常中了,嵌套了?此时如何处理,如何实现页表的维护?

MIPS硬件在这里做了特殊设计:当访存发现TLB中不存在对应地址映射时(此时),同时判断CP0 Status寄存器的EXL位,如果为1,表示当前已经在异常处理中,此时,不再重复进入TLB Refill异常(高优先级异常,对应异常编号为1),而是直接进入普通优先级异常(通用异常,对应异常编号为3)处理,同时会在CP0的STATUS寄存器[6:2]中填入相应的ExcCode(页表中不存在地址翻译条目的情况,对应的ExcCode为2,即TLB Load异常),通用异常的处理接口中,会根据ExcCode调用相应处理接口,其中对于缺页的情况,会最终调用do_page_fault接口,实现内存分配和页表维护。

在TLB Refill过程中再次发生的TLB miss,通常也称为TLB Load/Store异常,此时处理流程跟TLB refill是不同的。过程类似于X86中的缺页异常。

缺页后如何更新TLB

如前面所述,当在异常处理过程中(Status[EXL] = 1),又出现新异常时,CPU将不会重新设置EPC和CAUSE[BD],当新异常处理完成后,由于EPC之前没有重置,就直接返回到发生异常原始指令处。

也就是说,当TLB Refill过程中再次发生TLB miss(实现了类似X86中的缺页异常的功能,完成页表维护),进行处理后,会直接返回最初发送TLB Refill异常的地方,而不会回到第二次TLB Miss发生的地方,也就是说,虽然页表更新成功了,但TLB中还没有填入相应的映射呢,那页表中的内容是如何写到TLB中的呢?

答案是:又一次异常。当返回最初发生TLB Refill异常的指令后,会重新执行原来的指令,此时由于TLB中仍没有相应的映射条目,所以硬件会再次触发TLB Refill异常,而此时,页表中的条目已经准备好了,异常处理中会直接从页表refill到TLB。

MIPS地址翻译全过程

再次完整梳理一遍MIPS地址翻译的全过程:

  1. 当CPU做访存操作时,MMU硬件会自动到TLB中寻找相应的映射条目。
  2. 如果映射条目存在,则直接取出做映射,得到物理地址,这是最快的路径。
  3. 如果条目不存在,则MMU硬件触发TLB Refill(也称TLB Miss)异常,跳转到固定的高优先级异常入口地址处理,其中是内核填入的处理接口,会通过Context寄存器读取位于内存中的页表中对应的条目,
  • 如果页表中相应映射条目存在,则直接读取,并填入TLB(这些操作由软件,也就是内核完成)。
  • 由于页表本身也是通过虚拟地址映射的(通常kseg2段),所以其自身也需要通过TLB映射,而此时异常处理接口中会通过页表的虚拟地址来做访存操作,如果页表不存在相应映射条目,则MMU硬件会再次触发TLB Miss异常。
  • 由于MIPS硬件上做了特殊处理,对于在异常中(Status[EXL] = 1)再次发生异常的情况,不会重新进入,而会进入General exception的处理,并设置ExcCode为2。
  • General exception处理中,会根据ExcCode,条用相应的处理接口,此时对应为handle_tlbl。
  • 在handle_tlbl中,会根据情况条用do_page_fault接口更新和维护页表。
  • General exception处理完成后,直接返回到第一次发生TLB Refill异常的地址,重新执行原来触发异常的指令,此时会再次触发TLB Refill异常,然后从页表refill相应的条目到TLB。至此,处理结束。

可以看出,在最糟糕的情况下(页表和TLB中都不存在相应映射条目),会触发3次异常,才能完成TLB Refill(而X86的page fault只需要一次异常),这样的性能能好么?

实践证明,其实还不错。最糟糕的情况相对比较少~


原文地址: http://happyseeker.github.io/kernel/2016/12/27/mips-TLB-miss.html

你可能感兴趣的:(Linux,Kernel)