Virtual machine execution methods, devices, and equipment

Abstract

This disclosure discloses methods, devices, and equipment for running a virtual machine. [Solution] The virtual machine method, upon receiving a virtual machine restart command in response to at least one virtual machine being in a terminated state, includes the steps of: determining a first image execution memory and a first image backup memory pre-allocated to each virtual machine via the virtual machine controller; copying the virtual machine image stored in the first image backup memory to the first image execution memory via the virtual machine controller; and executing a virtual machine restore command via the virtual machine controller to trigger a jump to the kernel entry address of the first image execution memory and restart the execution of the virtual machine.

Description

Technical Field

[0001] The present disclosure relates to the field of embedded virtualization technology, and in particular to a method, apparatus and device for executing a virtual machine.

Background Art

[0002] In an embedded virtualization scenario, in order to support normal startup and restart of a virtual machine, it is necessary to load a virtual machine image from a storage medium to the memory of the virtual machine before the virtual machine executes.

[0003] In the related art, it is necessary to deploy a privileged virtual machine and a non-privileged virtual machine in a system. When the system starts up, a bootloader loads a virtual machine image from a storage medium to the memory of the virtual machine. When a non-privileged virtual machine restarts, the privileged virtual machine needs to load the virtual machine image of the non-privileged virtual machine from the storage medium to the memory of the virtual machine. In this way, although the restart of the non-privileged virtual machine depends on the privileged virtual machine, it cannot support the restart of the privileged virtual machine. Therefore, the privileged virtual machine will affect the normal execution of the non-privileged virtual machine, and independent restart of virtual machines cannot be realized.

[0004] For this reason, there is an urgent need for a virtual machine loading method that implements independent restart between virtual machines.

Summary of the Invention

Problem to be Solved by the Invention

[0005] In order to solve the above technical problem, the present disclosure provides a method, apparatus and device for executing a virtual machine, which implements independent restart between virtual machines without depending on a privileged virtual machine.

Means for Solving the Problem

[0006] A method for executing a virtual machine according to a first aspect of the present disclosure includes: When a virtual machine restart command is received in response to at least one virtual machine being in a terminated state, the virtual machine controller determines the first image execution memory and first image backup memory that have been pre-allocated to each virtual machine. The steps include copying the virtual machine image stored in the first image backup memory via the virtual machine controller to the first image execution memory, The process includes the steps of executing a virtual machine restore command via the virtual machine controller, triggering a jump to the kernel entry address of the first image execution memory, and restarting the execution of the virtual machine.

[0007] The virtual machine execution device relating to the second aspect of this disclosure is When a virtual machine restart command is received in response to at least one virtual machine being in a terminated state, a first determination module for determining the first image execution memory and first image backup memory pre-allocated to each virtual machine via the virtual machine controller, A first copy module for copying a virtual machine image stored in the first image backup memory via the virtual machine controller to the first image execution memory, The system includes a first boot module for executing a virtual machine restore command via the virtual machine controller and for triggering a jump to the kernel entry address of the first image execution memory to resume execution of the virtual machine.

[0008] An electronic device according to a third aspect of this disclosure includes a processor and a storage device for storing instructions that the processor can execute, wherein the processor reads the executable instructions from the storage device and executes them to realize the virtual machine execution method described in the first aspect.

[0009] A fourth aspect of this disclosure provides a computer program product, and when instructions within the computer program product are executed by a processor, the virtual machine execution method described in the embodiment of the first aspect of this disclosure is executed. [Effects of the Invention]

[0010] In the proposed technology described herein, after a virtual machine has stopped running, based on a received virtual machine restart command, the virtual machine controller hypervisor first determines the image backup memory and virtual machine execution memory pre-allocated to the virtual machine, copies the virtual machine image stored in the image backup memory to the virtual machine execution memory, and then executes a virtual machine restore command via the hypervisor to restart the virtual machine. In other words, with this solution, in embedded virtualization scenarios, the privileged virtual machine does not need to load the virtual machine image from the storage medium into the virtual machine execution memory each time the virtual machine is restarted. Since the virtual machine controller loads the virtual machine image from the image backup memory into the virtual machine execution memory, the restart of the virtual machine does not need to depend on the privileged virtual machine, meaning that there is no need to deploy a privileged virtual machine to the system, and independent restart of the virtual machine is achieved. Compared to conventional methods which require the deployment of a privileged virtual machine, this solution eliminates the need to deploy a privileged virtual machine, thus reducing the number of system components and the resource overhead of embedded devices. [Brief explanation of the drawing]

[0011] [Figure 1] This is a schematic flowchart of a virtual machine execution system according to one exemplary embodiment of the present disclosure. [Figure 2] This is a schematic flowchart of a virtual machine execution method according to one exemplary embodiment of the present disclosure. [Figure 3] This is a schematic flowchart illustrating a method for executing a virtual machine according to another exemplary embodiment of the present disclosure. [Figure 4A] A schematic diagram of an image copying process according to one exemplary embodiment of the present disclosure. [Figure 4B] This is a schematic diagram of an image copying process relating to another exemplary embodiment of the present disclosure. [Figure 5] This is a schematic flowchart illustrating a method for executing a virtual machine according to yet another exemplary embodiment of the present disclosure. [Figure 6] This is a schematic flowchart illustrating a method for executing a virtual machine according to yet another exemplary embodiment of the present disclosure. [Figure 7] A schematic diagram of an image loading process according to one exemplary embodiment of the present disclosure. [Figure 8] This is a schematic flowchart illustrating a method for executing a virtual machine according to yet another exemplary embodiment of the present disclosure. [Figure 9] This is a schematic diagram of an image loading process relating to another exemplary embodiment of the present disclosure. [Figure 10] This is a schematic diagram of the structure of a virtual machine execution device according to one exemplary embodiment of the present disclosure. [Figure 11] This is a structural diagram of an electronic device relating to one exemplary embodiment of the present disclosure. [Modes for carrying out the invention]

[0012] To illustrate this disclosure, exemplary embodiments of this disclosure will be described in detail below with reference to the drawings. Clearly, the embodiments described are only a selection of, and not all, embodiments of this disclosure. This disclosure should not be limited by the exemplary embodiments.

[0013] It should be noted that the relative arrangements of parts and steps, formulas, and numerical values ​​described in these embodiments do not limit the scope of this disclosure unless otherwise specified.

[0014] Application Summary As described above, in the related art, it is necessary to simultaneously deploy a privileged virtual machine and a non-privileged virtual machine in the system. When the system is started, a bootloader loads each virtual machine image from a storage medium into the memory of the corresponding virtual machine. When a non-privileged virtual machine is restarted, the privileged virtual machine needs to load the virtual machine image of the non-privileged virtual machine from the storage medium into the memory of the virtual machine. In this way, the restart of the non-privileged virtual machine depends on the privileged virtual machine, but the above method cannot support the restart of the privileged virtual machine. Therefore, the privileged virtual machine will affect the normal execution of the non-privileged virtual machine, and independent restart of virtual machines cannot be achieved.

