[A-11]ARMv8/ARMv9-Memory-多级页表架构

ver 0.2
[看前序文章有惊喜，关注WX公众*号“浩瀚架构师”，解锁更多精彩内容。]
媒介

书接上文，我们用了一篇文章，搞清楚了一个事实：架在内存的虚拟地点空间和物理地点空间上联通相互的这座鹊桥着实就是一个账本，记录着软件和硬件之间的接洽，大概说一个虚拟地点空间的地区和物理地点空间地区的映射关系。上一节，我们循着MMU的工作的流程，大致的讲述了账本每个目次项记录的内容。在文章的结尾举例了一个一级页表工作的例子，这里思考第几个问题：
(1) 一级页表是不是满足全部场景下的需求?
(2) 虚拟和物理之间地区的映射size是怎么定的？
(3) 这个账本的目次项的详细格式到底是由谁规定的？具体的格式到底是啥样的？
(4) 具体的映射过程又是啥样的？
下面我们将带着这些问题，进入正文。
正文

1.多级页表

1.1 背景

这一节我们重要是算一笔细账，算账之前让我们扼要看一下虚拟地点空间。随着计算机技术的发展，虚拟地点空间也不断增长，从8位到16位、32位再到现在广泛的64位。对于32位或64位系统而言，其可寻址的虚拟地点空间极大，如32位系统支持4GB的虚拟地点空间，而对于64位的系统虚拟地点的空间就变得更大了，如图1-1所示。

   图1-1 典型的64Bits虚拟空间配置  前面的文章我们介绍页表的根本概念的时间讲过了，页表就是一个账本记录着虚拟内存空间和物理内存空间一段地区的映射关系。当然，我们也说过这个地区有两种情势一种是Block的情势，一种是Page的情势，我们先把Block的情势放一放，先看看按照页分别，这笔账能算成啥样。要算账，肯定得准备一下，我们先创建一个单级页表的模型，如图1-2所示。

   图1-2 典型的单级页表模型  条件
我们对上面的模型先做一个归纳：
(1) 虚拟地点空间(VA Size)：EL0/EL1空间的虚拟地点空间256TB(Linux进程的地点，48Bits有用位)。
(2) 页面的Size(Page Size)：假定为常见的以4KB的颗粒度对虚拟地点空间举行切片分别。
(3) 页表的项Size(Translation Tables)：按照8个字节计划，记录一次虚拟地点的分配映射过程。
计算
我们来算一笔细账：按照这个单级页表模型管理一个进程的虚拟地点空间需要斲丧多少物理空间来存放页表(账本)?
(1) 根据已知条件Page_Size = 4K = 2^12，也就是说48位的进程地点空间中需要拿出12Bits举行页内的寻址，也可以说一次分配的地区需要斲丧地点空间的低12Bits。
(2) 根据上面的推导，一个页表项目TTE(Translation Table Entry)可以记录低12Bits的空间，那么一个进程的地点空间内页表项的总数TTE_Count = 2^(48 - 12) = 2 ^ 36 。
(3) 一个TTE由于要存储被分配的物理地区的起始物理地点和该内存地区的属性，我们假定TTE_Size = 8Bytes，那么一个进程的内存空间统共需要多少物理内存来存放页表(TTS Translation Tables Size)：TT_Size = TTE_Count X TTE_Size = 2 ^ 36 X 8 = 2 ^ 39(Bytes)。
总结
我们对上面模型的计算结果举行扼要总结：
(1) 4G物理地点空间也就2 ^ 32(Bytes)，这2 ^ 39(Bytes)的地点空间来放账本，着实是太大了，显然是不可能接受的。
(2) 假如我们能对单级页表

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。