xv6 内核空间共享

本文介绍: x v6 不需要内核页表同步，因为 x v6 在启动的时候，内核地址空间的映射关系已经建立好了，而纵观代码也没有修改内核地址空间映射关系的地方，所以内核地址空间的映射关系应是一直不变的。每个进程页表只需要映射它自己的地址空间以及跳转到内核那一小段代码段即可，跳转到内核后，切换到内核页表，在内核办完事儿后再切换回进程页表，这个过程似乎没有问题，也就是根本就没必要拷贝整个内核页表到进程页表的内核部分，那为什么还要这么做呢，让内核地址空间和进程用户地址空间在同一张页表共存？这就有个问题，如何共享的？

首发公号：Rand_cs

共享内核空间

我们常说，每个进程都有自己的虚拟地址空间，但其中内核部分是共享的。

这就有个问题，如何共享的？

系统启动时创建了一张内核页表，里面记录着内核地址空间与物理地址空间的映射关系，而每次 fork 子进程时都会复制一份内核页表，所以说每个进程页表中的内核部分是“相同的”，因此可以说共享内核空间。

这里我将最初的内核页表称为“原本”，每个进程的内核部分称为“副本”，类似副本的设计都会存在存在一个问题——同步，意思是说，如果某个进程修改了内核空间的映射关系，那么需要将这种映射关系的改变同步到其他副本，如此才能保证逻辑正确。

最初分析 x v6 的 scheduler 的代码时，发现每次返回到调度器时都会切换到内核页表，如下所示：

void scheduler(void)
{
........
      swtch(&amp;(c-&gt;scheduler), p-&gt;context); 
      switchkvm();   
........
}

当时我便在想，不切换行不行，于是将 switchkv m 注释掉，发现出了错，而且错误还不固定，有的是触发 page fault、有的是系统 reset(从 main 函数重新开始执行)，未找到明确的复现规律。当时没有细想，初步便认为是因为各个进程页表的内核部分，也就是“副本”们之间没有同步，导致了种种错误。后来重新看代码的时候，发现问题应该不在内核页表同步。

xv6 不需要内核页表同步，因为 xv6 在启动的时候，内核地址空间的映射关系已经建立好了，而纵观代码也没有修改内核地址空间映射关系的地方，所以内核地址空间的映射关系应是一直不变的。可能有的朋友会觉得 kalloc 函数会更改内核映射，其实并没有，kalloc 只是分配内存，并没有修改映射关系，可以仔细看看 kalloc 前后的关于修改映射关系的代码，比如说 *pte = xxx, *p de = xxx，这才是修改页表修改映射关系。在 g row proc->kalloc 调用链中，kalloc 分配的内存映射到了进程的用户空间，修改的是进程页表用户态部分的 pte，map pages->walkpg dir->kalloc 中分配的内存用作用户页表，修改的是进程页表用户态部分的 pde

这就相当于 Linux 中的直接映射区域，但是不存在 vmalloc 动态映射区域，所以 xv6 其实不需要内核页表的同步。假如说某个进程确实会改动内核映射关系，那么应该如何实现内核页表同步。同步内核页表是为了每个进入内核时都能看到相同的内核影响，所以

第一种方式不需要同步内核页表，每次进程进入内核的时候，切换到“原本”内核页表，那么每个进程进入内核的时候使用的是同一份页表，当然就不需要同步
第二种方式，那就是老老实实的同步页表，也就是说当“原本”或“副本”被修改的同时，也就将相关的修改同步到其他“副本”。这部分可以参考 Linux vmalloc 区同步的做法，当“原本”修改时，调用 sync_global_pg ds 主动将修改同步到其他“副本”。当某个“副本”被修改时，Linux 先后有三种同步方式，最开始在 pagefault 中触发同步，但有竟态问题，有了第二种主动同步，但因为性能问题，又增加了第三种干掉同步的方式。Linux 内存管理的部分见 bin的技术小屋这位大佬写的文章，本文不赘述，这应该是全网对 Linux 内存管理讲解的最详尽细致的文章了，值得一看。

这里在穿插一个问题，既然内核里面本来就有一份内核页表，那么进程页表何必再拷贝一份内核页表，反正进程在用户态时不能访问内核态，根本就用不到内核页表。每个进程页表只需要映射它自己的地址空间以及跳转到内核那一小段代码段即可，跳转到内核后，切换到内核页表，在内核办完事儿后再切换回进程页表，这个过程似乎没有问题，也就是根本就没必要拷贝整个内核页表到进程页表的内核部分，那为什么还要这么做呢，让内核地址空间和进程用户地址空间在同一张页表共存？

我想，这个问题应该是和架构强相关，在 arm 中有两个页表寄存器，ttbr0 存放进程页表，ttbr1 存放共享的内核页表，访问用户空间地址使用 ttbr0 寄存器，访问内核空间地址使用 ttbr1 寄存器。因为 arm 有两个寄存器，进程进出内核不需要进行页表切换。

但是 x86 架构只有一个页表寄存器，如果将用户页表和内核页表分开，那么进出内核势必造成页表切换，页表切换刷新 tlb，如果没有 ASID/PCID 等机制的话，性能损失太多

话说，内核页表和用户页表共存也会引发一些安全问题，比如之间大爆的 m eldown 漏洞，以及相应的缓解方案 kpti，挺有意思，有兴趣的话可以看一下。

回到 xv6 上面来，那为什么 scheduler 中需要切换到内核页表？很不幸，这个问题始终还未能解决，写在这里便是和大家讨论一下，以及分享一下相关的一些东西，另外很有意思的是，当我在 ubuntu 虚拟机中跑注释掉 switchkvm 的 xv6 时，会引发各种问题，但是在 ubuntu 的宿主机上跑便没有问题(已考虑到虚拟机 cpu 核心分配的问题)，这便很奇怪，想了很久未能弄明白，暂时存疑吧。元芳，你怎么看？