KR20080079852A - CPU virtualization method - Google Patents

Abstract

The present invention relates to a CPU virtualization method.

A CPU virtualization method according to an embodiment of the present invention includes: providing a virtualization unit which simultaneously runs a plurality of guest operating systems and runs in a privileged mode of a processor; Partitioning and generating a non-privileged mode of the processor into at least two virtual sub modes hierarchically ordered; Transitioning to the virtualization unit when a privilege command occurs in the virtual lower mode; Transmitting, by the virtualization unit, the privilege command to a hierarchical mode that processes the privilege command among the virtual lower modes; Processing the privileged command in a hierarchical mode of processing the privileged command, maintaining the mode as it is, or transitioning to one of the other virtual sub-modes.

Description

CPU virtualization method

1 is a diagram illustrating a CPU mode of Xen;

2 is a configuration block diagram for virtualizing a CPU according to an embodiment of the present invention;

3 and 4 are flowcharts illustrating a method for processing a system event in a virtual CPU mode according to an embodiment of the present invention;

5 is a block diagram illustrating a virtual stack pointer management method according to an embodiment of the present invention;

6 is a flowchart specifically illustrating a system event processing method of FIGS. 3 and 4;

7 is a flowchart illustrating a method of switching from a virtual kernel mode to a virtual user mode according to an embodiment of the present invention;

8 is a flowchart specifically showing a processing method of a virtual PSR according to an embodiment of the present invention.

<Explanation of symbols for the main parts of the drawings>

10: virtual machine monitor 12: VMM exception vector

14 VMM event processing unit 16: virtual kernel mode switch unit

18: hyper call processing unit (18) 20: guest operating system

22: user program 24: virtual user mode

26: Kernel Program 28: Virtual Kernel Mode

30: Guest operating system callback routine 32: Guest operating system exception vector

34: guest operating system exception handler 40: shared memory

The present invention relates to a CPU virtualization method, and more particularly, to a CPU virtualization method that enables an operating system operating in a processor having two CPU modes to be stably and efficiently paravirtualized in one CPU mode.

Operating System (OS) is a set of programs that provides an interface for a user to use hardware more easily in a computer device such as a personal computer (PC), and includes a processor, a memory device, an input / output device, and a communication device. Manage resources such as devices and data.

Since the development of the IBM System / 360, which is the beginning of the operating system, personal computer devices have been developed into Windows XP through MS's DOS, window 3.1, window 95, and window 98. In contrast, Windows NT, window 2000, UNIX, and UNIX-based operating systems such as Solaris and LINUX are widely used for workstations and servers equipped with high-performance microprocessors.

On the other hand, users may install and use a plurality of operating systems on one recording medium depending on the purpose or need. For example, install Windows XP and LINUX in two logically partitioned areas on one recording medium, install applications supported by the operating system on each operating system, and then boot the computer device to the desired operating system. To perform the operation in the operating system.

As such, installing a plurality of operating systems and booting the operating system selected by the user is referred to as multibooting. However, in multi-booting, it is troublesome to reboot the computer device in order to switch from one operating system to another.

In order to solve this problem, a virtualization technology has been proposed that enables a plurality of operating systems to run on one platform. More specifically, the virtualization technology may include a virtual machine monitor (VMM) or a hypervisor that forms a virtualization layer on a host OS or directly provides a virtualization layer. ), So that a plurality of logical virtual machines (VMs) are created on this virtualization layer. A guest OS may be installed in each of the plurality of virtual machines, and a program supported by the corresponding guest OS may be installed on each guest OS.

These virtualization technologies include full-virtualization that does not require modification of the guest operating system, and para-virtualization that requires modification of the guest operating system for the purpose of minimizing performance degradation and enhancing security in preparation for the existing guest operating system. virtualization).

Figure 1 illustrates the Central Processing Unit (CPU) mode of Xen, a virtualization technology based on Intel x86 processors. VirtualPC and VMWare apply full-virtualization technology, while Xen uses para-virtualization technology that requires modification of the operating system to specific hardware architectures.

As shown in FIG. 1, based on three CPU modes of x86 in Xen, the Xen VMM 100 is in CPU ring 0, the kernel 102 of the guest operating system in CPU ring 1, and the user program. (user application) 104 operates on CPU ring 3.

Meanwhile, an embedded processor such as an ARM processor has two CPU modes, a user mode and a privileged mode. The user program runs in user mode and the kernel runs in privileged mode.

