Container starting method, host system and electronic equipment

Abstract

The embodiment of the invention provides a container starting method, a host system and electronic equipment. The container runs in a micro virtual machine on a host machine, and the method comprises the following steps: respectively registering a plurality of virtual functions bound to a virtual function input / output driver on the host machine to the corresponding micro virtual machine; based on the memory allocated for the micro virtual machine, idle page collection is carried out in the memory of the host machine, a first page in idle pages is determined, the first page is recorded, index marking is carried out on the idle pages, and host machine physical addresses of the idle pages are mapped to input and output virtual addresses, zero clearing of the first page is triggered by IO operation or registration operation for the first page; and starting the micro virtual machine, the container on the micro virtual machine and the application in the container. According to the method, container starting time consumption is reduced, and quick starting is achieved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of cloud networks, and more particularly, to a container starting method, a host system and an electronic device. BACKGROUND

[0002] In recent years, secure containers are increasingly valued in multi-tenant cloud environments, especially in highly security-conscious scenarios. Unlike traditional containers that run directly on a host machine, secure containers run container processes inside micro VMs with independent kernels to provide a higher level of isolation against attacks such as privilege escalation. Many use cases of secure containers require network communication, and due to the short-lived nature of containers and the possibility of experiencing high-capacity bursty calls, an ideal network solution for secure containers needs to support not only high data plane performance but also high deployment density and fast startup performance.

[0003] Hardware-assisted network device virtualization technologies, such as Single Root Input / Output Virtualization (SR-IOV), have been able to achieve high data plane performance while supporting high deployment density in recent years. SR-IOV supports micro VMs to directly interact with network cards, thereby achieving high data plane performance. Moreover, with the advent of technologies such as Mediated Device (mdev) and Scalable Input / Output Virtualization (Scalable IOV), the deployment density of SR-IOV has also been greatly improved.

[0004] Although the secure container network solution based on SR-IOV has advantages in data plane performance and deployment density, it is deficient in achieving fast startup performance. SUMMARY

[0005] The present application provides a container starting method, a host system and an electronic device, which solves the problem of the deficiency of the secure container network solution based on SR-IOV in achieving fast startup performance.

[0006] In a first aspect, the present application provides a container starting method, wherein the container runs in a micro VM on a host machine, and the method comprises:

[0007] registering a plurality of virtual functions on the host machine, which are bound to a virtual function input / output driver, to corresponding micro VMs respectively;

[0008] based on the memory allocated for the micro virtual machine, performing a free page collection in the memory of the host machine, determining a first page in the free page that needs to be delayed zeroed, and recording the first page, indexing the free page and mapping a host physical address of the free page to an input output virtual address, wherein the zeroing of the first page is triggered by an input output (IO) operation or a register operation for the first page;

[0009] starting the micro virtual machine, a container on the micro virtual machine, and an application in the container.

[0010] In a second aspect, the present application provides a host system, comprising: a host machine and a micro virtual machine running on the host machine.

[0011] The host system is configured to perform the method of the first aspect.

[0012] In a third aspect, the present application provides an electronic device, comprising: a memory and a processor.

[0013] The memory is configured to store a computer program.

[0014] The processor is configured to execute the computer program stored in the memory, and the computer program, when executed, causes the processor to perform the method of the first aspect.

[0015] In a fourth aspect, the present application provides a computer readable storage medium, which stores a computer program, and the computer program, when executed by a processor, causes the processor to perform the method of the first aspect.

[0016] In a fifth aspect, the present application provides a computer program product, comprising a computer program, and the computer program, when executed by a processor, implements the method of the first aspect.

[0017] The application provides a container starting method, a host system and an electronic device. The method registers a plurality of virtual functions on a host computer, which are bound to virtual function input / output drivers, to corresponding micro virtual machines respectively; based on memory allocated for the micro virtual machines, idle page collection is performed in the memory of the host computer, a first page in the idle pages is determined, the first page is recorded, the idle pages are indexed and marked, and the host computer physical addresses of the idle pages are mapped to input / output virtual addresses, wherein the zeroing of the first page is triggered by an IO operation or a registration operation for the first page; the micro virtual machine, the container on the micro virtual machine and the application in the container are started. In the container starting process, the zeroing operation of the first page is delayed for DMA memory mapping, and the zeroing of the first page is triggered by the IO operation or the registration operation for the first page, that is, in the starting process, the zeroing of the first page is not required before the indexing and marking of the idle pages and the mapping of the host computer physical addresses of the idle pages to the input / output virtual addresses in the DMA memory mapping, so that the starting time is reduced, and fast starting is achieved. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or the prior art description will be briefly introduced. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0019] Figure 1 is a schematic diagram of a container concurrent starting process based on a native SR-IOV CNI container network plug-in;

