Information scheduling method from secure container operating system to virtual machine monitor

A technology of virtual machine monitor and security container, applied in the direction of instrument, program control design, program control device, etc., can solve the problems of poor performance and high cost, and achieve the effect of improving execution efficiency

Pending Publication Date: 2020-07-28

孙宇霖

0 Cites 0 Cited by

AI-Extracted Technical Summary

Problems solved by technology

The performance of "KVM Hyper Call" is relatively poor. This is because a "KVM Hyper Call" requires two context switches: a. Secure container to host operating system switching; b. Host operating system to vir...

Method used

Memory-based message queue: VMM and the secure container operating system kernel use message queue communication based on shared memory, to avoid high-cost context switching;

Thread synchronization based on spin lock Spinlock: VMM thread and secure container kernel thread carry out thread synchronization (spin lock spinlock in linux) based on shared memory SpinLock, avoid high...

Abstract

The invention discloses an information scheduling method from a secure container operating system to a virtual machine monitor. The invention provides a scheduling method from a security container toa virtual machine monitor. The scheduling method comprises the steps: providing the virtual machine monitor and a security container kernel share a memory space; constructing a shared memory-based message queue between the two security container kernels and the virtual machine monitor, wherein a memory pointer of the Hyper Call of the security container kernel is placed in the message queue; enabling the virtual machine monitor to process the Hyper Call in the shared memory; and putting the processed Hyper Call thread ID into a message queue, and obtaining the processed Hyper Call thread ID bythe scheduler. Through the information exchange mode of the queue, when the virtual CPU (vCPU) of the security container needs to call the Hyper Call, the context switching between the kernel of thesecurity container and the monitor of the virtual machine is not needed, so that the execution efficiency of the super call can be greatly improved.

Application Domain

Interprogram communicationSoftware simulation/interpretation/emulation

Technology Topic

Virtual machineMessage queue +7

Image

Examples

Experimental program(1)

Example Embodiment

[0024] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. The embodiments of the present invention and all other embodiments obtained by those skilled in the art without creative work shall fall within the protection scope of the present invention.

[0025] The terms "including" and "having" and any variations of them in the present invention are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or modules is not necessarily limited to a clearly listed Those steps or modules may include other steps or modules that are not clearly listed or are inherent to these processes, methods, products, or equipment. The division of modules presented in this article is only a logical division , There can be other divisions in actual application.

[0026] The invention provides a Hyper Call communication mechanism from a secure container operating system based on a message queue to a VMM. Its basic principle is as follows:

[0027] Memory-based message queue: VMM and the secure container operating system kernel use shared memory-based message queue communication to avoid high-cost context switching;

[0028] Spinlock-based thread synchronization: The VMM thread and the secure container kernel thread perform thread synchronization based on the shared memory SpinLock (spinlock in linux), which also avoids high-cost context switching synchronization;

[0029] Information exchange based on the secure container operating system kernel thread stack: Hyper Call parameters and return values are allocated in the secure container kernel thread stack to avoid additional memory allocation. The message queue only transmits the pointer and thread ID of Hyper Call related information.

[0030] figure 1 As shown, it is necessary to construct two shared memory message queues between the secure container kernel and the virtual machine monitor.

[0031] Call queue: The direction is from the secure container kernel to the virtual machine monitor. When the secure container kernel needs to call the service of the virtual machine monitor, the secure container kernel needs to put the Hyper Call related information pointer into the call queue;

[0032] Return queue: The direction is from the virtual machine monitor to the secure container kernel. When the Hyper Call related processing is completed by the virtual machine monitor, the relevant security container kernel thread ID is put into the return queue;

[0033] figure 2 Shown, concrete,

[0034] When the secure container kernel needs to perform Hyper Call, its related process is as follows:

[0035] 1) The virtual CPU of the secure container kernel presses Hyper Call information onto the current secure container kernel thread stack, including: Hyper Call type ID, Hyper Call parameters, and secure container kernel thread ID;

[0036] 2) Put the memory pointer of the Hyper Call information on the thread stack into the Call Queue;

[0037] 3) The virtual CPU of the secure container kernel changes the current kernel thread state to the Waiting state, and the scheduler module obtains the next ready ready thread for scheduling execution;

[0038] 4) The VMM Hyper Call processing thread in the VMM host operating system thread reads the Hyper Call information from the Call Queue for processing.