Therefore, Xen, based on three CPU modes, cannot be used on ARM processors in two modes, and must be ported anew if desired.

In addition, when the virtual machine monitor 10 is operated in the privileged mode of the processor when the operating system operating in the system having two CPU modes (eg, the user mode and the privileged mode) is modified, the kernel of the guest operating system is changed. The user program must be modified to run in user mode. However, since the existing operating system is already implemented to operate in two CPU modes, some code of the relevant kernel must be modified.

SUMMARY OF THE INVENTION The present invention has been made to solve the above problems, and an object of the present invention is to provide a CPU virtualization method that enables an operating system operating in a processor having two CPU modes to be stably and efficiently paravirtualized in one CPU mode. There is this.

However, the objects of the present invention are not limited to the above-mentioned objects, and other objects not mentioned will be clearly understood by those skilled in the art from the following description.

In order to achieve the above object, a CPU virtualization method according to an embodiment of the present invention comprises: providing a virtualization unit which simultaneously runs a plurality of guest operating systems and runs in a privileged mode of a processor; Partitioning and generating a non-privileged mode of the processor into at least two virtual sub modes hierarchically ordered; Transitioning to the virtualization unit when a privilege command occurs in the virtual lower mode; Transmitting, by the virtualization unit, the privilege command to a hierarchical mode that processes the privilege command among the virtual lower modes; Processing the privileged command in a hierarchical mode of processing the privileged command, maintaining the mode as it is, or transitioning to one of the other virtual sub-modes.

Specific details of other embodiments are included in the detailed description and drawings, and the advantages and features of the present invention and methods for achieving them will be apparent with reference to the embodiments described below in detail with the accompanying drawings.

However, the present invention is not limited to the embodiments disclosed below, but may be embodied in various different forms, and the present embodiments merely make the disclosure of the present invention complete and common knowledge in the technical field to which the present invention belongs. It is provided to fully inform the person having the scope of the invention, which is defined only by the scope of the claims. Like reference numerals refer to like elements throughout.

Hereinafter, a CPU virtualization method according to an embodiment of the present invention will be described with reference to the accompanying block diagrams or the drawings of the processing flowchart.

At this point, it will be understood that each block of the flowchart illustrations and combinations of flowchart illustrations may be performed by computer program instructions.

Since these computer program instructions may be mounted on a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, those instructions executed through the processor of the computer or other programmable data processing equipment may be described in flow chart block (s). It creates a means to perform the functions.

These computer program instructions may be stored in a computer usable or computer readable memory that can be directed to a computer or other programmable data processing equipment to implement functionality in a particular manner, and thus the computer usable or computer readable memory. It is also possible for the instructions stored in to produce an article of manufacture containing instruction means for performing the functions described in the flowchart block (s). Computer program instructions It can also be mounted on a computer or other programmable data processing equipment, so that a series of operating steps are performed on the computer or other programmable data processing equipment to create a computer-implemented process to create a computer or other programmable data processing equipment. The instructions that perform may also provide steps for performing the functions described in the flowchart block (s).