[0015] Based on the above technical problem, in the technical solution according to the present disclosure, after a virtual machine stops running, based on a received virtual machine restart instruction, an image backup memory and a virtual machine execution memory pre-allocated to the virtual machine via a virtual machine controller (hypervisor) are first determined, the virtual machine image stored in the image backup memory is copied to the virtual machine execution memory, and then a virtual machine restoration instruction is executed via the hypervisor to resume the execution of the virtual machine. That is, with the present solution, in an embedded virtualization scenario, it is not necessary for the privileged virtual machine to load the virtual machine image from the storage medium to the virtual machine execution memory every time the virtual machine is restarted. Since the virtual machine controller loads the virtual machine image from the image backup memory to the virtual machine execution memory, the restart of the virtual machine does not need to depend on the privileged virtual machine. That is, it is not necessary to deploy a privileged virtual machine in the system, and independent restart of the virtual machine is realized. In contrast to the related art which requires deploying a privileged virtual machine, the present solution eliminates the need for deploying a privileged virtual machine, thereby reducing the number of system components and reducing the resource overhead of embedded devices.

[0016] Furthermore, in the present solution, since the image is loaded via the "image backup memory" at the memory level, it is faster than loading from a storage medium, which improves the restart efficiency of the virtual machine.

[0017] Exemplary System Figure 1 is a schematic flow diagram of a virtual machine execution system according to an exemplary embodiment of the present disclosure. The system comprises a virtual machine VM_A, a virtual machine VM_B, a virtual machine controller (hypervisor), a bootloader, and a hardware memory. Here, both the virtual machine VM_A and the virtual machine VM_B are Linux (registered trademark) systems.

[0018] For example, as shown in Figure 1, VM_A in the memory is a first image execution memory allocated to the virtual machine VM_A, IMG_VMA in the memory is a first image backup memory allocated to the virtual machine VM_A, VM_B in the memory is a first image execution memory allocated to the virtual machine VM_B, IMG_VMB in the memory is a first image backup memory allocated to the virtual machine VM_B, and Hypervisor_VM in the memory is a second image execution memory allocated to the virtual machine controller.

[0019] For example, as shown in Figure 1, the bootloader can provide an image loading module and is responsible for loading each virtual machine image and hypervisor image from a storage medium. The hypervisor is responsible for creating and managing one or more virtual machines, can provide an image copying module, is responsible for copying each virtual machine image, and supports normal startup, execution and restart of virtual machines. Herein, a complete virtual machine image comprises a kernel image, a device tree file and an initial memory file system.

[0020] In some examples, the image load module in the bootloader can be used to load the virtual machine image of virtual machine VM_A from storage into IMG_VMA, and the virtual machine image of virtual machine VM_B from storage into IMG_VMB. The image copy module in the hypervisor can further be used to copy the virtual machine image of virtual machine VM_A from IMG_VMA to VM_A, and the virtual machine image of virtual machine VM_B from IMG_VMB to VM_B.

[0021] In this way, a virtual machine VM_A can be generated via the hypervisor based on the virtual machine image of VM_A, and VM_A can be successfully started and executed in VM_A (i.e., the first image execution memory). After the execution of virtual machine VM_A is stopped, the virtual machine image of virtual machine VM_A (e.g., kernel image, device tree file, and initial memory file system) is copied back to VM_A via the hypervisor, and virtual machine VM_A is restarted. After the execution of virtual machine VM_B is stopped, execution can be resumed in the same manner as virtual machine VM_A described above.

[0022] In several other examples, the image load module in the bootloader can be used to load the virtual machine image of virtual machine VM_A from storage into VM_A, and the virtual machine image of virtual machine VM_B from storage into VM_B. Because the initial memory filesystem within the virtual machine image is configured not to be released after decompression at runtime, the image copy module in the hypervisor can be used to copy a partial virtual machine image from VM_A to IMG_VMA, and a partial virtual machine image from VM_B to IMG_VMB.

[0023] In this way, a virtual machine VM_A can be generated based on the virtual machine image of VM_A via the hypervisor, and VM_A can be successfully started and executed in VM_A (i.e., the first image execution memory). After the execution of virtual machine VM_A is stopped, a partial virtual machine image of virtual machine VM_A (e.g., kernel image and device tree file) is copied back to VM_A from IMG_VMA via the hypervisor, and virtual machine VM_A is restarted. After the execution of virtual machine VM_B is stopped, execution can be resumed in the same manner as virtual machine VM_A described above.

[0024] The virtual machine execution system described in this disclosure deploys only a virtual machine controller (hypervisor) and a normal virtual machine, provides an image backup memory for backing up virtual machine images, and does not deploy a privileged virtual machine. With this solution, in embedded virtualization scenarios, the privileged virtual machine does not need to load the virtual machine image from the storage medium into the virtual machine execution memory each time the virtual machine is restarted. Instead, the virtual machine controller loads the virtual machine image from the image backup memory into the virtual machine execution memory. Therefore, virtual machine restarts do not need to depend on the privileged virtual machine, achieving independent virtual machine restarts. While conventional methods require the deployment of a privileged virtual machine, this solution eliminates the need for the deployment of a privileged virtual machine, thereby reducing the number of system components and lowering the resource overhead of embedded devices.

[0025] Exemplary Method Figure 2 is a schematic flowchart of a virtual machine execution method according to an exemplary embodiment of the present disclosure. This embodiment can be applied to electronic devices and includes the following steps 201 to 203, as shown in Figure 2.

[0026] In step 201, if a virtual machine restart command is received in response to at least one virtual machine being in a terminated state, the first image execution memory and first image backup memory pre-allocated to each virtual machine are determined via the virtual machine controller.

[0027] In some cases, a virtual machine switching from a running state to a terminated state typically includes the following situations: (1) The virtual machine is triggered when a user executes a shutdown command and performs a normal shutdown flow to enter the terminated state. (2) The virtual machine is forcibly terminated due to a crash caused by an error in the virtual machine system. (3) The virtual machine controller detects abnormal execution of the virtual machine and forcibly terminates the virtual machine's execution. (4) The virtual machine is instantaneously terminated due to a hardware failure (e.g., processor overheating). The above four situations are merely illustrative examples, and the embodiments of this disclosure are not limited thereto.

[0028] In some embodiments, the virtual machine restart command is a command or signal to trigger the recovery of a virtual machine from a terminated state to a running state (i.e., a restart of the virtual machine). The virtual machine restart command may be a restart command sent directly by a user or system administrator via a management interface or command-line tool (e.g., typing "reboot" on the command line), or a pre-configured scheduled restart command. If the virtual machine restart command includes a target virtual machine identifier, the command is intended to restart only the target virtual machine indicated by the target virtual machine identifier, which may be a specific virtual machine of at least one virtual machine or all virtual machines. If the virtual machine restart command does not include any virtual machine identifier, the command can be used to restart all virtual machines in a terminated state managed by the current virtual machine controller.

