同一个Guest的两个进程QEMU虚拟CPU之间的内存保护
Memory protection between QEMU virtual CPUs for two processes of the same Guest
假设客户机 OS 在 QEMU/KVM 上 运行 使用 2 个 vCPU (-smp 2)，我的理解是每个 vCPU 实际上将映射到一个 QEMU 线程以允许在真正的多核系统上并行。
在这种情况下，QEMU如何保证这些线程在内存中的分离？
我认为这是必需的，因为两个 vCPU 可能正在执行两个不共享任何内存的不同来宾进程。如果它们被映射到主机线程，它们实际上是运行在同一个虚拟地址space吗？
我是不是漏掉了什么？
使用 KVM 时，来宾用户空间进程之间的分离由来宾 OS 和硬件处理。当主机 CPU 具有虚拟化硬件支持时，这意味着（除其他外）它不仅支持通常的虚拟->物理地址转换，而且支持 two-stage guest-virtual-address -> guest-physical-address -> host-physical-address 翻译。当来宾 OS 运行多个用户空间进程时，它会像往常一样设置 CPU 的 MMU，并控制 guest-VA 到 guest-PA 的转换。这可以防止一个来宾 OS 进程看到另一个拥有的内存，就像来宾 OS 在真实硬件上 运行 一样。
翻译的第二阶段（guest-physical 到 host-physical）是管理程序控制的；在本例中是 QEMU 和 KVM。这在所有 vCPU 之间共享，就像在真实物理机器中每个 CPU 看到并共享相同的物理内存布局一样。
另请注意，虽然每个 vCPU 确实是一个“线程”，但该线程在执行访客代码时所看到的行为和环境与执行来宾代码时所看到的完全不同作为 QEMU 的一部分，它在用户空间中是 运行。作为 QEMU 的一部分，该线程与其他任何线程一样，但它执行 KVM_RUN ioctl，并且控制权进入主机内核，然后该线程纯粹用作调度和控制 vCPU .当 vCPU 是 运行 访客代码时，它只能看到 VM 提供的假象，无法直接访问 QEMU 进程。最终，当控制从客户代码返回时，主机内核导致 KVM_RUN ioctl 变为 return 并且“正常”user-space 线程行为恢复。
假设客户机 OS 在 QEMU/KVM 上 运行 使用 2 个 vCPU (-smp 2)，我的理解是每个 vCPU 实际上将映射到一个 QEMU 线程以允许在真正的多核系统上并行。
在这种情况下，QEMU如何保证这些线程在内存中的分离？
我认为这是必需的，因为两个 vCPU 可能正在执行两个不共享任何内存的不同来宾进程。如果它们被映射到主机线程，它们实际上是运行在同一个虚拟地址space吗？
我是不是漏掉了什么？
使用 KVM 时，来宾用户空间进程之间的分离由来宾 OS 和硬件处理。当主机 CPU 具有虚拟化硬件支持时，这意味着（除其他外）它不仅支持通常的虚拟->物理地址转换，而且支持 two-stage guest-virtual-address -> guest-physical-address -> host-physical-address 翻译。当来宾 OS 运行多个用户空间进程时，它会像往常一样设置 CPU 的 MMU，并控制 guest-VA 到 guest-PA 的转换。这可以防止一个来宾 OS 进程看到另一个拥有的内存，就像来宾 OS 在真实硬件上 运行 一样。
翻译的第二阶段（guest-physical 到 host-physical）是管理程序控制的；在本例中是 QEMU 和 KVM。这在所有 vCPU 之间共享，就像在真实物理机器中每个 CPU 看到并共享相同的物理内存布局一样。
另请注意，虽然每个 vCPU 确实是一个“线程”，但该线程在执行访客代码时所看到的行为和环境与执行来宾代码时所看到的完全不同作为 QEMU 的一部分，它在用户空间中是 运行。作为 QEMU 的一部分，该线程与其他任何线程一样，但它执行 KVM_RUN ioctl，并且控制权进入主机内核，然后该线程纯粹用作调度和控制 vCPU .当 vCPU 是 运行 访客代码时，它只能看到 VM 提供的假象，无法直接访问 QEMU 进程。最终，当控制从客户代码返回时，主机内核导致 KVM_RUN ioctl 变为 return 并且“正常”user-space 线程行为恢复。