In addition, each block may represent a portion of a module, segment, or code that includes one or more executable instructions for executing a specified logical function (s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of order. For example, the two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the corresponding function.

2 illustrates a configuration block diagram for virtualizing a CPU according to an embodiment of the present invention.

Meanwhile, in the exemplary embodiment of the present invention, 'system event' is a privileged command and is used as a term including an event generated by an exception or an interrupt. In addition, 'exception' refers to an attempt to execute an instruction not defined in the processor, an access to an operating system function that requires permission, and the like.

The apparatus for virtualizing the illustrated CPU includes a virtual machine monitor 10 providing a virtualization layer and a guest operating system 20 running on the virtual machine monitor 10. Here, the guest operating system 20 may be one or more.

In a system having two CPU modes (e.g., user mode, privileged mode), virtual machine monitor 10 operates in privileged mode, and guest operating system 20 operates in non-privileged user mode.

The non-privileged user mode is the virtual user mode 24 which is the user program 22 execution mode and the virtual kernel mode which is the kernel program 26 execution mode by the virtual machine monitor 10. Is divided into (28). The virtual user mode 24 and the virtual kernel mode 28 are hierarchically ordered, and the virtual kernel mode 28 is preferably a higher layer mode than the virtual user mode 24. In the present embodiment, the non-privileged mode is divided into two virtual sub-modes, the virtual user mode 24 and the virtual kernel mode 28. However, the non-privileged mode may be more than that.

In the virtual kernel mode 28, a guest for handling an exception according to a callback routine 30 of a guest operating system 20, which is given control from the virtual machine monitor 10, and an instruction of the callback routine 30. An exception handler 34 of the operating system 20 operates.

The callback routine 30 branches to the exception vector 32 of the guest operating system 20 using the offset value of the vector stored in the processor's register.

In an existing operating system, the first part of a system event is the exception vector. However, the guest operating system 20 on the virtual machine monitor 10 performs some sort of callback routine 30 where control is passed by the virtual machine monitor 10 before branching to the exception vector 32. The callback routine 30 is set to branch to the virtual exception vector 32 using the virtual CPU context generated by the virtual machine monitor 10. Thus, it is possible to secure stability by minimizing kernel modification of the guest operating system 20.

The guest operating system 20 exception processing unit 34 may be one or more routines that are called according to the value of the guest operating system 20 exception vector 32 to perform different instructions.

The virtual machine monitor 10 includes a VMM exception vector 12 and a VMM event processor 14, a virtual kernel mode switch unit 16, and a hypercall processor 18 for handling exceptions.

The virtual kernel mode switching unit 16 is a part for switching from the virtual machine monitor 10 to the virtual kernel mode 28 in order to process a system event in the virtual kernel mode 28.

The hypercall processing unit 18 performs a corresponding command according to the hypercall request. Here, the hypercall refers to a kind of system call requested by the guest operating system 20 or the kernel of the guest operating system 20 to perform a specific command to the virtual machine monitor 10.

The apparatus for virtualizing the illustrated CPU further includes a shared memory 40 provided for sharing information between the kernel of the virtual machine monitor 10 and the guest operating system 20.

The virtual machine monitor 10 and the guest operating system 20 need the virtual CPU mode information at the time the system event occurs, and the shared memory 40 stores the virtual CPU mode information. Accordingly, the virtual CPU mode information can be read / written as necessary.

Specifically, the virtual memory mode information is stored in the shared memory 40 when switching from the virtual machine monitor 10 to the virtual kernel mode 28, and the virtual when switching from the virtual kernel mode 28 to the virtual user mode 24. User mode information is stored. That is, the virtual CPU mode information currently being executed is stored.

The shared memory 40 also stores a virtual user mode stack pointer and a virtual kernel mode stack pointer. The reason for storing the stack pointer of each mode in the shared memory 40 is to restore the CPU context when returning to each mode after processing the system event.

Of course, although shown in the block diagram of the configuration when an exception occurs as a system event, an interrupt vector by interrupt, an interrupt handler, and the like may be configured.

3 and 4 are flowcharts illustrating a method for processing a system event in a virtual CPU mode according to an embodiment of the present invention.

Meanwhile, when implementing a virtualization of an operating system designed to operate the kernel and the user program 22 in two CPU modes, a stack pointer (SP) management method considering the virtual machine monitor 10 is required. In particular, when the virtual machine monitor 10 is operated in a privileged mode, the virtual user mode stack pointer and the virtual kernel mode stack pointer must be managed separately. The virtual stack pointer management method will also be described with reference to the flowcharts of FIGS. 3 and 4.

First, when code is running in the user program 22 (virtual user mode 24) or kernel program 26 (virtual kernel mode 28) of the guest operating system 20 in the virtual machine monitor 10 environment, When a system event occurs (S100), control passes to an event handler 14 such as an exception handler or interrupt handler of the virtual machine monitor 10.

At this time, the virtual machine monitor 10 stores the CPU context of the current state (virtual user mode 24 or virtual kernel mode 28) in a stack frame (S102). The virtual CPU mode information stored in the shared memory 40 is read, and the virtual CPU mode in which the system event occurs is determined (S104).

The event processing unit 14 of the virtual machine monitor 10 stores the stack pointer value of the determined mode in the shared memory 40 (S106 and S108). For example, if a system event occurs while executing the virtual user mode 24, the virtual user mode stack pointer value is stored in a field holding the virtual user mode stack pointer of the shared memory 40, and the virtual kernel mode 28 is stored. If a system event occurs during execution, the virtual kernel mode stack pointer value is stored in a field holding the virtual kernel mode stack pointer of the shared memory 40.

Thereafter, the event processing unit 14 of the virtual machine monitor 10 performs primary processing on the system event (S110), and transfers control to the virtual kernel mode 28 of the guest operating system 20, shared memory. The virtual kernel mode information is stored in the virtual CPU mode information field of 40 (S112), and the virtual kernel mode stack pointer value stored in the shared memory 40 is read (S114). The virtual machine monitor 10 updates the virtual kernel mode stack pointer value of the stack frame to set CPU context information and switches to the virtual kernel mode 28 of the guest operating system 20 (S116).

When the processing of the system event is completed in the virtual kernel mode 28 of the guest operating system 20 (S118), it is checked whether the switch to the virtual user mode 24 is necessary, and requests a hypercall if necessary. (S120).

Then, the virtual machine monitor 10 stores the virtual user mode information in the virtual CPU mode information field of the shared memory 40 (S122), reads the virtual user mode stack pointer value stored in the shared memory 40 (S124). In step S126, the CPU context of the virtual user mode 24 is restored (S126) and the virtual user mode 24 is switched from the virtual kernel mode 28 to the virtual user mode 24 (S128).

On the other hand, although not shown, when the hypercall request to the virtual machine monitor 10 in the virtual kernel mode 28, the virtual kernel mode stack pointer value is stored in the shared memory 40, of course.

Meanwhile, referring to FIGS. 3 and 4, when a system event occurs in the virtual user mode 24 and returns to the virtual user mode 24 or transitions to the virtual kernel mode 28 after the event processing, the virtual kernel mode ( There is a case where a system event occurs in 28) and transitions to the virtual user mode 24 after the event processing or returns to the virtual kernel mode 28. However, it is more preferable to return to the mode where the system event occurred.

5 is a block diagram illustrating an example of a stack pointer processing method when a system event occurs in a virtual user mode.

When a system event occurs in the virtual user mode 24, the virtual machine monitor 10 stores the virtual user mode stack pointer in the shared memory 40. The CPU context is restored by reading the virtual kernel mode stack pointer stored in the shared memory 40 to transmit the system event information to the virtual kernel mode 28. After returning to the virtual user mode 24 after the system event processing in the virtual kernel mode 28 is completed, the virtual machine monitor stores the virtual kernel mode stack pointer in the shared memory 40 and receives a hypercall from the kernel. The hypercall processor 18 of 10 reads the virtual user mode stack pointer stored in the shared memory 40 to restore the CPU context. In this way, switching between modes is possible.

6 is a flowchart specifically illustrating a system event processing method of FIGS. 3 and 4.

First, when an exception occurs, for example, as a system event (S130), the virtual machine monitor 10 stores the exception vector 12 value in a stack frame so that the guest operating system 20 uses it (S132). ). Then, the event processing unit 14 performs the processing (S134). Thereafter, event information must be delivered to the guest operating system 20, which is handled by the virtual kernel mode switcher 16.