[0020] Figure 2 is a flowchart of a container starting method provided by an embodiment of the present application;

[0021] Figure 3 is a structural schematic diagram of a system architecture provided by an embodiment of the present application;

[0022] Figure 4 is a driving binding flowchart of a VF in the related art;

[0023] Figure 5 is a driving binding flowchart of a VF provided by an embodiment of the present application;

[0024] Figure 6 is a schematic diagram of a parent-child node lock provided by an embodiment of the present application;

[0025] Figure 7This is a schematic diagram of the process of triggering delayed clearing via EPT page fault provided in an embodiment of this application;

[0026] Figure 8 This is a schematic block diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] The technical terms used in the embodiments of this application are introduced below.

[0029] Container: refers to a virtualization technology used to isolate and run applications and their dependencies in an independent environment.

[0030] Secure container: refers to an enhanced container technology that offers greater security and isolation.

[0031] Container Runtime: refers to the software that implements container functionality, used to manage and execute container operations, including creating, starting, stopping, and destroying containers.

[0032] Container Network: refers to the network architecture and technology used to connect different containers, containers and host machines, and containers and container services.

[0033] Container Network Interface (CNI): Refers to a specification and interface used for communication and coordination between containers and network plugins to enable the configuration and management of container networks.

[0034] Container Engine: Refers to the agent software that receives standardized container lifecycle management commands and calls container runtime and CNI programs to execute the corresponding commands.

[0035] Microvirtual machines: a secure container implementation that achieves a lightweight and secure virtual environment by reducing the virtual machine manager, virtual machine OS, etc.

[0036] Virtual Function (VF): A type of device virtualization that simulates the Peripheral Component Interconnect Express (PCIe) device interface and has its own independent hardware resources, such as network interface card queues.

[0037] Input / Output Memory Management Unit (IOMMU): The device hardware passes through the data plane of virtualization technology, enabling fast IOVA->HPA address translation in hardware.

[0038] Virtual Function Input / Output (VFIO): The VF device hardware passes through the control plane of virtualization technology. It is implemented in kernel mode and serves as a bridge for communication of control information between the virtual machine manager and the IOMMU data plane.

[0039] Virtual machine manager: Software that assists in the operation of virtual machines, such as a hypervisor, which consists of the kernel virtual machine (KVM) in kernel space and the quick emulation machine (QEMU) in user space.

[0040] Kernel Virtual Machine: The kernel-mode virtual machine manager, responsible for central processing unit (CPU) scheduling and allocation, memory isolation, device interrupts, etc.

[0041] Fast emulator: A user-space virtual machine manager responsible for emulating I / O devices, such as network cards.

[0042] SR-IOV: A hardware passthrough network virtualization technology that uses the VFIO control plane and IOMMU data plane to pass VF directly into the virtual machine, bypassing KVM and QEMU's involvement in the data plane to improve performance.

[0043] Guest Virtual Address (GVA): The virtual address used by applications running within a virtual machine (i.e., the guest machine).

[0044] Guest Physical Address (GPA): The physical address as perceived by the virtual machine's operating system. To the operating system and applications within the virtual machine, these addresses appear to be actual physical memory addresses, but in reality, they are virtual addresses managed by the virtual machine manager.

[0045] Host Virtual Address (HVA): The virtual address provided by the host operating system for its own applications and processes.

[0046] Guest Physical Address (HPA): The actual physical memory address managed by the host operating system and hardware. These addresses directly correspond to locations on the physical memory chips and are the lowest-level memory addresses in the system.

[0047] Input / Output Virtual Address (IOVA): A mechanism for address mapping between devices and memory, especially in virtualized environments. It allows devices to use virtual addresses for data transfer without directly accessing physical addresses, thereby improving system flexibility and security.

[0048] Memory Management Unit (MMU): The internal memory mapping management module of the host operating system, responsible for HVA->HPA address translation.

[0049] Extended Page Table (EPT): This method translates GPA to HPA using hardware, which improves efficiency compared to software-based translation from GPA to HVA and then to HPA.

[0050] Virtual I / O File System (VirtioFS): A shared file system implemented through a semi-virtualization scheme based on memory channel technology. The host and guest machines can directly transfer files through VirtioFS without the involvement of a virtual machine manager.

