【问题标题】:Memory protection between QEMU virtual CPUs for two processes of the same Guest同一Guest的两个进程的QEMU虚拟CPU之间的内存保护
【发布时间】:2020-11-26 21:38:56
【问题描述】:
假设客户操作系统使用 2 个 vCPU (-smp 2) 在 QEMU/KVM 上运行,我的理解是每个 vCPU 实际上将映射到一个 QEMU 线程,以允许在真正的多核系统上进行并行处理。
例如here 和here 对此进行了解释。
在这种情况下,QEMU如何保证这些线程之间在内存中的分离?
我认为这是必需的,因为两个 vCPU 可能正在执行两个不共享任何内存的不同来宾进程。如果它们映射到 Host 线程,它们实际上是在同一个虚拟地址空间中运行的吗?
我错过了什么吗?
【问题讨论】:
标签:
linux
operating-system
virtualization
qemu
kvm
【解决方案1】:
使用 KVM 时,来宾用户空间进程之间的分离由来宾操作系统和硬件处理。当主机 CPU 具有对虚拟化的硬件支持时,这意味着(除其他外)它不仅支持通常的虚拟->物理地址转换,而且还支持两阶段的 guest-virtual-address -> guest-physical-address -> host -物理地址转换。当客户操作系统运行多个用户空间进程时,它会像往常一样设置 CPU 的 MMU,从而控制客户 VA 到客户 PA 的转换。这可以防止一个客户操作系统进程看到另一个完全拥有的内存,就像客户操作系统在真实硬件上运行时一样。
转换的第二阶段(客户物理到主机物理)是管理程序控制的阶段;在这种情况下是 QEMU 和 KVM。这在所有 vCPU 之间共享,就像在真实物理机器中每个 CPU 看到并共享相同的物理内存布局一样。
还请注意,虽然每个 vCPU 确实是一个“线程”,但该线程在执行来宾代码时看到的行为和环境与它在用户空间中运行时看到的完全不同QEMU。作为 QEMU 的一部分,线程与其他线程一样,但它执行 KVM_RUN ioctl,并且控制进入主机内核,然后它纯粹使用该线程作为调度和控制 vCPU 的一种方式。当 vCPU 运行来宾代码时,它只能看到 VM 提供的错觉,并且无法直接访问 QEMU 进程。最终,当控制权从来宾代码返回时,主机内核会导致 KVM_RUN ioctl 返回,并且“正常”用户空间线程行为恢复。