[0029] In some embodiments, the virtual machine controller (hypervisor) has administrator privileges as an administrator and can be used for resource allocation and scheduling of each virtual machine. Multiple memory regions are divided from physical storage, such as Double Data Rate Synchronous Dynamic Random-Access Memory (DDR), via the virtual machine controller and allocated to each virtual machine as the first image execution memory for the virtual machine corresponding to that virtual machine. The first image execution memory is used to execute the virtual machine image. The hypervisor can further pre-allocate a first image backup memory corresponding to each virtual machine, and this first image backup memory is used to store the virtual machine image loaded from the storage medium. In this way, each virtual machine is associated with a unique first image backup memory and first image execution memory, and based on the above correspondence, the first image backup memory and first image execution memory corresponding to each virtual machine can be determined according to the virtual machine identifier of at least one virtual machine that is in a terminated state. The size and location of the first image execution memory and first image backup memory are determined when the virtual machine is created, and these two memory regions are directly reused when the virtual machine is restarted.

[0030] In step 202, the virtual machine image stored in the first image backup memory is copied to the first image execution memory via the virtual machine controller.

[0031] In some embodiments, when the system starts up, the virtual machine image for each virtual machine is loaded from the storage medium into the corresponding first image backup memory, so the corresponding virtual machine image is pre-stored in each first image backup memory. Therefore, when restarting a virtual machine, if the first image backup memory and first image execution memory corresponding to each virtual machine are determined, the virtual machine image stored in the first image backup memory of each virtual machine can be copied to the corresponding first image execution memory via the virtual machine controller (hypervisor) based on the identifier of each virtual machine.

[0032] For illustrative purposes, let's assume we have virtual machines A, B, and C. Based on the identifier of each virtual machine, the first image execution memory A' and first image backup memory A'' allocated to virtual machine A are determined via the hypervisor, the first image execution memory B' and first image backup memory B'' allocated to virtual machine B, and the first image execution memory C' and first image backup memory C'' allocated to virtual machine C are determined. In this way, based on the identifier of virtual machine A, the virtual machine image of virtual machine A stored in the first image backup memory A'' is copied to the first image execution memory A' via the hypervisor, based on the identifier of virtual machine B, the virtual machine image of virtual machine B stored in the first image backup memory B'' is copied to the first image execution memory B' via the hypervisor, and based on the identifier of virtual machine C, the virtual machine image of virtual machine C stored in the first image backup memory C'' is copied to the first image execution memory C' via the hypervisor.

[0033] In some examples, a complete virtual machine image typically includes a kernel image, an initial memory file system, and a device tree blob (DTB). For example, the initial memory file system may be an initial RAM disk (Initrd) or an initial RAM filesystem (initramfs). In one possible scenario, the virtual machine image stored in the first image backup memory is a complete image file, for example, containing the kernel image, Initrd, and DTB simultaneously. In another possible scenario, the virtual machine image stored in the first image backup memory is a partial image file, for example, containing only the kernel image and DTB. Embodiments of this disclosure describe, but are not limited to, the case where the initial memory file system is Initrd.

[0034] In step 203, a virtual machine restore command is executed via the virtual machine controller, triggering a jump to the kernel entry address of the first image execution memory to restart the virtual machine execution.

[0035] In some examples, the kernel entry address of the first image execution memory is the starting address of the kernel image within the virtual machine image. A virtual machine restore instruction (e.g., vm_resume) is executed via the hypervisor, initializing the CPU context based on the kernel entry address of the kernel image. This causes the CPU to switch to virtual machine mode, jump to the kernel entry address of the kernel image, and begin reading and executing instructions. The virtual machine kernel parses the DTB and mounts the true root file system based on Initrd, thereby resuming the execution of the virtual machine. A detailed explanation of the virtual machine restart can be found in the descriptions of related technologies and is not detailed in the embodiments of this disclosure.

[0036] If there are no updates to the virtual machine image, when restarting the virtual machines, steps 201 to 203 above are executed directly to resume execution of each virtual machine. If there are updates to the virtual machine image, when restarting the virtual machines, steps 205 to 207 described below are executed to regenerate the virtual machines and then run each virtual machine. Furthermore, the method disclosed herein requires the use of a Linux® system or a Linux®-based system for the virtual machine system.

[0037] In the proposed technology described herein, after a virtual machine has stopped running, based on a received virtual machine restart command, the virtual machine controller (hypervisor) first determines the image backup memory and virtual machine execution memory pre-allocated to the virtual machine, copies the virtual machine image stored in the image backup memory to the virtual machine execution memory, and then executes a virtual machine restore command via the hypervisor to restart the virtual machine. In other words, with this solution, in embedded virtualization scenarios, the privileged virtual machine does not need to load the virtual machine image from the storage medium into the virtual machine execution memory each time the virtual machine is restarted. Since the virtual machine controller loads the virtual machine image from the image backup memory into the virtual machine execution memory, the restart of the virtual machine does not need to depend on the privileged virtual machine, meaning that there is no need to deploy a privileged virtual machine to the system, and independent restart of the virtual machine is achieved. Compared to conventional methods which require the deployment of a privileged virtual machine, this solution eliminates the need to deploy a privileged virtual machine, thus reducing the number of system components and the resource overhead of embedded devices.

[0038] Furthermore, this solution loads images via memory-level "image backup memory," which is faster than loading from storage media and improves the efficiency of virtual machine restarts.

[0039] In some embodiments, when a virtual machine is created, the virtual machine image copied from the first image backup memory to the first image execution memory differs depending on whether the initial memory file system within the virtual machine image stored in the first image execution memory is decompressed and retained without being released. Based on this, as shown in Figure 3, step 202 above may include the following steps 2021 to 2022 based on the embodiment of Figure 2 described above.

[0040] In step 2021, in response to the fact that the virtual machine image stored in the first image backup memory contains only the kernel image and device tree files, and that the initial memory file system within the virtual machine image is stored in the first image execution memory, the virtual machine controller copies the kernel image to the first sub-execution memory within the first image execution memory and copies the device tree files to the second sub-execution memory within the first image execution memory.

[0041] In some embodiments, when a virtual machine is created, if the initial memory file system within the virtual machine image stored in the first image execution memory is retained after decompression without being released, the initial memory file system continues to be stored in the first image execution memory. When the virtual machine is restarted, it is not necessary to recopy the initial memory file system to the first image execution memory. Thus, if the first image backup memory contains only the kernel image and device tree files, it is sufficient to copy the kernel image from the first image backup memory to the first sub-execution memory within the first image execution memory via the virtual machine controller (hypervisor), and copy the device tree files from the first image backup memory to the second sub-execution memory within the first image execution memory.