[0039] 5) After the processing is completed, put the return value on the Guest kernel stack; then the Hyper Call information takes out the secure container kernel thread ID and puts it in the Return Queue;

[0040] 6) The scheduler module obtains the thread ID of the secure container kernel that completes the Hyper Call from the Return Queue, and changes the status of this thread to Ready, waiting for scheduling.

[0041] Here, the data structure and construction method of the call queue and the return queue are the same. The schematic code of the data structure they use is as follows:

[0042] Struct Queue {

[0043] Queue dataQueue;

[0044] SpinLock lock;

[0045] }

[0046] The definition of each of their fields is as follows:

[0047] 1. dataQueue: It is a standard first-in first-out queue, and its basic data structure can be an array or a linked list;

[0048] 2.lock: This is a spin lock based on the memory atomic operation standard. When you need to read and push data to the queue, you need to first acquire this lock to ensure data consistency. Since it is a spin lock, it can be directly synchronized between the current threads without relying on the synchronization system call of the operating system.

[0049] A spin lock based on memory atomic operations is used synchronously between the secure container kernel and the virtual machine monitor.

[0050] Through the information exchange method of this queue, when the virtual CPU (vCPU) of the secure container needs to call Hyper Call, it does not need to perform context switching between the secure container kernel and the virtual machine monitor, which can greatly improve the execution of the hyper call. effectiveness.

[0051] Through the actual test results based on the open source software Redis, in the case of high-frequency super calls, the throughput based on the present invention is 2 to 3 times larger than the throughput based on the KVM super call software gVisor.

[0052] It can reduce latency: This mechanism avoids the high-cost context switching based on "KVM Hyper Call" and can reduce the latency of Hyper Call.

[0053] High throughput: In the scenario of multiple secure container operating system kernel threads, the kernel thread can switch to other threads for execution while waiting for the return result of HyperCall. This switch does not involve the switch from the kernel to the VMM;

[0054] Zero heap memory allocation: Hyper Call parameters are placed on the secure container operating system kernel stack, and only pointers to the Hyper Call parameter stack are passed to the VMM. There is no need to allocate additional heap memory.

[0055] Zero memory copy: Hyper Call parameters only include memory pointers. Since VMM and the secure container operating system kernel share part of the memory address space, the secure container operating system application memory does not need to be copied to the kernel and VMM.

[0056] Specific examples are used in this article to describe the principles and implementation of the present invention. The description of the above examples is only used to help understand the method and core idea of the present invention; at the same time, for those skilled in the art, according to the present invention The idea of, there will be changes in the specific implementation and the scope of application. In summary, the content of this specification should not be construed as a limitation of the present invention.

PUM

Description & Claims & Application Information

We can also present the details of the Description, Claims and Application information to help users get a comprehensive understanding of the technical details of the patent, such as background art, summary of invention, brief description of drawings, description of embodiments, and other original content. On the other hand, users can also determine the specific scope of protection of the technology through the list of claims; as well as understand the changes in the life cycle of the technology with the presentation of the patent timeline. Login to view more.

Classification and recommendation of technical efficacy words

Improve execution efficiency

Embedded type distributed simulation platform based on HLA facing to space flight measurement and control and its realization method

InactiveCN101055530AReduce system overheadImprove execution efficiency

Owner:中国人民解放军63791部队

Information scheduling method from secure container operating system to virtual machine monitor

A technology of virtual machine monitor and security container, applied in the direction of instrument, program control design, program control device, etc., can solve the problems of poor performance and high cost, and achieve the effect of improving execution efficiency

AI-Extracted Technical Summary

Problems solved by technology

Method used

Abstract

Image

Examples

Example Embodiment

PUM

Description & Claims & Application Information

Similar technology patents

Design method of NES (Nintendo Entertainment System) emulator used on TV set top box

Method for allocating tasks to operator and device thereof

Method for calling plug-in board by browser, plug-in board manager and browser

Methods and systems for external connection of tables of database

User identity authentication method and device

Classification and recommendation of technical efficacy words

Embedded type distributed simulation platform based on HLA facing to space flight measurement and control and its realization method

Computing group structure for superlong instruction word and instruction flow multidata stream fusion

Sql (Structured query language) injection detection method and device

Instruction classified multi-emitting method based on SPRAC V8 instruction set

Protection method for side channel attack and fault attack