[0051] Reference Figure 1 As shown, the concurrent startup process of a container based on the native SR-IOV CNI container network plugin includes VF driver binding, attaching the VF to the microvirtual machine, and subsequent startup of the microvirtual machine.

[0052] VF driver binding includes: moving VFs pre-bound to the host network driver to the container network namespace; and having the container runtime search for VFs on the host machine before each microvirtual machine startup and rebind the VFs to the VFIO driver.

[0053] Attaching Virtual Functions (VFs) to a microvirtual machine involves registering each VF with its corresponding microvirtual machine and performing Direct Memory Access (DMA) memory mapping on the memory regions of each microvirtual machine. Registering a VF with its corresponding microvirtual machine requires enabling the VF and configuring it accordingly. The DMA memory mapping process includes free page looting, page zeroing, page marking, and page mapping. Page marking can also be called index marking, and page mapping can also be called address mapping.

[0054] Starting a microvirtual machine includes: starting the microvirtual machine, initializing the microvirtual machine's VF driver, storage driver, and kernel module, and starting the container and the applications within the container.

[0055] By breaking down the time consumption of each part of the above process, we can find that the main time bottlenecks are as follows:

[0056] Bottleneck 1: For the startup process of each container, the VF that was previously bound to the host network driver needs to be rebound to the VFIO driver, which takes a lot of time.

[0057] Bottleneck 2: Registering a Virtual Function (VF) to the corresponding microvirtual machine requires opening the VF. However, opening the VF requires acquiring the VF's lock. Currently, the VFIO device set uses coarse-grained locks, meaning that multiple VFs derived from the same hardware device share the same global mutex lock of the same VFIO device set. Lock contention during concurrent startup takes a long time, significantly reducing the parallelism of concurrent startup.

[0058] Bottleneck 3: During the DMA memory mapping process, all memory regions are mapped, which takes a long time.

[0059] Bottleneck 4: During DMA memory mapping, the page zeroing operation takes a long time.

[0060] Bottleneck 5: The initialization of the VF driver is blocked by the initialization of other drivers and kernel modules, which takes a long time.

[0061] For the aforementioned time-consuming bottlenecks, improving any one or more of them can reduce startup time and achieve fast startup. The method described in this application proposes a method to improve upon these bottlenecks.

[0062] In particular, regarding how to solve the problem of the page clearing operation taking a long time, Figure 2 This is a flowchart illustrating a container startup method provided in an embodiment of this application. The method includes:

[0063] S201. Register the multiple VFs on the host machine that are already bound to the VFIO driver to their respective microvirtual machines.

[0064] Because SR-IOV technology divides network interface card (NIC) resources into multiple Virtual Functions (VFs), and assigns each VF to a micro-virtual machine (VM) via VFIO, allowing the VM to directly interact with the NIC, the VFs already bound to the VFIO driver need to be registered with the corresponding VM before starting the VM. Registering the VF establishes the mapping between the VF and the VM, enabling each VM to subsequently use its corresponding VF to interact with the NIC.

[0065] S202. Based on the memory allocated to the micro-virtual machine, free pages are collected in the host machine's memory, the first page among the free pages is determined and recorded, the free pages are indexed and marked, and the host machine physical address of the free page is mapped to the input / output virtual address. The clearing of the first page is triggered by the IO operation or registration operation targeting the first page.

[0066] DMA memory mapping maps the HPA (Hardware Address Parity) of memory allocated for a microvirtual machine to the IOVA (Internal Memory Parity Parity). Compared to the previously described DMA memory mapping process, which includes free page collection, page zeroing, index marking, and address mapping, in this step, the first page is a page with delayed zeroing. That is, during the DMA memory mapping process, the zeroing operation of the first page can be delayed. After collecting free pages, it is not necessary to wait for all free pages to be zeroed; instead, subsequent index marking and address mapping can proceed directly. The first page can be part or all of the free pages. In related technologies, page collection, page zeroing, index marking, and address mapping in DMA memory mapping are executed sequentially, and there are no I / O operations or registration operations on pages during the DMA memory mapping process. However, in this embodiment, the DMA memory mapping process is improved by not immediately zeroing all free pages after page collection. Instead, the zeroing of the first page is triggered by subsequent I / O operations or registration operations on the first page. These I / O operations or registration operations on the first page are operations performed after DMA memory mapping. For example, the I / O operations or registration operations on the first page can be operations performed after the application starts. By delaying the zeroing of the first page, the operations performed during DMA memory mapping during startup are reduced, thus reducing the time consumption of DMA memory mapping.

