KVM Implementation Mechanism

KVM Management Interface

QEMU has a deep relationship with KVM and can even assume that both sides are inherently software, and that QEMU is the control part of the application layer, and KVM is the kernel execution part. Software reuse can be so seamless to the point, is a very magical thing, also shows the KVM design time of the idea of the ingenious.

So the analysis of KVM must start with the QEMU code analysis. In order to avoid the tedious, introduce too many knowledge points, and mixed unclear. So the QEMU code is simplified.

Code Listing 2-1 QEMU startup code

S->FD = Qemu_open ("/DEV/KVM", O_RDWR);

ret = Kvm_ioctl (s, kvm_get_api_version, 0);

S->VMFD = Kvm_ioctl (S, KVM_CREATE_VM, 0);

...............................

ret = Kvm_vm_ioctl (S, Kvm_create_vcpu, Env->cpu_index);

.............................

ENV->KVM_FD = ret;

Run_ret = Kvm_vcpu_ioctl (env, Kvm_run, 0);

As you can see, KVM provides a device/DEV/KVM that the KVM control is implemented via the Io_ctl interface provided by this device. This is the most common way that the Linux kernel provides services, not to repeat them.

KVM provides three concepts, which are controlled by different io_ctl interfaces, respectively.

Q KVM: Represents the KVM module itself, used to manage KVM version information and create a VM.

Q VM: Represents a virtual machine. With the VM's Io_ctl interface, you can create vcpus for virtual machines, set memory intervals, create interrupt control chips, allocate interrupts, and more.

Q Vcpus: Represents an Vcpus. With the Io_ctl interface of Vcpus, you can start or pause the Vcpus, set up a register of Vcpus, inject interrupts for Vcpus, and so on.

The way Qemu is used, first is to open the /DEV/KVM device, create a virtual machine object through KVM_CREATE_VM, and then create an Vcpus object for the virtual machine through KVM_CREATE_VCPU, and finally through KVM_ Run to set up the Vcpus. Because it is simplified code, interrupt chip simulation, memory simulation, register settings and so on have been omitted.

KVM Implementation

The VMM,KVM is divided into two parts, namely the KVM kernel module running in kernel mode and the QEMU module running in user mode. The kernel mode and the user mode here actually refer to the privilege level 0 and Privilege Level 3 in the VMX root mode. In addition, KVM calls the operating mode in which the virtual machine is located in Guest mode. The so-called guest mode, in effect, refers to the non-root mode of VMX.

With the support of Vt-x technology,each virtual machine in KVM can have multiple virtual processor Vcpus, each of which corresponds to a qemu thread , the creation , initialization , operation of Vcpus, and Exit processing takes place in the context of the QEMU thread and requires the kernel, user, and guest three modes to mate with each other, with the working model shown in Figure 2.1. The QEMU thread interacts with the KVM kernel module in an IOCTL manner, while the KVM kernel module switches between the VM exit and the VM entry operation between the client software.

The QEMU thread instructs the KVM kernel module to create and initialize Vcpus in an IOCTL manner, primarily by creating and initializing the various data structures required by the VMM to run the Vcpus. One of the most important data structures is VMCS, whose initialization configuration is attached to 2.

After initialization is complete, theQEMU thread sends instructions to the KVM kernel module to run the Vcpus in the form of an IOCTL, which performs VM entry operations, switches the processor from kernel mode to guest mode, aborts the host software, and runs the client software instead. Note that when the host software is aborted, the kernel mode handler is in the QEMU thread context and executing the IOCTL system call. Client software during operation, such as an event such as an exception or an external interrupt, or perform I/O operations, may cause the VM exit to switch the processor state from guest mode back to kernel mode . The KVM kernel module checks the cause of the VM exit and, if the VM exit is caused by an I/O operation, performs a system call return operation, handing the I/O operation to the QEMU thread in user mode to process, and the QEMU thread executing the IOCTL again after I am done with the I/O operation. Instructs the KVM switch processor to guest mode, resumes the operation of the client software, if the VM exit is caused by other reasons, it is handled by the KVM kernel module, and then switches the processor to guest mode after processing and resumes the operation of the client.

Traditional operating system through the hardware MMU to complete the virtual address to the physical address mapping. In a virtualized environment, the guest's virtual address requires more than one layer of conversion to be placed on the address bus:

Guest virtual address, guest physical address, host physical address

MMU1 MMU2

Where MMU1 can be implemented by software simulations (vtlb in Shadow paging) or hardware implementations (Intel EPT, AMD NPT). MMU2 is provided by hardware. The system's IO virtualization technology, typically the IO request of the VMM capture guest, passes its request to the physical device through a traditional device that is simulated by the software. Some new devices that support virtualization technology, through hardware technology such as Intel vt-d, can be assigned directly to the guest operating system to avoid software overhead.