CPU Pure Software Semi-virtualization technology

In 2003, Xen emerged using an alternative semi-virtualized solution to solve the CPU-sensitive instruction problem in the x86 architecture. The main use of hypercall technology. Part of the code for the guest OS is changed so that the guest OS translates the operations associated with the privileged instructions into Hypercall (super Call) to VMM, which is processed by VMM. The two optimizations of batch and asynchronous supported by Hypercall make it possible to get the approximate speed of a physical machine by Hypercall.

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M02/79/F3/wKiom1afF8rRLK3ZAACfLO6bwIA867.png "title=" 1.png " alt= "Wkiom1aff8rrlk3zaacflo6bwia867.png"/>

1. Hypercall Technology

For the x86 architecture, Cpu,xen uses a super call to replace the monitored operation, which includes sensitive instructions under the x86 schema. The super-replacement approach adopted by Xen is a new design concept: It moves the center of the problem from VMM to the guest OS itself, by proactively handling these instructions from the guest OS, rather than being handed over to the VMM for processing, and in this design concept, modifying the guest OS kernel.

The ability to modify the guest OS is a technical core of para-virtualization. By modifying the kernel of the guest OS. Making the guest OS clearly aware that it is running on the 1 ring, rather than the 0 loop of the usual OS, effectively avoids the problem of virtualized execution conflicts. The Guest OS also knows that VMM provides itself with a virtual register group and can access them in other ways, avoiding the problem of access violations.

Addressing the issue of sensitive instructions only solves the first step of semi-virtualization under the x86 architecture. Instructions that run on the 1-ring operating system do not have permission to execute, which is handled by the 0-ring VMM, much like the application's system invocation: The function of a system call is to give the operating system the command that the application does not have permission to execute. As a result, Xen provides a set of "system calls" to the guest OS. For the convenience of the guest OS call, this part of "system call" is super call Hypercall.

The mechanism of super call Hypercall not only implements the instruction virtualization of the x86 architecture, but also provides new ideas and methods for the later memory virtualization and I/O virtualization, and the super Call and event channel are the basis of the whole semi-virtualized.

Let's take a look at the overall access flowchart for the semi-virtualized scenario.

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M01/79/F3/wKiom1afF9-BZbZuAAAotW_0zjg092.png "title=" 1.png " alt= "Wkiom1aff9-bzbzuaaaotw_0zjg092.png"/>

CPU Semi-virtualized technology

Explicitly shows the Hypercall call location, in Xen, each component communicates as follows, and the Hypercall call nature is synchronous. Other Xen communication methods are almost always asynchronous.

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M00/79/F3/wKiom1afF_iQ2q87AACww5CfWNE788.png "title=" 1.png " Width= "578" height= "213" border= "0" hspace= "0" vspace= "0" style= "width:578px;height:213px;" alt= "wkiom1aff_ Iq2q87aacww5cfwne788.png "/>

In the process of communication between the virtual machine and Xen, if the virtual machine needs to invoke the sensitive instruction, it will initiate the Hypercall call to the virtual machine monitor actively. Hypercall is like a system call under a traditional operating system, which provides various services to the virtual machines on which it is operated, such as MMU Update, Domain0 operation request, and virtual processor state.

Shows the privileged mode in the semi-virtualized mode:

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M01/79/F2/wKioL1afGFCTwrrgAADLqoaNu8Q729.png "title=" 1.png " alt= "Wkiol1afgfctwrrgaadlqoanu8q729.png"/>

Under the x86 architecture, there are differences between the native system and the semi-virtualized environment. In a native environment, the CPU has 4 privileged levels (RING0--RING3), the operating system is at the highest level of RING0, and the application is at the lowest ring3. In a semi-virtualized environment, the virtual machine monitor is at the highest level of RING0, the operating system is at the intermediate level of ring1, and the application is at the lowest ring3.

650) this.width=650; "src=" Http://s5.51cto.com/wyfs02/M01/79/F3/wKiom1afGCqRoKQeAABTEciqbX8993.png "title=" 1.png " alt= "Wkiom1afgcqrokqeaabteciqbx8993.png"/>

Only code with a privileged level of 1 (the kernel of the quasi-virtualized guest VM) can send hypercall requests to Xen to prevent possible damage to the system by an application (Privilege level 3) Error call. Therefore, only the virtual machine operating system kernel running at privileged Level 1 can request hypercall. However, some Xen-specific special programs, such as Xend or XE, also require hypervisor services to perform special operations, such as generating a new GUESTVM, which is implemented in Xen Linux through a kernel driver called Privcmd. The application made a service request to the driver through the IOCTL, and the Privcmd driver running at the virtual machine kernel (Privilege level 1) then turned the service request in hypercall form to hypervisor, and the latter actually completed the action of generating the new guest VM.

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M02/79/F2/wKioL1afGH6wRgTgAAELB5Omcd0071.png "title=" 1.png " alt= "Wkiol1afgh6wrgtgaaelb5omcd0071.png"/>

Shows where Hypercall is located, Hypercall is in the upper-right corner of the diagram, where the kernel initiates the call to Hypervisor. Xen enables the 130th interrupt vector port (16 binary 82H) as the interrupt number for the super call. The DPL of this interrupt vector is set to type 1, and the type is the interrupt gate. In this way, the super call can be initiated by the client operating system at privileged Level 1 and not from the user state.