[0067] S203. Start the microvirtual machine, the container on the microvirtual machine, and the application within the container.

[0068] After performing DMA memory mapping, start the microvirtual machine and initialize its VF driver, storage driver, and kernel module. Then you can start the container and the applications within it.

[0069] In the method of this application embodiment, during the container startup process, the zeroing operation of the first page in the DMA memory mapping is delayed. The zeroing of the first page is triggered by subsequent operations on the first page. In other words, the micro virtual machine and container can be started without page zeroing during the startup process, thereby reducing startup time and achieving fast startup.

[0070] Based on the above embodiments, and further in conjunction with the container startup process, the improvements to the aforementioned bottlenecks in the embodiments of this application will be explained.

[0071] The method in the embodiments of this application can be based on, for example... Figure 3 The system architecture implementation is shown. For example, as shown... Figure 3 As shown, the host machine includes a kernel-level FastIOV virtualization page latency clearing module (fastiovd), VFIO, and KVM, as well as a user-level container runtime, QEMU, and FastIOV CNI. The guest machine, i.e., the micro-virtual machine, includes a kernel-level VF driver, container runtime agent, and virtioFS, as well as a user-level serverless application. Here, fastiovd is a page latency clearing module provided in this embodiment, and it is a pluggable Linux kernel module. FastIOV CNI is a container network plugin for SR-IOV hardware passthrough provided in this embodiment. Figure 3 The functions of each system module shown will be described in conjunction with subsequent embodiments.

[0072] Regarding the bottleneck mentioned above, the startup process of each container requires rebinding the VF (Virtual Container) pre-bound to the host network driver to the VFIO driver, which is time-consuming. (Refer to...) Figure 4 As shown, in related technologies, VF driver binding during container startup includes:

[0073] The S401 and SR-IOV CNI container network plugins move the VF, which is pre-bound to the host network driver, to the container network namespace.

[0074] S402. The container runtime searches for VFs bound to the host network driver on the host machine before each startup of the microvirtual machine.

[0075] S403. When the container runs, it will rebind the VF that was bound to the host network driver to the VFIO driver.

[0076] Only then can the container runtime provide VF information to the microvirtual machine for the subsequent steps of registering the VF to the microvirtual machine.

[0077] The binding process described above needs to be executed every time the container starts, which results in high startup time.

[0078] Therefore, in this embodiment, after the host machine starts, the VF is pre-bound to the VFIO driver. This binding process only needs to be performed once after the host machine starts, and subsequent bindings from VF to VFIO driver are not required during the startup of each container. Furthermore, by creating a simulated virtual network device corresponding to the VF, the container runtime can recognize the VF that has already been bound to the VFIO driver. (Refer to...) Figure 5 As shown, the driver binding of VF in this embodiment includes:

[0079] S501: After the host machine starts up, VF is bound to the VFIO driver in advance.

[0080] In this embodiment of the application, after the host machine starts up, the FastIOV CNI controller can pre-bind the VF bound to the host machine network driver to the VFIO driver.

[0081] S502. Create a simulated virtual network device in the container network namespace. The information of the simulated virtual network device is the information of the VF that is pre-bound to the VFIO driver after the host machine starts.

[0082] Before the microvirtual machine and container start, the FastIOV CNI container networking plugin creates simulated virtual network devices corresponding to each VF in the container network namespace based on the VF information pre-bound to the VFIO driver. For example, the VF information may include VF control plane information, such as the VF's IP address and MAC address. Simulated virtual network devices can also be called pseudo-virtual network devices.

[0083] S503, Search for simulated virtual network devices within the container network namespace via container runtime.

[0084] When a container runs, it searches for simulated virtual network devices within the container network namespace and can read the information of the simulated virtual network devices, which is the VF information.

[0085] S504. The container runtime determines the VF that has been bound to the VFIO driver based on information from the simulated virtual network device.

[0086] Afterwards, the container runtime can provide the VF information to the microvirtual machine for subsequent steps of registering the VF to the microvirtual machine.

[0087] In the process described above, VF driver binding only needs to be performed once after the host machine starts. This binding operation is performed before the container starts, and VF driver binding is not involved during container startup, thus significantly reducing startup time. Meanwhile, during container runtime, the container can correctly identify the VF bound to the VFIO driver by simulating the VF information carried by the virtual network device, thereby ensuring that subsequent startup steps can proceed normally.

