内核态内存的page table与用户态内存的page table

dean_go

看书上说，线性空间4G，前3G用于用户进程，后1G用于内核态。
每个用户进程都有4G的线性空间。
那么每个进程都包含同样的后1G空间，用于内核态。那么这1G空间的页表是怎么处理的？
每个进程都有一份copy吗？
是什么时候copy的？

求大家指占迷津。

humjb_1983

dean_go 发表于 2013-12-26 12:27
看书上说，线性空间4G，前3G用于用户进程，后1G用于内核态。
每个用户进程都有4G的线性空间。
那么每个进 ...

每个进程都有一份copy，当发生内核态缺页异常时，从内核的主页表中同步到进程自己的页表中。

goter

内核用的1G空间不需要页表项

arm-linux-gcc

32位arm的实现方法：
1，每个进程有自己的一份kernel space页表，也就是说每个进程自己的页表就完整的表示了4G范围的映射关系。
2，kernel的lowmem部分用一级页表映射，每个entry对应1M；vmalloc zone等非线性部分使用二级页表来映射。
3，做ioremap时并不会更新本进程自己的内核页表，而是更新内核主页表（0xc0004000这个地方），于是本进程在首次使用这个ioremap的返回值时，就会发生异常，然后在异常处理中会去将内核一级主页表中的对应entry同步到本进程的内核页表中，然后重新执行发生异常处的指令，此时本进程的一级页表中的对应entry已经有了内容，这个内容是指向的二级页表，而二级页表中的对应entry已经在ioremap时填好了，所以这次就能够正常运行了。
4，做iounmap时，不会释放二级页表的buffer，只会将buffer里面的内容设置为无效，内核主页表和本进程的内核页表的一级页表对应的entry也仍然会一直指向这个buffer。然后如果对iounmap的地址再访问，在做虚拟到物理地址转换时，就会发现对应二级页表中的entry内容是非法的，于是发生异常。当下一次再有ioremap时，就又会重复利用这个已经分配的二级页表的buffer。

64位arm的实现方法：
用户空间和内核空间的页表是分离的，TTBR0用来指向用户空间页表，TTBR1用来指向内核空间页表，这样就不存在从内核主页表同步的问题了。
其实armv7中已经实现了分离页表，只是kernel中还没有使用。
在arm64分支中就用上了分离页表，因为内核地址和用户地址之间差距巨大（见Documentation\arm64\memory.txt），如果不分离的话，光是页表就要占据上百M的内存。

冬瓜头

goter 发表于 2013-12-26 22:12
内核用的1G空间不需要页表项

哦？能否稍微详细说一下巍峨不需要页表项，没有页表项，怎么做的转换呢？谢谢。

arm-linux-gcc

回复 3# goter


    只有mips才不需要吧，arm肯定是需要的，powerpc貌似也需要，x86不了解

xs3c

回复 6# arm-linux-gcc

32bit PPC BOOKE的话用三个TLB1 entry来映射lowmem，每个entry 对应256M. highmem 还是跟arm32类似。
64bit PPC BOOKE 基本上几个entry就把所有的内存都一一映射了，另外你说Ioremap这些还是走swapper_dir。


   

kiongf

回复 3# goter


    如果内核空间没有页表项, 那么支持大页的架构的内核空间如何使用大页？
   
   x86的架构 就使用kernel_physical_mapping_init()函数初始化了一个swapper_pg_dir的paging hierarchy.