[0042] In some examples, the first image backup memory may include a first sub-backup memory and a second sub-backup memory, where the first sub-backup memory is used to store the kernel image and the second sub-backup memory is used to store the device tree file. In other words, in the above situation, there is no need to reserve image backup memory for Initrd, and it is sufficient to provide each virtual machine with image backup memory for the Kernel Image and DTB backups.

[0043] For example, as shown in Figure 4A, the first image backup memory includes a first sub-backup memory 01 and a second sub-backup memory 02, with the Kernel Image stored in the first sub-backup memory 01 and the DTB stored in the second sub-backup memory 02. The first image execution memory includes a first sub-execution memory 03, a second sub-execution memory 04, and a third sub-execution memory 05. Since the initial memory file system Initrd is stored in the third sub-execution memory 05, when the virtual machine is restarted, the Kernel Image stored in the first sub-backup memory 01 can be copied to the first sub-execution memory 03 via the hypervisor, and the DTB stored in the second sub-backup memory 02 can be copied to the second sub-execution memory 04.

[0044] In step 2022, in response to the fact that the virtual machine image stored in the first image backup memory includes a kernel image, a device tree file, and an initial memory file system, and that the initial memory file system within the virtual machine image is not stored in the first image execution memory, the virtual machine controller copies the kernel image to the first sub-execution memory within the first image execution memory, copies the device tree file to the second sub-execution memory within the first image execution memory, and copies the initial memory file system to the third sub-execution memory within the first image execution memory.

[0045] In some embodiments, when a virtual machine is created, if the initial memory filesystem within the virtual machine image stored in the first image execution memory is decompressed and then released, the initial memory filesystem will no longer be stored in the first image execution memory. When the virtual machine is restarted, the initial memory filesystem must be copied back into the first image execution memory. Therefore, if the initial memory filesystem is included in the first image backup memory, it is necessary not only to copy the kernel image to the first sub-execution memory within the first image execution memory and the device tree file to the second sub-execution memory within the first image execution memory via the virtual machine controller (hypervisor), but also to copy the initial memory filesystem stored in the first image backup memory to the third sub-execution memory within the first image execution memory via the virtual machine controller (hypervisor). In other words, in the above situation, it is necessary to provide each virtual machine with image backup memory for the Kernel Image and DTB backups, as well as to reserve image backup memory for Initrd.

[0046] In some examples, the first image backup memory may include a first sub-backup memory, a second sub-backup memory, and a third sub-backup memory, where the first sub-backup memory stores the kernel image, the second sub-backup memory stores the device tree file, and the third sub-backup memory stores the initial memory file system. In other words, in the above situation, each virtual machine needs to be simultaneously provided with image backup memory for the Kernel Image, DTB, and Initrd, respectively.

[0047] For example, as shown in Figure 4B, the first image backup memory includes a first sub-backup memory 06, a second sub-backup memory 07, and a third sub-backup memory 08. The first sub-backup memory 06 stores the Kernel Image, the second sub-backup memory 07 stores the DTB, and the third sub-backup memory 08 stores Initrd. The first image execution memory includes a first sub-execution memory 09, a second sub-execution memory 10, and a third sub-execution memory 11. Since the third sub-execution memory 11 does not store the initial memory file system Initrd, when the virtual machine is restarted, the Kernel Image stored in the first sub-backup memory 06 can be copied to the first sub-execution memory 09 via the hypervisor, the DTB stored in the second sub-backup memory 07 can be copied to the second sub-execution memory 10, and the Initrd stored in the third sub-backup memory 08 can be copied to the third sub-execution memory 11.

[0048] Based on the above embodiment, in response to the virtual machine image stored in the first image backup memory containing only the kernel image and device tree files, and the initial memory file system within the virtual machine image being stored in the first image execution memory, the kernel image can be copied to the first sub-execution memory within the first image execution memory via the virtual machine controller, and the device tree files can be copied to the second sub-execution memory within the first image execution memory. Alternatively, in response to the first image backup memory further containing the initial memory file system, and the initial memory file system within the virtual machine image being stored in the first image execution memory, the initial memory file system can be further copied to the third sub-execution memory within the first image execution memory via the virtual machine controller. Thus, on the one hand, on-demand allocation and isolated storage of each part of the image can be achieved, avoiding redundant memory occupation due to a full copy. On the other hand, the image copy can be flexibly adapted based on the configuration of the virtual machine image and the state of the execution memory, reducing the amount of copied data and significantly shortening the virtual machine restart time.

[0049] In some embodiments, during the system startup phase, the images of each virtual machine and the controller image of the virtual machine controller can be loaded from the storage medium via the boot loader, and each virtual machine can be created and managed via the virtual machine controller. Based on this, as shown in Figure 5, the method for running a virtual machine according to the embodiments of this disclosure, based on the embodiment of Figure 2 described above, may further include the following steps 204 to 207 before step 201.

[0050] In step 204, the first configuration parameter of the device tree file contained in the virtual machine image stored on the storage medium is determined via the running boot loader.

[0051] Here, the first configuration parameter is used to set the free state of the initial memory file system included in the virtual machine image after it has been unzipped at runtime.

[0052] In some cases, the bootloader described above is the first software executed when the system starts up and is used to access the storage medium and load the virtual machine image of each virtual machine from the storage medium into the corresponding memory. The bootloader described above is mainly applied to embedded scenarios, and for example, the bootloader may be U-Boot (Universal Bootloader) or a lightweight embedded bootloader.

[0053] For example, the storage medium is a physical device that stores virtual machine images and controller images for virtual machine controllers. For instance, the storage medium could be an embedded multimedia card (eMMC) or a secure digital card. (Secure Digital Card, SD, etc.) may also be used. The embodiments of this disclosure are not limited to this.

[0054] In some embodiments, when the virtual machine system is a Linux® system, the virtual machine Linux® system retains the memory occupied by the Initrd image after decompression, without releasing it. In this way, before system startup, the DTB in the virtual machine image stored on the storage medium can be modified in advance, and the retain_initrd startup parameter can be added to the DTB to become the first configuration parameter. During the system startup phase, the storage medium driver is called via the bootloader to access the storage medium and identify the storage location of the virtual machine image, the device tree file (DTB) is identified from that storage location, and the identified DTB file is analyzed to extract the first configuration parameter.

[0055] For example, if the first configuration parameter is set to the first preset value, it indicates that the initial memory file system is configured to allow decompression and release at runtime. If the first configuration parameter is set to the second preset value, it indicates that the initial memory file system is configured to prohibit decompression and release at runtime.

[0056] In step 205, the boot loader loads the virtual machine image from the storage medium into the first image execution memory based on the first configuration parameter.