[0088] For VFs already bound to the VFIO driver, the aforementioned bottleneck two problem exists in the process of registering them to their respective microvirtual machines. During the registration process, the hypervisor opens the VF through the VFIO driver and obtains file descriptors and other related device information. The current design of the VFIO driver uses a global mutex lock for each VF in the VFIO device set. This coarse-grained global mutex lock means that when containers start concurrently, opening operations on different VFs require competition for the same global mutex lock, resulting in a long time consumption for concurrent container startup.

[0089] To address this issue, this application proposes a lock-breaking technique, which abstracts the lock problem in a VFIO device set as follows: The VFIO device set is taken as the parent node, and the VFs belonging to the VFIO device set are taken as child nodes. The parent node possesses a global state, which is associated with the local states of its child nodes. Based on the data accessed by operations, four types of operation relationships can be defined:

[0090] Operations between child nodes: Accessing the local state of different child nodes.

[0091] Operations within a child node: Accessing the local state of the same child node.

[0092] Internal operations of the parent node: Access the global state of the parent node.

[0093] Parent-child node operations: Access the global state of the parent node and the local state of the child node respectively.

[0094] Operations between child nodes are independent and can be executed in parallel, while the other three types of operations are mutually exclusive and should be executed sequentially. (See reference...) Figure 6 As shown in this embodiment, a read-write lock is allocated to the parent node, and a mutex lock is allocated to each child node. Thus, accessing the global state requires obtaining write access to the read-write lock, while accessing the local state of a child node requires first obtaining read access to the read-write lock and then acquiring the child node's mutex lock. This satisfies the independence or mutual exclusion requirements of the four types of operation relationships mentioned above.

[0095] Independent operations between child nodes: Assuming two threads access the local state of two child nodes respectively, the two threads can each acquire read access to the read lock and then acquire the mutex lock of the corresponding child node. In this way, the two threads can independently and in parallel access the local state of the two child nodes.

[0096] Mutual exclusion of operations within a child node: Assuming two threads both access the local state of the same child node, each thread can acquire read access to the read-write lock, but they need to compete for the mutex lock of the same child node. Therefore, the operations of the two threads are mutually exclusive and need to be executed serially.

[0097] Mutual exclusion of operations within the parent node: Assuming two threads both access the global state of the parent node, the two threads need to compete for the write permission of the parent node's read-write lock. Therefore, the operations of the two threads are mutually exclusive and need to be executed serially.

[0098] Mutual exclusion of parent and child node operations: Suppose one thread accesses the global state of the parent node, while another thread simultaneously accesses the local state of the child node. Because the write and read permissions of the parent node's read-write lock are mutually exclusive, the operations of the two threads are mutually exclusive and must be executed serially.

[0099] Based on the aforementioned lock fragmentation technique, in this embodiment, the VIFO driver allocates a read-write lock to the VFIO device set and assigns a corresponding mutex lock to each VF within the VFIO device set. During concurrent container startup, the opening operations for different VFs belong to the aforementioned inter-node operations and can be executed in parallel. That is, during the process of registering multiple VFs to their respective micro-virtual machines, the read-write locks of the VFIO device set to which the multiple VFs belong, as well as the mutex locks of each VF, are acquired to register the multiple VFs to their respective micro-virtual machines in parallel. For each thread opening different VFs, read permissions can be acquired from the read-write locks of the VFIO device set, and then each thread acquires the mutex lock of the corresponding VF. In this way, each thread can independently and in parallel execute the VF opening operation, thus achieving the parallel registration of multiple VFs to their respective micro-virtual machines.

[0100] After registering each VF to its corresponding microvirtual machine, DMA memory mapping is required. This DMA memory mapping process involves the aforementioned bottlenecks three and four. Bottleneck three involves performing DMA memory mapping on all memory regions in related technologies, leading to high startup time. However, for read-only memory regions, such as mirrored memory regions, DMA memory mapping is unnecessary since these regions do not require I / O operations. Therefore, this application proposes that DMA memory mapping be avoided for unnecessary memory regions. Based on the description information of the memory allocated to the microvirtual machine by the virtual machine manager, regions requiring DMA memory mapping are identified. For these regions, free pages are collected in the host machine's memory.

