Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1572329
  • 博文数量: 77
  • 博客积分: 1205
  • 博客等级: 少尉
  • 技术积分: 4476
  • 用 户 组: 普通用户
  • 注册时间: 2010-04-22 21:48
文章分类
文章存档

2018年(1)

2017年(1)

2015年(1)

2014年(18)

2013年(12)

2012年(44)

分类: LINUX

2014-04-17 17:48:19

当机器Power-ON时,x86 real mode的CS:IP=0xFFFF0,指向ROM中的BIOS代码。此时RAM还未初始化,所以BIOS的首要工作是把RAM给用起来,配置RAM当然要靠Memory Controller,PC架构中一个叫“北桥”的东西来完成,北桥的学名是GMCH -- Graphic Memory Controller Hub。BIOS中的代码需要通过GMCH来检测RAM的型号及容量。这个工作只能由ROM中的BIOS来完成,因为OS此时连毛都看不到,在如此原始的环境下。BIOS把RAM给弄起来后,会把它的数据和代码加载到RAM中(因为继续在ROM中运行的话很快就会遇到困难,比如一些变量无法更改等等, 另外执行速度方面的考虑),当然还会有其他板卡上的BIOS代码被加载到RAM中去,比如Video BIOS (VBIOS)。当然系统BIOS还会在0--0x3FF这个RAM空间处建立中断向量表,等等。它也通过MCH将0xA000--0xFFFFF处的RAM设置为"Read ONLY",总之,前1MB的RAM会被分成几个区域,前640K可以看作正常RAM,后面的大约384KB被BIOS的代码及其他Option ROMS所占据。




DMI: Direct Media Interface used to link NB and SB on a computer motherboard.
所以如果要模拟一个pc,首先要把GMCH的东西给模拟出来,这样虚拟PC的BIOS会检测到RAM,对于虚拟化而言,故事才刚刚开始。。。。。
阅读(5533) | 评论(4) | 转发(2) |
给主人留下些什么吧!~~

lmnos2014-04-20 18:15:02

MagicBoy2010:其实也不能说不对,只是segment与selector的区别而已,我想你肯定知道的。早期real mode没有base, limit的概念,直到引入了GDT的概念后。segment * 16 + offset是早期经典的寻址模式,现在的处理器在实模式下的CS依然是F000H,不过它叫selector,因为GDT尚无内容,硬件逻辑将CS对应的影子寄存器的base设置到了FFFF0000。这篇博文主要是从cpu虚拟化的视角,对于一个vcpu的VMCS结构而言,QEMU的虚拟化技术将VMCS.guestCS和RIP分别设置为F000和FFF0,这就是为什么我依然引用早期的模式。

按现在的说法,处理器在real mode时已经是32 bit内存寻址了,只不过还只能使用16位的指令?很久没关注过这些原始阶段的代码了。。。。。另外,我觉得FFFF0和FFFFFFF0处的指令应该是一样的,不过没有验证过

嘿嘿,看来我又班门弄斧了,不好意思

回复 | 举报

MagicBoy20102014-04-20 17:45:53

lmnos:当机器Power-ON时,x86 real mode的CS:IP=0xFFFF0, 这个不对

其实也不能说不对,只是segment与selector的区别而已,我想你肯定知道的。早期real mode没有base, limit的概念,直到引入了GDT的概念后。segment * 16 + offset是早期经典的寻址模式,现在的处理器在实模式下的CS依然是F000H,不过它叫selector,因为GDT尚无内容,硬件逻辑将CS对应的影子寄存器的base设置到了FFFF0000。这篇博文主要是从cpu虚拟化的视角,对于一个vcpu的VMCS结构而言,QEMU的虚拟化技术将VMCS.guestCS和RIP分别设置为F000和FFF0,这就是为什么我依然引用早期的模式。

按现在的说法,处理器在real mode时已经是32 bit内存寻址了,只不过还只能使用16位的指令?很久没关注过这些原始阶段的代码了。。。。。另外,我觉得FFFF0和FFFFFFF0处的指令应该是一样的,不过没有验证过

回复 | 举报

lmnos2014-04-19 19:18:48

当机器Power-ON时,x86 real mode的CS:IP=0xFFFF0, 这个不对

lmnos2014-04-19 19:14:13

不错,是这样的