In addition, there are 17 instructions in the x86 instruction set that cannot be effectively run on the Ring 1 privilege level, and the presence of Hypercall solves the problem that these instructions cannot be executed properly.

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/79/F2/wKioL1afGJeBGHKJAAGdRJhdhPM639.png "title=" 1.png " alt= "Wkiol1afgjebghkjaagdrjhdhpm639.png"/>

In the hypercall mechanism, under the 32-bit x86 architecture, Hypercall is implemented through the INT0X82 Trap directive because the traditional operating system itself does not use INT0X82 (Linux uses int 0x80 as the system invoke Directive, int 0x82 Not used).

INT0X82 includes:

• Super CALL Number: 45 Super calls are defined in Xen/include/public/xen.h, and 7 of them are platform-dependent calls.

• Super Call Table: Xen/arch/x86/x86_32/entry. The Super call table is defined in S, and the corresponding processing function can be conveniently found by the Super Call index.

• Super Call page: The Super Call page is a page that Xen prepares for the guest OS and can do different guest OS with different Super call page content.

The specific function identification number of the Hypercall is indicated by EAX, while the other parameters are in ebx, ecx, edx, ESI, and EDI. To reduce the number of privilege level (Ring) switches between virtual machines and hypervisor, Xen provides batch processing of Hypercall, with several Hypercall feature requests placed in a single list that are completed by a dedicated Hypercall batch request. In Xen, both the system call table and the Hypercall table are entry. is defined in the S file.

2. X86 Architecture Privilege Level

The x86 hardware supports 4 privilege levels (ring), the general kernel runs in ring 0, the user application runs in Ring 3, and the smaller ring has more system global resources than the higher ring can access, that is, higher privileges. Some instructions can only be executed correctly in ring 0, such as LGDT, LMSW directives, which we call privileged commands, and others that are executed correctly in ring 3, such as SGDT, SMSW, and Pushf/popf, which we call non-privileged instructions.

In both normal mode and virtualization scenarios, the privileged mode is described as follows:

Normal mode : The privilege level is for the segment, the last two bits of the segment descriptor identify the level of privilege at which the segment is located, for example, the interrupt handler runs on RING0 (), at which point the kernel program is privileged, that is, RING0. The RING3 user program can be called by the system, INT80, after the privilege is flipped into the RING0, and then can execute the interrupt handler smoothly (as if the user program calls the kernel program the only way).

In the case of virtualization :

Privilege cancellation: Refers to the release of a section that normally runs in ring0, such as an interrupt handler, which, in order to be virtualized, unlocks its privileges at this time and runs it on Ring1. When the user program is called through the system, its jump to the interrupt handler runs on ring1. However, in an interrupt handler, some of the instructions are required to be executed at RING0, and are automatically caught and then emulated. That is, the user program runs the privileged instruction, there will be two privilege drops, once through the system call into the RING1, the second is through the privileged command into the RING0. This means that the interrupt handler at the time of the interrupt is still the previous code in the kernel, but its runlevel is ring1, and some instructions need to be caught again before they can be executed. Another important issue is the problem that some sensitive, non-privileged instructions cannot get into: There are binary translations, super calls, and so on, forcing them into, and then simulating.

The following issues exist in support of virtualization on traditional X86 platforms:

There are 17 sensitive non-privileged directives in the X86 instruction set, and "non-privileged instructions" indicate that these instructions can be executed in x86 ring 3, while "sensitivity" indicates that VMM cannot easily allow the guest operating system to execute these instructions. The execution of these 17 instructions on the guest operating system may cause damage to the global state of the system, such as Popf instructions, or may cause problems with the guest operating system logic, such as reading the system state or the command of the control register, such as SMSW. Traditional X86 cannot capture these sensitive, non-privileged instructions.

In addition to the 17 sensitive non-privileged instructions, other sensitive instructions are sensitive privileged commands. In x86 virtualized environments, VMM needs to have unified control of system resources, so it must occupy the highest privileged level, that is, ring 0, so in order to capture privileged instructions, a direct feasible method in traditional x86 is "Ring deprivileging", such as the privileges of the guest operating system kernel Level from ring 0 to ring 1 or ring 3, that is, "eliminate" the privileges of the guest core, to lower than the ring 0 in which VMM is located, so that VMM captures sensitive privileged instructions.

3. Summary

The idea of semi-virtualized is to let the customer operating system know that they are running on the virtual machine, working in a non-RING0 state, then it was originally executed on the physical machine, some of the privileged instructions will be modified to other ways, this method can be agreed with the VMM, which is equivalent to, Porting the operating system to a new architecture by modifying the code is like customizing. So Xen is a semi-virtualized technology, the guest operating system has a dedicated custom kernel version, and x86, MIPS, ARM these kernel versions. In this way, there will be no catch-up anomaly, translation, simulation process, performance loss is very low. This is the advantage of this semi-virtualized architecture for Xen. This is why Xen virtualization only supports virtualized Linux and cannot virtualize windows because Microsoft does not modify the code to achieve semi-virtualized.

This article is from "I take fleeting chaos" blog, please be sure to keep this source http://tasnrh.blog.51cto.com/4141731/1736761

CPU Pure Software Semi-virtualization technology