[0101] For example, when QEMU allocates memory for a microvirtual machine, the memory region structure contains descriptive information describing the function of each memory region. Combining this descriptive information with the size of the memory allocated by QEMU, it can identify whether a memory region requires DMA memory mapping. For instance, if the memory region is determined to be a mirrored memory region based on the descriptive information and memory size, then it is determined that this memory region does not require DMA memory mapping. If the memory region is determined to be a main memory region based on the descriptive information and memory size, then it is determined that this memory region requires DMA memory mapping. Before QEMU enumerates different memory regions and issues DMA memory mapping operations to the VFIO kernel module, it intercepts the DMA memory mapping operations based on the identification results. That is, it intercepts the operations before the VFIO kernel module receives them, thus minimizing kernel modifications.

[0102] After identifying the memory region requiring DMA memory mapping, the fourth bottleneck issue in DMA memory mapping, as mentioned above... Figure 2 The embodiments shown are described in detail. Figure 2 Based on the illustrated embodiment, this paper further describes how to perform delayed clearing of the first page.

[0103] In a delayed zeroing scheme, it's crucial to ensure that applications within the microvirtual machine do not manipulate dirty pages when accessing memory regions. In one scenario, after the application starts within the container, an extended page table page fault is triggered in response to the application's I / O operation on the first target page within the first page. This causes the first target page to be zeroed and removed from the first page's records.

[0104] Reference Figure 7As shown, the application's operation on any first page's GPA is completed by checking the second-level page table (EPT table) to map GPA to HPA. The EPT table is constructed through an iterative process of "page fault-mapping write". For any unaccessed GPA, an EPT page fault will be triggered. KVM determines the mapping from GPA to HVA and queries the HVA to HPA mapping from the MMU page table. Thus, KVM determines the mapping from GPA to HPA and writes the GPA to HPA mapping into the EPT. Therefore, in this embodiment, the original page zeroing operation is disabled in the VFIO kernel module. When performing delayed zeroing of the first page, it can be intercepted before KVM writes the GPA to HPA mapping into the EPT, so that the first page is zeroed through fastiovd. After zeroing, the GPA to HPA mapping is written into the EPT, thereby ensuring that the application does not operate on dirty pages.

[0105] Optionally, in this embodiment, the information of the first page is inserted into a two-level hash table stored in fastiovd. The first-level key in the first-level hash table uses the process ID (PID) as the identifier for each microvirtual machine, and the value of the first-level key is a pointer to the second-level hash table maintained for that microvirtual machine. The second-level key in the second-level hash table is the HPA, and the value of the second-level key contains the information of the first page. When an application operates on the first target page in the first page, an EPT page fault is triggered. KVM checks whether the first target page that triggered the EPT page fault is in the two-level hash table. If it is determined that the first target page is in the two-level hash table, meaning the first target page is a page that is delayed in being zeroed, KVM notifies fastiovd to zero out the first target page and deletes the first target page from the second-level hash table.

[0106] In some scenarios, access to memory regions does not trigger EPT page faults. For example, during virtual machine manager memory writes, the virtual machine manager directly writes to the memory allocated for the microvirtual machine via HVA to perform necessary settings, including loading read-only regions such as the BIOS and kernel into memory. This process occurs before the microvirtual machine's operating system starts working and does not trigger any EPT page faults. EPT page faults are only triggered after the microvirtual machine starts and accesses these memory regions, such as when executing kernel code. If, during an EPT page fault, the page is zeroed according to the aforementioned delayed zeroing scheme, the data already written by the virtual machine manager will be zeroed, leading to system crashes.

[0107] To address the above problems, two methods can be used in the embodiments of this application.

[0108] In one approach, before indexing and marking the free pages, a second page is identified among the free pages. The second page is any page other than the first page among the free pages, and the second page is cleared.

[0109] This approach addresses the issue of memory writes by the virtual machine manager by establishing a whitelist of pages that are immediately zeroed. This whitelist includes second pages that are not subject to delayed zeroing—pages that are zeroed immediately after free page collection. For example, during memory allocation by the virtual machine manager, read-only memory regions such as BIOS and kernel memory are identified and added to the second page list. It's understandable that the second page is not included in the first page's list of pages subject to delayed zeroing. Application operations on the second page within the micro-virtual machine will not trigger delayed zeroing, thus ensuring that data already written by the virtual machine manager is not subsequently zeroed.

[0110] In another approach, in response to the virtual machine manager's I / O operation on the second target page in the first page, the second target page is zeroed out and deleted from the records of the first page.

[0111] In this method, the second target page is the page that the virtual machine manager operates on when writing to memory. The second target page is recorded in the first page's record with delayed zeroing. However, when the virtual machine manager operates on the second target page, it immediately triggers zeroing of the second target page and removes it from the first page's record. This way, when applications in the micro-virtual machine operate on the second target page again, delayed zeroing will not be triggered, thus ensuring that data already written by the virtual machine manager will not be zeroed out later.