[0057] In some embodiments, different first configuration parameters result in different settings for the free state of the initial memory file system after decompression at runtime, thus different methods for loading the virtual machine image from the storage medium into the first image execution memory via the bootloader based on different first configuration parameters. If the first configuration parameter allows the initial memory file system to be freed after decompression at runtime, the bootloader first loads the virtual machine image from the storage medium into the first image backup memory, and then the hypervisor loads the virtual machine image from the first image backup memory into the first image execution memory. If the first configuration parameter prohibits the initial memory file system from being freed after decompression at runtime, the bootloader can directly load the virtual machine image from the storage medium into the first image execution memory. For further details, please refer to the descriptions of the embodiments below, and the embodiments of this disclosure are not limited thereto.

[0058] In some embodiments, if the first configuration parameter is set to allow the initial memory file system to be freed after decompression at runtime, then, as shown in Figure 6, step 205 above may include the following steps 2051 to 2052 based on the embodiment of Figure 2 described above.

[0059] In step 2051, in response to the first configuration parameter being set to allow the initial memory file system to be freed after decompression at runtime, the virtual machine image is loaded from the storage medium into the first image backup memory via the boot loader.

[0060] In some embodiments, for each virtual machine, a first configuration parameter is configured to allow the initial memory file system to be released after decompression at runtime. That is, after the initial memory file system decompresses into running memory during the boot process and completes its task, the running memory occupied by the initial memory file system can be actively released and made available for subsequent components (e.g., the virtual machine image). Therefore, the initial memory file system needs to be reloaded each time the virtual machine is started. Accordingly, during the system startup phase, the complete virtual machine image (including the kernel image, device tree files, and initial memory file system) is loaded from the storage medium into a dedicated first image backup memory via the boot loader. That is, the first image backup memory stores the complete virtual machine image, including the initial memory file system, and when a subsequent virtual machine is created, started, or restarted, the complete virtual machine image, including the initial memory file system, can be copied from the first image backup memory to a dedicated first image running memory.

[0061] For example, as shown in Figure 7, the first image backup memory includes the first sub-backup memory 06, the second sub-backup memory 07, and the third sub-backup memory 08, and the first image execution memory includes the first sub-execution memory 09, the second sub-execution memory 10, and the third sub-execution memory 11. During the system startup phase, if the first configuration parameter is set to allow the initial memory file system to be released after decompression at runtime, the bootloader loads the Kernel Image from the storage medium into the first sub-backup memory 06, the DTB from the virtual machine image into the second sub-backup memory 07, and the Initrd from the virtual machine image into the third sub-backup memory 08.

[0062] In step 2052, the virtual machine image is copied from the first image backup memory to the first image execution memory via the running virtual machine controller.

[0063] In some embodiments, after loading the virtual machine image from the storage medium into the first image backup memory via the boot loader, the boot loader is transferred to the hypervisor via step 206 described below, and the system jumps to the execution of the hypervisor. Furthermore, step 2052 is executed, that is, the virtual machine image is copied from each first image backup memory to the corresponding first image execution memory via the hypervisor.

[0064] In some embodiments, step 2052 may specifically include, in response to the virtual machine image stored in the first image backup memory including a kernel image, a device tree file, and an initial memory file system, copying the kernel image from the first image backup memory to a first sub-execution memory within the first image execution memory, copying the device tree file from the first image backup memory to a second sub-execution memory within the first image execution memory, and copying the initial memory file system from the first image backup memory to a third sub-execution memory within the first image execution memory, via the virtual machine controller.

[0065] In some cases, the first image backup memory can be divided into a first sub-backup memory, a second sub-backup memory, and a third sub-backup memory, with the first sub-backup memory used to store the kernel image, the second sub-backup memory used to store the device tree file, and the third sub-backup memory used to store the initial memory file system. The kernel image is copied from the first sub-backup memory to the first sub-execution memory via the virtual machine controller hypervisor, the device tree file is copied from the second sub-backup memory to the second sub-execution memory, and the initial memory file system is copied from the third sub-backup memory to the third sub-execution memory.

[0066] For example, as shown in Figure 7, during the system startup phase, the Kernel Image can be copied from the first sub-backup memory 06 to the first sub-execution memory 09 via the hypervisor, the DTB can be copied from the second sub-backup memory 07 to the second sub-execution memory 10, and the Initrd can be copied from the third sub-backup memory 08 to the third sub-execution memory 11. This allows at least one virtual machine to be generated via the hypervisor thereafter.

[0067] According to the above embodiment, in response to the first configuration parameter being set to allow the initial memory file system to be released after decompression at runtime, the boot loader loads the virtual machine image from the storage medium into the first image backup memory, and the running virtual machine controller copies the virtual machine image from the first image backup memory to the first image execution memory. Therefore, if the initial memory file system is allowed to be released after decompression, a backup of the complete virtual machine image is provided in the first image backup memory, thereby ensuring that the complete virtual machine image can be copied from the first image backup memory to the first image execution memory to start or restart the virtual machine.

[0068] In some other embodiments, if the first configuration parameter is set to prevent the initial memory file system from being released after decompression at runtime, then, as shown in Figure 8, step 205 above may include the following step 2053 based on the embodiment of Figure 2 described above.

[0069] In step 2053, in response to the first configuration parameter setting that prevents the initial memory file system from being released after decompression at runtime, the virtual machine image is loaded from the storage medium into the first image execution memory via the boot loader.

[0070] In some cases, the virtual machine image stored on the storage medium is a complete image file, meaning the virtual machine image simultaneously includes the kernel image, device tree file, and initial memory file system. Therefore, the first image execution memory can be divided into a first sub-execution memory, a second sub-execution memory, and a third sub-execution memory. The first sub-execution memory is used to store the kernel image, the second sub-execution memory is used to store the device tree file, and the third sub-execution memory is used to store the initial memory file system. If the first configuration parameter is set to prevent the initial memory file system from being released after decompression at runtime, the kernel image can be loaded from the storage medium into the first sub-execution memory, the device tree file into the second sub-execution memory, and the initial memory file system into the third sub-execution memory via the boot loader. This enables the loading of the virtual machine image from the storage medium into the first image execution memory via the boot loader.

[0071] For example, as shown in Figure 9, the first image backup memory includes the first sub-backup memory 01 and the second sub-backup memory 02, and the first image execution memory includes the first sub-execution memory 03, the second sub-execution memory 04, and the third sub-execution memory 05. During the system startup phase, if the first configuration parameter is set to prevent the initial memory file system from being released after decompression at runtime, the bootloader loads the Kernel Image from the storage medium into the first sub-execution memory 03, the DTB from the virtual machine image into the second sub-execution memory 04, and the Initrd from the virtual machine image into the third sub-execution memory 05.

[0072] According to the above embodiment, in response to the setting by the first configuration parameter that prevents the initial memory file system from being released after decompression at runtime, the boot loader loads the virtual machine image from the storage medium into the first image execution memory, and then generates and starts the virtual machine based on the virtual machine image loaded into the first image execution memory. Therefore, it is not necessary to load the virtual machine image from the storage medium into the first image backup memory via the boot loader and copy it from the first image backup memory to the first image execution memory. This simplifies the virtual machine generation and startup flow during the system startup phase and shortens the time required to start the virtual machine once.

