Cavium MIPS的内存布局
这里主要想讨论MIPS架构的内存分配问题,对Cavium的了解比较多,所以从熟悉的芯片开始做衍生。Cavium的架构基本上会遵循MIPS的内存分配规则,不会有太大的差异。所以以下讨论均基于Cavium的MIPS架构。
一、物理地址的分配
关于物理内存的讨论,也是基于64bit架构的。MIPS的64bit架构在上世纪90年代开始了。其技术一直都领先于其他的架构处理器。MIPS中采用统一编址架构,IO和Memory使用同样的访问方式。在64bit中实际使用49bits来实现物理地址的访问,其中包括system memory(DRAM) 和IO space。PABITS=49,也就是bits<48::0>。
49bits物理地址格式
其中
IO---I/O bit,决定是访问memory 还是IO space
DID---直接访问的hardware block,映射到芯片中的不同的IO 部件上。
Offset –memory或者IO空间的地址值。
那么以这种方式实现的设计是如何的呢?下图中可以大概的列出物理地址的分配问题。
IO部分的分配:
System memory部分的分配:
针对system memory这一块,系统实际上只使用了36bits来寻址16G的system memory,所以,Cavium MIPS只支持到16G的物理内存大小。但是我们从图上可以看到,真正起作用的也只有35bits而已,这个足以实现16G system memory的访问了。
值得注意的是,图中这这16G 物理内存的寻址空间是有非连续的,分成了三部分:
DR0:256MB [0x0 – 0xfff_ffff]
DR1:256MB [0x4_1000_0000 – 0x4_1fff_ffff]
DR2:15.5GB [0x2000_0000 – 0x3_ffff_ffff]
好像是,DR1部分本来该在[0x1000_0000 – 0x1fff_ffff]段的,但是被抠出来放到了高端地址部分了。但是实际上这里有个转换动作,由于在启动的时候bootbus部分bfc0_0000会映射到物理内存的低端地址处,也就是0x1000_0000 –0x1fff_ffff中间一段。所以,system memory不会使用这段地址,而是在等待bootbus的寻址已经完成之后,比如启动稳定之后,系统对memory的访问,Dram controller会将bit[35:34]屏蔽掉,那么对DR1的访问自然就会映射到地址段0x1000_0000 – 0x1fff_ffff部分了。所以这时候DRAM controller看16G的system memory是连续的。
二、32bit的虚拟内存的讨论(本节为转载,写的很好,就没有自己另外去写了)
在32位MIPS体系结构下,最多可寻址4GB地址空间。这4GB空间的分配是怎样的呢?让我们看下面这张图:
+-----------------------------------------------------------------+
| | 0xFFFFFFFF
| |
| |
| Kernel Space Mapped Cached (kseg2) |
| |
| |
0xC0000000 | |
+-----------------------------------------------------------------+
| | 0xBFFFFFFF
| Kernel Space Unmapped UnCached (kseg1) |
| |
0xA0000000+------------------------------------------------------------------+
| | 0x9FFFFFFF
| Kernel Space Unmapped Cached (kseg0) |
| |
0x80000000+------------------------------------------------------------------+
| | 0x7FFFFFFF
| |
| |
| |
| User Space |
| |
| |
| |
| |
| |
0x00000000 +-----------------------------------------------------------------+
Figure 2-1 MIPS Logical AddressingSpace
上图是MIPS处理器的逻辑寻址空间分布图。我们看到,2GB以下的地址空间,也就是从0x00000000到0x7FFFFFFF的这一段空间,为User Space,可以在User Mode下访问,当然,在Kernel Mode下也是可以访问的。程序在访问UserSpace的内存时,会通过MMU的TLB,映射到实际的物理地址上。也就是说,这一段逻辑地址空间和物理地址空间的对应关系,是由MMU中的TLB表项决定的。
从0x80000000到0xFFFFFFFF的一段为Kernel Space,仅限于KernelMode访问。如果在User Mode下试图访问这一段内存,将会引发系统的一个Exception。MIPS的 Kernel Space又可以划分为三部分。首先是通过MMU映射到物理地址的1GB空间,地址范围从0xC0000000到0xFFFFFFFF。这1GB空间可以用来访问实际的DRAM内存,可以为操作系统的内核所用。
MIPS的Kernel Space中,还有两段特殊的地址空间,分别是从0x80000000到0x9FFFFFFF的Kernel Space Unmapped Uncached和0xA0000000到0xBFFFFFFF的Kernel Space Unmapped Cached。之所以说它们特殊,是因为这两段逻辑地址到物理地址的映射关系是硬件直接确定的,不通过MMU,而且两段实际上是重叠的,均对应0x00000000到0x20000000的物理地址。那么,为什么一段同样的物理地址有两个逻辑地址对应呢?它们的区别又在哪里呢?
原来,这是MIPS的设计特色之一。软件在访问Kernel Space Unmapped Uncached这段地址空间的时候,不经过MIPS的Cache。这样,虽然速度会比较慢,但是,对于硬件I/O寄存器来说,就不存在所谓的Cache一致性问题。Cache一致性问题,是指硬件将某个地址的内容跳过软件而改变了,Cache中的内容尚未同步。这样,如果软件读取该地址,有可能从Cache中获取到错误的内容。将硬件I/O寄存器设定在这段地址空间,就可以避免Cache一致性带来的问题。MIPS的程序上电启动地址0xBFC00000,也落在这段地址空间内。——上电时,MMU和Cache均未初始化,因此,只有这段地址空间可以正常读取并处理。
另一段特殊的地址Kernel Space Unapped Cached,与前者类似,直接映射到0x00000000到0x20000000,与KernelSpace Unmapped Uncached重叠。因为通过Cache,这段地址空间的访问速度比前者为快。一般地,这段内存空间用于内核代码段,或者内核中的堆栈。
显然地,当工程师们换算Kernel Space中的这两段的物理地址和逻辑地址时,只需要改变地址的高3bit就可以了。
三、64bit的虚拟内存的讨论
MIPS的虚拟内存的划分是以‘segments’来实现的,但不是所有的segments都是可以映射的。虚拟地址的转换需要依赖这些条件:
1、 地址空间使用的address bits :64bit 或者32bit 地址空间。
2、 Segment 的选址
3、 权限级别:kernel、supervisor 或者user。
对于64bit的虚拟地址映射,虚拟地址的高位的两个bit用来选择四个segment中的一个,当然这些地址位的转换都是由Hardware来完成的。剩下的62bits则有部分bit是忽略被处理器忽略的。如下图所示:
在64bit的虚拟地址空间中,可以划分为四个segment:xkseg、xkphys、xsseg、suseg等。如下图所画,分别所处的地址空间为:
Xkseg:0xc000_0000_0000_0000 –- 0xffff_ffff_ffff_ffff :kernel mapped
Xkphys: 0x8000_0000_0000_0000 -– 0xbfff_ffff_ffff_ffff ;kernel unmapped
Xsseg: 0x4000_0000_0000_0000 -– 0x7fff_ffff_ffff_ffff ;supervisor mapped
Suseg: 0x0000_0000_0000_0000 -– 0x3fff_ffff_ffff_ffff ;user mapped
而64bit是兼容32bit的,处理方式就是将32bit的虚拟地址的高位进行扩展。比如32地址0x7fff_fff0,最高位是0,扩展到64bit之后,变成了0x0000_0000_7fff_fff0;而比如地址0x8000_fff0,最高位是1,扩展到64bit之后,变成了0xfff_ffff_8000_fff0. 依据这种方式,那么32bit的地址空间扩展到64bit的地址空间是怎么样的呢? 下图也有划分出来。之前的低字节的2G部分user space 依然扩展到64bit地址空间的低字节部分2G。而之前的高字节部分2G kernel space 扩展到64bit空间的最高端2G。
推荐本站淘宝优惠价购买喜欢的宝贝:
本文链接:https://hqyman.cn/post/626.html 非本站原创文章欢迎转载,原创文章需保留本站地址!
休息一下~~