[0112] In other scenarios, access to memory regions does not immediately trigger an EPT page fault. For example, in paravirtualization-based data transfers, where data is exchanged between a micro-virtual machine and the host machine using paravirtualization protocols (e.g., the virtioFS shared file system), containers within the micro-virtual machine can access specified files on the host machine through a shared buffer. In this process, an EPT page fault is triggered only after the micro-virtual machine's write operation to the shared buffer is completed. If the EPT page fault triggers delayed cleanup, it will incorrectly clean up files in the shared buffer.

[0113] To address the aforementioned issues, in this embodiment, after the application within the container starts, an EPT page fault is triggered when the shared buffer is registered in the microvirtual machine. This triggers the zeroing of the page corresponding to the shared buffer in the first page and removes the page corresponding to the shared buffer from the records of the first page. In this implementation, the page corresponding to the shared buffer is recorded in the first page with delayed zeroing, but an EPT page fault is proactively triggered for all pages involved in the shared buffer when the microvirtual machine registers the shared buffer to zero out the page corresponding to the shared buffer, thereby preventing subsequent erroneous zeroing of the page corresponding to the shared buffer.

[0114] Building upon the above embodiments, in this application embodiment, a cleanup thread can periodically scan the records of the first page, zero out the third target page within the first page, and delete the third target page from the records of the first page. Besides the delayed zeroing triggered by operations on the first page, a background cleanup thread can be maintained in fastiovd. This cleanup thread can periodically scan the aforementioned two-level hash table, i.e., the records of the first page, and trigger the zeroing of the third target page without waiting for operations on the third target page to trigger the zeroing. After zeroing the third target page, it is deleted from the two-level hash table. In this way, the delayed zeroing triggered by the cleanup thread and the delayed zeroing triggered by operations on the first page coexist, reducing the EPT page fault time and further improving the performance of container applications.

[0115] After performing DMA memory mapping, during the process of starting the microvirtual machine and the container on the microvirtual machine, the related technologies suffer from the problem of the VF driver, storage driver, and kernel module initialization blocking and time consumption, as mentioned in the fifth bottleneck above.

[0116] To address the aforementioned issues, this application proposes parallelizing the driver initialization operations. Specifically, it starts the microvirtual machine and concurrently initializes its VF driver, storage driver, and kernel module; it also starts the containers on the microvirtual machine and the applications within them.

[0117] By modifying the container runtime agent of the microvirtual machine, the initialization of the VF driver, storage driver, and kernel module are executed in parallel to reduce startup time. Furthermore, the container runtime agent repeatedly initializes the state before starting the application within the container, and only starts the container and its application after initialization is complete, thus ensuring security.

[0118] Figure 8 This is a schematic block diagram of the electronic device provided in an embodiment of this application. Figure 8 As shown, the electronic device 800 may include at least one processor 801 for implementing the container startup method provided in the embodiments of this application.

[0119] Optionally, the electronic device 800 further includes at least one memory 802 for storing program instructions and / or data. The memory 802 is coupled to the processor 801. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, and can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. The processor 801 may operate in conjunction with the memory 802. The processor 801 may execute program instructions stored in the memory 802. At least one of the at least one memory may be included in the processor.

[0120] Optionally, the electronic device 800 further includes a communication interface 803 for communicating with other devices via a transmission medium, thereby enabling the electronic device 800 to communicate with other devices. The communication interface 803 may be, for example, a transceiver, interface, bus, circuit, or a device capable of transmitting and receiving functions. The processor 801 can utilize the communication interface 803 to transmit and receive data and / or information, and to implement the methods provided in the embodiments of this application. For details, please refer to the detailed descriptions in the preceding embodiments; further elaboration is not repeated here.

[0121] This application embodiment does not limit the specific connection medium between the processor 801, memory 802, and communication interface 803. This application embodiment... Figure 8 The processor 801, memory 802, and communication interface 803 are connected via bus 804. Bus 804 is... Figure 8 The connections between other components are shown in thick lines only and are not intended to be limiting. This bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0122] It should be understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0123] It should also be understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Sync Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0124] This application also provides a host system, including: a host machine and a micro virtual machine running on the host machine; the host system is used to execute the methods in any of the foregoing embodiments.

[0125] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is run by a processor, it causes the computer to perform the methods as described in any of the foregoing embodiments.