[0073] In some embodiments, the method for executing a virtual machine according to embodiments of the present disclosure may further include the step of copying the virtual machine image from a first image execution memory to a first image backup memory via a running virtual machine controller before executing the virtual machine.

[0074] To ensure reloading after a failure to load the virtual machine into the first image execution memory or restarting after an abnormal shutdown of the virtual machine, the initial memory file system is retained without being released after decompression following the transfer of control from the boot loader to the virtual machine controller. Furthermore, partial virtual machine images (i.e., kernel images and device tree files) can be copied from each first image execution memory to the corresponding first image backup memory via the virtual machine controller.

[0075] In some embodiments, the step of copying the virtual machine image from the first image execution memory to the first image backup memory via the running virtual machine controller may specifically include, in response to the virtual machine image stored in the first image execution memory including a kernel image, a device tree file, and an initial memory file system, copying the kernel image from the first image execution memory to a first sub-backup memory within the first image backup memory and copying the device tree file from the first image execution memory to a second sub-backup memory within the first image backup memory via the running virtual machine controller.

[0076] In some embodiments, the first sub-execution memory within the first image execution memory is used to store the kernel image, the second sub-execution memory is used to store the device tree file, and the third sub-execution memory is used to store the initial memory file system. Because the first configuration parameter is set to prevent the initial memory file system from being released after decompression at runtime, after the kernel image, device tree file, and initial memory file system have been decompressed and completed their respective tasks, the kernel image and device tree file are released, but the initial memory file system is not. That is, the first and second sub-execution memories are released, but the third sub-execution memory remains occupied by the initial memory file system, which has not been released. Therefore, it is sufficient to back up only the kernel image and device tree file; that is, the kernel image can be copied from the first sub-execution memory within the first image execution memory to the first sub-backup memory within the first image backup memory via the running virtual machine controller, and the device tree file can be copied from the second sub-execution memory within the first image execution memory to the second sub-backup memory within the first image backup memory. Thus, compared to the embodiment described above in which the initial memory file system is released, this embodiment employs a method that does not release the initial memory file system, resulting in a smaller memory space being occupied by the first image backup memory.

[0077] For example, as shown in Figure 9, the first image backup memory includes the first sub-backup memory 01 and the second sub-backup memory 02, and the first image execution memory includes the first sub-execution memory 03, the second sub-execution memory 04, and the third sub-execution memory 05. Since the initial memory file system is retained and not released after decompression, it is sufficient to back up only the kernel image and device tree files. This allows the Kernel Image to be copied from the first sub-execution memory 03 to the first sub-backup memory 01 and the DTB to be copied from the second sub-execution memory 04 to the second sub-backup memory 02 via the hypervisor before the virtual machine starts running.

[0078] According to the above embodiment, before running the virtual machine, the kernel image can be copied from the first image execution memory to the first sub-backup memory within the first image backup memory via the running virtual machine controller, and the device tree file can be copied from the first image execution memory to the second sub-backup memory within the first image backup memory. Therefore, only the kernel image and device tree file need to be backed up for each virtual machine, and there is no need to back up the initial memory file system, thus reducing the image backup memory space used and saving memory resources. In addition, during normal startup and execution of the virtual machine and when restarting the virtual machine, the hypervisor only needs to copy the kernel image and device tree file, and there is no need to copy the initial memory file system, thus improving the virtual machine startup performance.

[0079] In step 206, the boot loader loads the virtual machine controller image from the storage medium into a second image execution memory pre-allocated to the virtual machine controller, and the boot loader switches to running the virtual machine controller in the second image execution memory.

[0080] In some embodiments, the second image execution memory may be a dedicated execution memory pre-allocated to the virtual machine controller, and the boot loader determines which second image execution memory is pre-allocated to the virtual machine controller based on the virtual machine controller identifier. If the controller image of the virtual machine controller is stored on the storage medium, the controller image of the virtual machine controller can be loaded from the storage medium into the second image execution memory via the boot loader.

[0081] In some embodiments, the switch from the bootloader to the execution of the virtual machine controller in the second image execution memory can be understood as triggering a jump instruction via the bootloader to transfer CPU control to the virtual machine controller. The CPU then switches from the bootloader execution context to the virtual machine controller execution context, executes the virtual machine controller code at the entry address of the controller image in the second image execution memory, and starts the virtual machine controller.

[0082] In step 207, a virtual machine is created based on the virtual machine image via the running virtual machine controller, and a virtual machine execution instruction is executed to trigger a jump to the kernel entry address of the first image execution memory, thereby running the virtual machine.

[0083] In some examples, the kernel entry address of the first image execution memory is the starting address of the kernel image within the virtual machine image. The DTB file within each virtual machine image is analyzed via the virtual machine controller to obtain hardware parameters (memory layout, peripheral base address, etc.), initialize the device tree file of the virtual machine, generate a virtual machine control structure to record the image path and execution state, etc., and realize the creation of at least one virtual machine. Subsequently, a virtual machine execution instruction (e.g., vm_run) is executed via the virtual machine controller to set the CPU context of the virtual machine based on the starting address of the kernel image. This switches the CPU to virtual machine mode, triggering the CPU to jump to the starting address of the kernel image, read instructions from that address, and execute them. The virtual machine kernel analyzes the DTB and mounts the true root file system based on Initrd to successfully start and run each virtual machine, realizing independent startup of each virtual machine. For specific implementations of the virtual machine creation and startup process, please refer to the detailed descriptions of related technologies, which are not detailed in the embodiments of this disclosure.

[0084] According to the above embodiment, the first configuration parameter of the device tree file contained in the virtual machine image stored on the storage medium is determined via the running boot loader, the virtual machine image is loaded from the storage medium into the first image execution memory based on the first configuration parameter, and at the same time, the controller image of the virtual machine controller is loaded into the second image execution memory, the execution of the virtual machine controller is switched to the second image execution memory, a virtual machine is generated based on the virtual machine image via the virtual machine controller, virtual machine execution instructions are executed, and a jump to the kernel entry address of the first image execution memory is triggered to execute the virtual machine. In other words, this solution can dynamically determine the load strategy based on the configuration parameter of the device tree file, thereby flexibly adapting to differences in the memory layout of different embedded hardware and improving the compatibility and stability of the system boot flow.

[0085] Exemplary device Figure 10 is a schematic diagram of the structure of a virtual machine execution device according to one exemplary embodiment of the present disclosure. The device can be installed on electronic devices such as terminal equipment and servers, or on objects such as vehicles, and executes the virtual machine execution method of any of the embodiments of the present disclosure.

