hypervisor guest os中的内存地址转换

dae*_*hee 4 linux memory virtualization virtual-machine virtual-memory

假设有这样的代码.

MOV [0x1234], EAX (intel assembly)
Run Code Online (Sandbox Code Playgroud)

假设CPU想要处理此指令.我们假设没有管理程序.我们只是在linux环境中使用普通的x86 CPU(保护模式).

现在,我理解的是,因为0x1234是一个虚拟地址,所以需要将其转换为物理地址.(让我们跳过分段部分)

CPU只是将此地址(0x1234)传递给MMU硬件.MMU遍历页表并使用物理地址访问内存内容.

我对么?

现在让我们假设有一个虚拟机管理程序,这个代码是从客户操作系统运行的.

究竟发生了什么?

我知道虚拟机管理程序提供了另一层页表.但我不明白这究竟是如何运作的.

如果客户代码"MOV [0x1234],EAX"在真实CPU中执行.虚拟地址0x1234将由真实硬件MMU转换.所以我认为必须重写这条指令(0x1234应该在执行代码之前替换为另一个地址),或者被困在管理程序中......

我错了吗?如果我错了,请修正我的理解......

先感谢您.

Ben*_*oit 5

回答你的第一个问题:是的,你是.这基本上就是虚拟内存的工作原理.

现在,让我们看看当MMU和客户操作系统之间运行虚拟机管理程序时会发生什么.出于性能考虑,虚拟机管理程序(无论是类型1还是类型2)都会尝试避免在每个来宾操作系统内存访问时进行陷阱.我们的想法是客户操作系统管理MMU.我将详细介绍可能的实现,一个用于x86,另一个用于PowerPC.

在x86上,来自英特尔的手册3B:

27.3.2访客和主机物理地址空间

内存虚拟化为访客软件提供从零开始的连续访客物理地址空间,并扩展到访客虚拟处理器的物理地址宽度支持的最大地址.VMM利用客户物理到主机物理地址映射来定位主机存储器中的客户物理地址空间的全部或部分.VMM负责该映射的策略和算法,其可以考虑主机系统物理存储器映射和VMM向客户机暴露的虚拟化物理存储器映射.

VMM知道PDBRVM 的当前基地址(PDBRCR3寄存器中保持),因为访问CR3将导致VM_EXIT.VMM将能够代表来宾操作系统维护真实页面目录.我的意思是当客户操作系统修改其页面目录以将逻辑地址A映射到物理地址B时,VMM对此进行陷阱,而不是将A映射到B,它将A映射到C.因此,对A的任何进一步访问都不会导致#PF,它将通过MMU完美地路由到C.这种方法的悲哀之处在于客户认为它已将A映射到B,但实际上A映射到C,因此VMM必须维护虚拟页面目录,以防客户端读取它先前映射到A的位置. VMM捕获此读取访问权限,而不是将A映射到B,而是返回到A映射到C的guest虚拟机.

27.3.3通过暴力虚拟化虚拟内存

一种简单的方法是确保所有访客尝试访问地址转换硬件陷阱到VMM,在VMM中可以正确模拟这些操作.它必须确保对页面目录和页表的访问也会被捕获.这可以通过使用传统的基于页面的保护来保护这些内存中结构来完成.VMM可以这样做,因为它可以找到页面目录,因为它的基地址在CR3中,VMM接收对CR3的任何更改的控制权; 它可以找到页表,因为它们的基地址在页面目录中.

在PowerPC上,您没有像英特尔那样的页面目录的硬件表格.TLB的每次修改都是由一条指令引起的,通常来自内核内存管理器.同样,一个直截了当的想法是捕获每个访客对TLB的访问权限(tlbwe例如,当guest虚拟机执行指令时设置导致VM退出的事项;注意:tlbwe将条目写入TLB).一旦进入VMM,管理程序就会对陷阱指令进行解码,并模拟其行为,但不是将A映射到B,而是将A映射到C,直接映射到TLB.同样,VMM必须维护虚拟TLB,以防客户操作系统想要检查TLB中的内容,并返回它认为早先放入TLB的内容.

总而言之,虽然某些硬件功能有助于虚拟化客户物理内存,但通常由VMM来管理有效的客户 - 物理到主机 - 物理内存映射.

  • 谢谢你这是非常有帮助的答案!! (2认同)