The virtual kernel mode switching unit 16 performs a task of restoring the virtual kernel mode 28 CPU context (S136). In operation S138, the guest operating system 20 may check whether an exception may be received (S138).

In the callback routine 30 of the virtual kernel mode 28, which has passed control from the virtual machine monitor 10, the callback routine 30 branches to the exception vector 32 to catch an exception in the exception processing unit 34 of the guest operating system 20. Processing is performed (S142, S144).

Meanwhile, as described above, if a system event occurs while the user program 22 is being executed in the guest operating system 20, the virtual machine monitor 10 and the virtual kernel process the system event and then the user again. It is desirable to switch to the virtual user mode 24 in which the program 22 has operated.

For ARM processors, the Program Status Register (PSR) values used in supervisor mode and user mode are different, so when switching to virtual user mode 24, the PSR information must be switched as well. .

In addition, since the interrupt is disabled at the time of switching to the virtual user mode 24, it is necessary to set the interrupt to enable and switch. However, if the interrupt is enabled and switched in advance, a problem occurs if an interrupt occurs while the context is not yet switched, so the mode must be switched atomically.

In the kernel of the existing operating system, the CPU mode switch command is used to atomically switch the context of the kernel and the user's context. However, in the guest operating system 20 of the virtual machine monitor 10 environment, when the context is switched from the virtual kernel mode 28 to the virtual user mode 24, the mode switching command valid only in the privileged mode is operated. You will not. In addition, the command to change the value of the PSR is also available only in the supervisor mode, which causes a problem of having to redo the hypercall.

Accordingly, an embodiment of the present invention proposes a method in which a PSR, a context switch, and an interrupt enable are atomic when performing a single hypercall when switching from the virtual kernel mode 28 to the virtual user mode 24. do. The detailed method will be described with reference to FIG. 7.