[0086] As shown in Figure 10, the device 300 may include a first decision module 301, a first copy module 302, and a first startup module 303. The first decision module 301 can be used to determine the first image execution memory and first image backup memory pre-allocated to each virtual machine via the virtual machine controller when it receives a virtual machine restart command in response to at least one virtual machine being in a terminated state. The first copy module 302 can be used via the virtual machine controller to copy the virtual machine image stored in the first image backup memory to the first image execution memory. The first startup module 303 can be used to execute a virtual machine restore command via the virtual machine controller and trigger a jump to the kernel entry address of the first image execution memory to resume execution of the virtual machine.

[0087] In one possible embodiment, the first copy module 302 can be used, specifically, via the virtual machine controller, to copy the kernel image to a first sub-execution memory within the first image execution memory and the device tree file to a second sub-execution memory within the first image execution memory, in response that the virtual machine image stored in the first image backup memory includes only a kernel image and a device tree file, and the initial memory file system within the virtual machine image is stored in the first image execution memory.

[0088] In one possible embodiment, the first copy module 302 can, specifically, be used to copy the initial memory file system to a third sub-execution memory within the first image execution memory via the virtual machine controller, in response to the virtual machine image stored in the first image backup memory further including an initial memory file system and the initial memory file system in the virtual machine image not being stored in the first image execution memory.

[0089] In one possible embodiment, the apparatus 300 may further include a second determination module, a first load module, a second load module, and a second startup module. The second determination module can be used to determine a first configuration parameter for a device tree file contained in each of the virtual machine images stored in a storage medium via a running boot loader, where the first configuration parameter is for setting the free state after the initial memory file system contained in the virtual machine image has been decompressed at runtime. The first load module can be used via the boot loader to load each of the virtual machine images from the storage medium into the first image execution memory based on the first configuration parameter. The second load module can be used via the boot loader to load a controller image of the virtual machine controller from the storage medium into a second image execution memory pre-allocated to the virtual machine controller, and to switch from the boot loader to the execution of the virtual machine controller in the second image execution memory. The second startup module is used to generate the virtual machine based on the virtual machine image via the running virtual machine controller, execute virtual machine execution instructions to trigger a jump to the kernel entry address of the first image execution memory, and execute the virtual machine.

[0090] In one possible embodiment, the first load module can be used to load the virtual machine image from the storage medium into the first image backup memory via the boot loader, in response to the first configuration parameter being configured to allow the initial memory file system to be freed after decompression at runtime, and to copy the virtual machine image from the first image backup memory to the first image execution memory via the running virtual machine controller.

[0091] In one possible embodiment, the first load module can be used, specifically, via the virtual machine controller, to copy the kernel image from the first image backup memory to a first sub-execution memory within the first image execution memory, the device tree file from the first image backup memory to a second sub-execution memory within the first image execution memory, and the initial memory file system from the first image backup memory to a third sub-execution memory within the first image execution memory, in response that the virtual machine image stored in the first image backup memory includes a kernel image, a device tree file, and an initial memory file system.

[0092] In one possible embodiment, the first load module can be used to load the virtual machine image from the storage medium into the first image execution memory via the boot loader, in response to the first configuration parameter being configured such that the initial memory file system is prohibited from being released after decompression at runtime.

[0093] In one possible embodiment, the apparatus 300 may further include a second copy module. The second copy module can be used to copy the virtual machine image from the first image execution memory to the first image backup memory via the running virtual machine controller before the virtual machine is executed.

[0094] In one possible embodiment, the second copy module can be used, specifically, in response to the virtual machine image stored in the first image execution memory including a kernel image, a device tree file, and an initial memory file system, to copy the kernel image from the first image execution memory to a first sub-backup memory within the first image backup memory, and to copy the device tree file from the first image execution memory to a second sub-backup memory within the first image backup memory, via a running virtual machine controller.

[0095] The beneficial technical effects corresponding to the exemplary embodiment of this device can be found by referring to the corresponding beneficial technical effects in the exemplary method section described above, and will not be described in detail here.

[0096] Exemplary electronic device Figure 11 is a structural diagram of an electronic device according to an embodiment of the present disclosure, the electronic device 11 including at least one processor 111 and a storage device 112.

[0097] The processor 111 may be a central processing unit (CPU) or another type of processing unit having data processing capability and / or instruction execution capability, and can control other components in the electronic device 11 to perform desired functions.

[0098] The storage device 112 may include one or more computer program products, including various forms of computer-readable storage media such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or high-speed cache memory (cache). Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions can be stored in the computer-readable storage media, and the processor 111 can execute one or more computer program instructions to implement the virtual machine execution methods and / or other desired functions of each embodiment of the present disclosure described above.

[0099] As one example, the electronic device 11 may further include an input device 113 and an output device 114, and these components are interconnected via a bus system and / or other forms of connection mechanisms (not shown).

[0100] The input device 113 may include various sensors, including, but not limited to, the following: a distance measuring sensor used to detect the distance between a target object and the vehicle, and an image sensor used to collect environmental information around the vehicle. In some examples, the input device may further include pressure sensors used to detect seat pressure and determine the presence and location of passengers; temperature sensors used to monitor the temperature inside the cockpit; humidity sensors used to monitor the humidity inside the cockpit and support the adjustment of the in-vehicle environment; air quality sensors used to monitor in-vehicle air quality by monitoring carbon dioxide, volatile organic compounds (VOCs), etc.; light sensors used to detect light intensity inside and outside the vehicle; acceleration sensors used to detect changes in the vehicle's acceleration; distance sensors used to detect the distance between the vehicle and other objects; touch display sensors used for interaction with the vehicle's infotainment system; biometric sensors used for fingerprint authentication, facial recognition, etc.; heart rate monitors used to monitor the driver's heart rate; voice sensors used for voice recognition and interaction to realize voice control functions; seat sensors used to monitor seat usage, such as whether the seat is occupied and the passenger's body shape; and wireless communication sensors such as Bluetooth® and Wi-Fi used to realize data transfer and remote control by connecting with smart devices. In addition to the examples described above, the input device may include more or fewer sensors, which are not detailed here.

[0101] The output device 114 can output various information or signals to other hardware or devices, which may include displays, in-vehicle speakers, seats, windows, steering wheels, etc., and communication networks and remote output devices connected thereto. Here, the displays may include multiple different displays such as a driver's seat display, a passenger seat display, and a rear seat display, and the in-vehicle speakers may include multiple speakers installed in different locations within the vehicle cockpit, and each of the different displays or speakers can operate independently.

[0102] Of course, for the sake of simplification, Figure 11 shows only some of the components in the electronic device 11 that are relevant to this disclosure, and components such as buses and input / output interfaces are omitted. In addition, depending on the specific application, the electronic device 11 may include other appropriate components.

[0103] Exemplary computer program products and computer-readable storage media Embodiments of the present disclosure may also include, in addition to the methods and apparatus described above, computer program products that, when executed by a processor, cause the processor to perform steps of the virtual machine execution method of the various embodiments of the present disclosure described in the “Exemplary Methods” section above.

