CODEWITHSUNDEEP
linuxoperating-systemvirtualizationqemukvm
Daniele Faugiana
Daniele Faugiana

Reputation: 994

Memory protection between QEMU virtual CPUs for two processes of the same Guest

Assuming that a guest OS is running on QEMU/KVM using 2 vCPU (-smp 2), my understanding is that each vCPU will be actually mapped to a QEMU thread to allow parallelism on real multicore systems.

This is explained here, and here for instance.

In this case, how does QEMU guarantee the separation in memory between such threads?

I think this is required as the two vCPU could be executing two different Guest processes that don't share any memory. If they are mapped to Host threads, are they actually running in the same virtual address space?

Am I missing something?

Upvotes: 2

Views: 784

Answers (1)

Peter Maydell
Peter Maydell

Reputation: 11383

When using KVM, the separation between guest userspace processes is handled by the guest OS and by the hardware. When the host CPU has hardware support for virtualization this means that (among other things) it supports not just the usual virtual->physical address translation, but a two-stage guest-virtual-address -> guest-physical-address -> host-physical-address translation. When the guest OS runs multiple userspace processes, it sets up the CPU's MMU as it would normally, and this controls the guest-VA to guest-PA translation. This keeps one guest OS process from seeing memory that the other owns exactly as it would if the guest OS were running on real hardware.

The second stage of translation (guest-physical to host-physical) is the one that the hypervisor controls; in this case that's QEMU and KVM. This is shared between all the vCPUs, in the same way that in a real physical machine every CPU sees and shares the same physical memory layout.

Note also that although it is true that each vCPU is a "thread", the behaviour and the environment that that thread sees is completely different when it is executing the guest code than what it sees when it's running in userspace as part of QEMU. As part of QEMU the thread is like any other, but it executes the KVM_RUN ioctl, and control goes into the host kernel, which then uses that thread purely as a way to schedule and control the vCPU. When the vCPU is running guest code it sees only the illusion provided by the VM and has no direct access to the QEMU process. Eventually when control comes back from guest code the host kernel causes the KVM_RUN ioctl to return and the "normal" user-space thread behaviour resumes.

Upvotes: 3

Related Questions