First, after exception processing is completed in the exception processing unit 34 of the guest operating system 20 (S150), a hypercall for virtual CPU mode switching is performed (S152). Then, the hypercall processing unit 18 of the virtual machine monitor 10 is called (S154).

The called hypercall processor 18 may restore the CPU context of the virtual user mode 24 using the stack pointer value of the virtual user mode stored in the shared memory 40 (S156). The hypercall processor 18 sets the virtual PSR value to be interrupt enabled (S158), and switches to the context of the virtual user mode 24 by using mode switching commands (movs) (S160).

8 is a flowchart specifically showing a processing method of a virtual PSR according to an embodiment of the present invention.

Since the guest operating system 20 needs to directly or indirectly access the PSR when handling various exceptions, the PSR should be virtualized so that the PSR can be accessed in the same manner as the existing method in the exception processing unit already implemented in the operating system. Here, the exception processor 34, which is already implemented in the guest operating system 20, determines the processor mode in which the exception has occurred through various bits of the PSR.

Referring to FIG. 8, the virtual machine monitor 10 first checks the value of all bits of the PSR stored in the stack of the virtual machine monitor 10 before transferring control of exception handling to the guest operating system 20. In operation S164, the exception processing unit 34 of the guest operating system 20 may identify the virtual CPU mode and the operation state that were previously executed by replacing the previous virtual CPU mode value. For example, before a system event occurs in the virtual user mode 24 and transfers control of exception handling to the guest operating system 20 after event processing in the virtual machine monitor 10, the value of the PSR is returned to the previous virtual CPU. The value is replaced with the virtual user mode 24 value.

When the exception processing unit 34 of the guest operating system 20 ends execution (S166), the actual state of the processor should be restored to the previous state (S168). At this time, the state of various operations previously performed, the actual operation mode of the processor, etc. must be completely restored. In the case of an ARM processor, the user operating system 20, including the guest operating system 20, is executed in a user mode, which is a non-privileged mode of the processor, at which time the mode bits of the PSR are replaced with actual user mode bits.

Meanwhile, in the embodiment of the present invention, the virtual machine monitor 10 is taken as an example of the virtualization unit that provides the virtualization layer. However, the present invention is not limited thereto, and any software may be used as long as it provides a hypervisor or a virtualization layer.

Although the CPU virtualization method according to the present invention has been described with reference to the drawings exemplified as above, the present invention is not limited to the embodiments and drawings disclosed in the present specification, and those skilled in the art within the technical scope of the present invention. Of course, various modifications can be made.

As described above, according to the CPU virtualization method of the present invention, an operating system operating in a processor having two CPU modes can be stably and efficiently paravirtualized in one CPU mode, and minimizes modification of the kernel of the existing operating system. While maintaining the stability of the, it is effective to shorten the development period.

Claims (5)

Providing a virtualization unit which simultaneously runs a plurality of guest operating systems and runs in a privileged mode of a processor; Partitioning and generating a non-privileged mode of the processor into at least two virtual sub modes hierarchically ordered; Transitioning to the virtualization unit when a privilege command occurs in the virtual lower mode; Transmitting, by the virtualization unit, the privilege command to a hierarchical mode that processes the privilege command among the virtual lower modes; Processing the privileged command in a hierarchical mode of processing the privileged command, and maintaining the mode as it is or transitioning to any other virtual sub-mode. The method of claim 1, Storing the switched virtual lower mode information each time the switch to the virtual lower mode; In the virtualization unit, determining a mode by reading the stored virtual lower mode information; And Storing a stack pointer value of the determined sub mode or a stack pointer value of the virtual sub mode before being switched to the virtual sub mode; And transitioning to the virtual lower mode includes reading the stored stack pointer value and restoring the context of the mode. The method of claim 2, Delivering the privilege command, And setting a context of a corresponding mode by reading a stack pointer value of a hierarchical mode that processes the privileged command. The method of claim 1, Transitioning to the virtual lower mode, Requesting a hypercall to the virtualization unit in a hierarchical mode of processing the privilege command; And restoring a context of a corresponding mode by using the stack pointer value of the other virtual lower mode in the virtualization unit that has received the hypercall. The method of claim 4, wherein Replacing a Program Status Register (PSR) value with a value of the virtual lower mode in which the privilege command is generated when the privilege command is transferred to the hierarchical mode in which the virtual command processes the privilege command; Processing the privileged command, replacing the program status register value with a value of an actual processor mode, and setting it to be interrupt enabled.

Images