[0104] Computer program products can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java® and C++, and common procedural programming languages ​​such as the C language or similar programming languages, to create program code for performing the operations of the embodiments of this disclosure. The program code may run entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device, partially on a remote computing device, or entirely on a remote computing device or server.

[0105] Furthermore, embodiments of the present disclosure may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform steps of the virtual machine execution method of the various embodiments of the present disclosure described in the “Exemplary Methods” section above.

[0106] Computer-readable storage media can employ any combination of one or more readable media. The readable media may be readable signal media or readable storage media. Readable storage media may include, but are not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include electrical connections with one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above.

[0107] While the basic principles of this disclosure have been explained above with reference to specific examples, the advantages, advantages, and effects mentioned in this disclosure are merely illustrative and not limiting, and it is not assumed that these advantages, advantages, and effects must be present in each example of this disclosure. Furthermore, the specific details disclosed above are merely illustrative and intended to facilitate understanding, and are not limiting, nor do they imply that this disclosure must be implemented in the specific details described above.

[0108] Those skilled in the art can make various modifications and variations to this disclosure without departing from the spirit and scope of the application. Thus, if such modifications and variations of the application fall within the scope of the claims of this disclosure and the equivalent art, this disclosure is intended to include such modifications and variations.

Claims

1. A method for executing a virtual machine, wherein each step is executed by the virtual machine's execution device, When a virtual machine restart command is received in response to at least one virtual machine being in a terminated state, the virtual machine controller determines the first image execution memory and first image backup memory that have been pre-allocated to each virtual machine. The steps include: copying the virtual machine image stored in the first image backup memory via the virtual machine controller to the first image execution memory; A method for executing a virtual machine, comprising the steps of executing a virtual machine restore command via the virtual machine controller, triggering a jump to the kernel entry address of the first image execution memory, and restarting the execution of the virtual machine.

2. The step of copying the virtual machine image stored in the first image backup memory via the virtual machine controller to the first image execution memory is: A method for executing a virtual machine according to claim 1, comprising the steps of copying the kernel image to a first sub-execution memory within the first image execution memory and copying the device tree file to a second sub-execution memory within the first image execution memory via the virtual machine controller, in response that the virtual machine image stored in the first image backup memory includes only a kernel image and a device tree file and that the initial memory file system within the virtual machine image is stored in the first image execution memory.

3. The step of copying the virtual machine image stored in the first image backup memory via the virtual machine controller to the first image execution memory is: A method for executing a virtual machine according to claim 1, comprising the steps of copying the kernel image to a first sub-execution memory in the first image execution memory, copying the device tree file to a second sub-execution memory in the first image execution memory, and copying the initial memory file to a third sub-execution memory in the first image execution memory, via the virtual machine controller, in response that the virtual machine image stored in the first image backup memory includes a kernel image, a device tree file, and an initial memory file system, and that the initial memory file system in the virtual machine image is not stored in the first image execution memory.

4. If a virtual machine restart command is received in response to at least one virtual machine being in a terminated state, the virtual machine execution method, prior to determining the first image execution memory and first image backup memory pre-allocated to each virtual machine via the virtual machine controller, further: A step of determining a first configuration parameter for a device tree file contained in each virtual machine image stored on a storage medium via a running boot loader, wherein the first configuration parameter is for setting the free state of the initial memory file system contained in the virtual machine image after it has been decompressed at runtime; The steps include loading the virtual machine image from the storage medium into the first image execution memory based on the first configuration parameters via the boot loader, The boot loader loads the controller image of the virtual machine controller from the storage medium into a second image execution memory pre-allocated to the virtual machine controller, and switches from the boot loader to the execution of the virtual machine controller in the second image execution memory. A method for executing a virtual machine according to claim 1, comprising the steps of generating the virtual machine based on the virtual machine image via a running virtual machine controller, executing a virtual machine execution instruction to trigger a jump to the kernel entry address of the first image execution memory, and executing the virtual machine.

5. The step of loading the virtual machine image from the storage medium into the first image execution memory based on the first configuration parameters via the boot loader is: In response to the fact that the initial memory file system is configured by the first configuration parameter to allow decompression and release at runtime, the steps include loading the virtual machine image from the storage medium into the first image backup memory via the boot loader, A method for running a virtual machine according to claim 4, comprising the step of copying the virtual machine image from the first image backup memory to the first image execution memory via a running virtual machine controller.

6. The step of copying the virtual machine image from the first image backup memory to the first image execution memory via the running virtual machine controller is: A method for executing a virtual machine according to claim 5, comprising the steps of, in response that the virtual machine image stored in the first image backup memory includes a kernel image, a device tree file, and an initial memory file system, via the virtual machine controller, copying the kernel image from the first image backup memory to a first sub-execution memory in the first image execution memory, copying the device tree file from the first image backup memory to a second sub-execution memory in the first image execution memory, and copying the initial memory file system from the first image backup memory to a third sub-execution memory in the first image execution memory.

7. The step of loading the virtual machine image from the storage medium into the first image execution memory based on the first configuration parameters via the boot loader is: A method for executing a virtual machine according to claim 4, comprising the step of loading the virtual machine image from the storage medium into the first image execution memory via the boot loader in response to the setting by the first setting parameter that the initial memory file system is prohibited from being released after decompression at runtime.

8. A method for executing a virtual machine according to claim 7, further comprising the step of copying the virtual machine image from the first image execution memory to the first image backup memory via a running virtual machine controller before executing the virtual machine.

9. The step of copying the virtual machine image from the first image execution memory to the first image backup memory via the running virtual machine controller is: A method for executing a virtual machine according to claim 8, comprising the steps of copying the kernel image from the first image execution memory to a first sub-backup memory in the first image backup memory and copying the device tree file from the first image execution memory to a second sub-backup memory in the first image backup memory, via a running virtual machine controller, in response that the virtual machine image stored in the first image execution memory includes a kernel image, a device tree file and an initial memory file system.

10. When a virtual machine restart command is received in response to at least one virtual machine being in a terminated state, a first determination module for determining the first image execution memory and first image backup memory pre-allocated to each virtual machine via the virtual machine controller, A first copy module for copying a virtual machine image stored in the first image backup memory via the virtual machine controller to the first image execution memory, A virtual machine execution device, comprising: a first boot module for executing a virtual machine restore command via the virtual machine controller and for triggering a jump to the kernel entry address of the first image execution memory to resume execution of the virtual machine.

11. A computer-readable storage medium that, when executed by a processor, stores a computer program for realizing the method of executing a virtual machine according to any one of claims 1 to 9.

12. Processor and The processor includes a storage device for storing executable instructions, The processor reads and executes the executable instructions from the storage device to realize the method for executing a virtual machine according to any one of claims 1 to 9, an electronic device.

Images