[0126] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods in any of the foregoing embodiments.

[0127] The terms “unit”, “module”, etc., used in this specification may be used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution.

[0128] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. In the several embodiments provided in this application, it should be understood that the disclosed apparatus, devices, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0129] The unit described as a separate component may or may not be physically separate. The component shown as a unit may or may not be a physical unit; that is, it may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0130] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0131] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. This computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line, DSL) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Video Discs, DVDs), or semiconductor media (e.g., Solid State Disks, SSDs), etc.

[0132] If this function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0133] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0134] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method of starting a container, characterized by, The container runs in a micro virtual machine on a host computer, and the method comprises: Registering a plurality of virtual functions on the host computer, which are bound to a virtual function input / output driver, to corresponding micro virtual machines respectively; Based on the memory allocated to the micro virtual machine, performing idle page collection in the memory of the host computer, determining a first page in the idle page, and recording the first page, indexing the idle page, and mapping the host computer physical address of the idle page to an input / output virtual address, wherein the clearing of the first page is triggered by an input / output (IO) operation or a registration operation on the first page; Starting the micro virtual machine, the container on the micro virtual machine, and the application in the container.

2. The method of claim 1, wherein, Further comprising: After the application in the container is started, in response to an IO operation of the application on a first target page in the first page triggering an extended page table page fault interrupt, clearing the first target page, and deleting the first target page from the record of the first page.

3. The method of claim 1, wherein, Before indexing the idle page, further comprising: Determining a second page in the idle page, the second page being other than the first page in the idle page, and clearing the second page.

4. The method of claim 1, wherein, Before starting the micro virtual machine, the method further comprises: In response to an IO operation of a virtual machine manager on a second target page in the first page, clearing the second target page, and deleting the second target page from the record of the first page.

5. The method of claim 1, wherein, Further comprising: After the application in the container is started, triggering an extended page table page fault interrupt when the micro virtual machine registers a shared buffer, clearing a page corresponding to the shared buffer in the first page, and deleting the page corresponding to the shared buffer from the record of the first page.

6. The method of claim 1, wherein, After starting the micro virtual machine, the container on the micro virtual machine, and the application in the container, the method further comprises: Periodically scanning the record of the first page by a cleaning thread, clearing a third target page in the first page, and deleting the third target page from the record of the first page.

7. The method according to any one of claims 1 to 6, characterized in that, Based on the memory allocated to the micro virtual machine, the idle page collection in the memory of the host computer comprises: Based on the description information of the memory allocated to the micro virtual machine by the virtual machine manager, identifying the region that needs to be directly memory accessed memory mapped, and performing idle page collection in the memory of the host computer for the region that needs to be directly memory accessed memory mapped.

8. The method according to any one of claims 1-6, characterized in that, Before registering a plurality of virtual functions on the host computer to corresponding micro virtual machines respectively, the method further comprises: Creating a simulated virtual network device in a container network namespace, the information of the simulated virtual network device being the information of the virtual function bound to the virtual function input / output driver in advance after the host computer is started; After the container runtime searches the simulated virtual network device in the container network namespace, based on information of the simulated virtual network device, it determines that a virtual function has been bound to a virtual function input / output driver.

9. The method according to any one of claims 1-6, characterized in that, Registering the multiple virtual functions bound to the virtual function input / output driver on the host computer to corresponding micro virtual machines respectively, comprises: Obtaining read-write locks of multiple virtual function input / output device sets to which the multiple virtual functions belong, and mutual exclusion locks of the multiple virtual functions respectively, to register the multiple virtual functions to the corresponding micro virtual machines in a parallel manner.

10. The method according to any one of claims 1-6, characterized in that, The starting of the micro virtual machine and the container on the micro virtual machine comprises: Starting the micro virtual machine, and concurrently initializing a virtual function driver, a storage driver and a kernel module of the micro virtual machine; Starting the container on the micro virtual machine and an application in the container.

11. A host system, comprising: Comprise: A host computer and a micro virtual machine running on the host computer; The host system is configured to perform the method of any one of claims 1-10.

12. An electronic device, comprising: Comprise: A memory and a processor; The memory is configured to store a computer program; The processor is configured to execute the computer program stored in the memory, and the computer program runs to make the processor execute the method of any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and when the computer program is executed by the processor, the processor executes the method of any one of claims 1-10.

14. A computer program product, characterised in that, The computer program is executed by the processor to implement the method of any one of claims 1-10.

Images