Virtual machine multi-core starting method and device, storage medium and electronic equipment

Abstract

The embodiment of the invention provides a virtual machine multi-core starting method and device, a storage medium and electronic device.The method comprises the steps that a configured virtual machine is started; the virtual machine is configured with a plurality of virtual processors and other components except the plurality of virtual processors; capturing a power management request sent by a plurality of virtual processors through a specified falling mechanism through a virtual monitor, and simulating a response behavior of power management equipment to the power management request through the virtual monitor to obtain a first interaction result; directly performing hardware interaction with the power management equipment through other components to obtain a second interaction result; and starting a plurality of virtual processors of the virtual machine based on the first interaction result and the second interaction result, and through the method and the device, the problem that the virtual machine cannot be started due to large Hypervisor analog quantity in related technologies is solved.

Description

Technical Field

[0001] Embodiments of the present application relate to the technical field of vehicle virtualization systems, and more specifically, to a method, device, storage medium, and electronic device for starting up multiple cores of a virtual machine. Background Art

[0002] With the rapid development of automotive electronic technology, automotive operating systems are also constantly being subdivided according to their specific application scenarios. At present, automotive operating systems are mainly divided into two categories, namely vehicle control operating systems and vehicle-mounted operating systems. Vehicle control operating systems are mainly aimed at the field of classic vehicle control; vehicle-mounted operating systems are mainly aimed at the fields of infotainment and smart cockpits. With the acceleration of changes in electronic and electrical architectures, cross-domain integration has become a general trend. Under the cross-domain integration solution, domain operating systems are rapidly taking shape, and traditional operating systems are transforming from multiple independent operating systems to a unified operating system. The most mainstream technology for integrating multiple operating systems is virtualization technology, which enables operating systems in multiple different domains to run on the same hardware.

[0003] When using PSCI (Power State Coordination Interface) to start multiple CPU cores of a virtual machine, the hypervisor is required to simulate the hardware resources of the power management device and interact with the virtual machine through the SMC protocol.

[0004] However, there may be a large amount of hardware in the virtual machine's operating system that needs to interact with it. In the process of simulating the hardware through the Hypervisor, there is a problem of large simulation amount. If the Hypervisor does not simulate them perfectly, the operation of the virtual machine may have problems or even fail to start. Summary of the invention

[0005] The embodiments of the present application provide a method, device, storage medium and electronic device for starting a virtual machine multi-core, so as to at least solve the problem of being unable to start the virtual machine due to the large amount of Hypervisor simulation in the method for starting a virtual machine multi-core in the related art.

[0006] According to one aspect of an embodiment of the present application, a method for multi-core startup of a virtual machine is provided, comprising: starting a configured virtual machine; the virtual machine is configured with multiple virtual processors and other components except the multiple virtual processors; capturing power management requests sent by the multiple virtual processors through a specified trap mechanism through a virtual monitor, and simulating the response behavior of a power management device to the power management request through the virtual monitor to obtain a first interaction result; directly performing hardware interaction with the power management device through the other components to obtain a second interaction result; and starting the multiple virtual processors of the virtual machine based on the first interaction result and the second interaction result.

[0007] According to another aspect of an embodiment of the present application, a multi-core startup device for a virtual machine is provided, comprising: a configuration startup module, used to start a configured virtual machine; the virtual machine is configured with multiple virtual processors and other components except the multiple virtual processors; a simulation module, used to capture power management requests sent by the multiple virtual processors through a specified trap mechanism through a virtual monitor, and simulate the response behavior of the power management device to the power management request through the virtual monitor to obtain a first interaction result; a hardware interaction module, used to directly perform hardware interaction with the power management device through the other components to obtain a second interaction result; a multi-core startup module, used to start the multiple virtual processors of the virtual machine based on the first interaction result and the second interaction result.

[0008] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the above-mentioned virtual machine multi-core startup method when running.

[0009] According to another aspect of an embodiment of the present application, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the virtual machine multi-core startup method through the computer program.

[0010] According to another aspect of the embodiments of the present application, a computer program product is provided, including a computer program, which, when executed by a processor, implements the steps in any of the above-mentioned virtual machine multi-core startup method embodiments.

[0011] Through the embodiments of the present application, the virtual machine is allowed to interact directly with the power management device to start devices other than the virtual processor (CPU core), that is, the devices other than the virtual processor in the virtual machine directly interact with the power management device without being simulated by the virtual monitor, and the startup of the virtual processor is trapped in the virtual monitor for simulation through a specified trap mechanism, thereby reducing the simulation amount of the virtual monitor; by separating the startup of the virtual processor from the direct interaction with the power management device, it is possible to effectively avoid conflicts caused by multiple virtual machines trying to interact with the power management device at the same time. The startup of the virtual processor is controlled by the virtual monitor, while the interaction of other devices is carried out directly, which can not only ensure the correct startup of the virtual processor, but also reduce the load and complexity of the virtual monitor. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 It is a hardware structure block diagram of an optional virtual machine multi-core startup method in an embodiment of the present application;

[0013] Figure 2 It is a flowchart of an optional virtual machine multi-core startup method according to an embodiment of the present application;

[0014] Figure 3 is a schematic diagram of an optional overall virtualization architecture according to an embodiment of the present application;

[0015] Figure 4 is a schematic diagram of an optional bare metal virtualization structure according to an embodiment of the present application;

[0016] Figure 5 is a schematic diagram of an optional CPU virtualization according to an embodiment of the present application;

[0017] Figure 6 is a schematic diagram of an optional ARMV8 exception level according to an embodiment of the present application;

[0018] Figure 7 is a schematic diagram of a control bit of an optional HCR_EL2 register according to an embodiment of the present application;

[0019] Figure 8 is an optional PSCI instruction simulation flow chart according to an embodiment of the present application;

[0020] Fig. 9 It is a structural block diagram of an optional virtual machine multi-core startup device according to an embodiment of the present application;

[0021] Fig.10 It is a structural block diagram of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0023] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0024] According to one aspect of an embodiment of the present application, a method for starting a multi-core virtual machine is provided. Optionally, in this embodiment, the multi-core virtual machine starting method can be applied to Figure 1 In the hardware environment composed of the vehicle terminal 102 and the server 104 shown in FIG. Figure 1 As shown, the server 104 is connected to the vehicle-mounted terminal 102 via a network, and can be used to provide services (such as application services, etc.) for the terminal or a client installed on the terminal. A database can be set up on the server or independently of the server to provide data storage services for the server 104. Cloud computing and / or edge computing services can be configured on the server or independently of the server to provide data computing services for the server 104.

[0025] The above network may include but is not limited to at least one of the following: wired network, wireless network. The above wired network may include but is not limited to at least one of the following: wide area network, metropolitan area network, local area network, and the above wireless network may include but is not limited to at least one of the following: WIFI, Bluetooth.

[0026] The virtual machine multi-core startup method of the embodiment of the present application can be executed by the vehicle terminal 102, or can be executed by the server 104 and the vehicle terminal 102 together. Taking the vehicle terminal 102 executing the virtual machine multi-core startup method of the embodiment as an example, Figure 2 is a flow chart of an optional virtual machine multi-core startup method according to an embodiment of the present application, such as Figure 2As shown, the process of the method may include the following steps:

[0027] Step S202: Start the configured virtual machine; the virtual machine is configured with multiple virtual processors and other components except the multiple virtual processors.

[0028] Among them, a virtual machine (VM) is a complete computer system with complete hardware system functions that runs in an isolated environment and is simulated by software. It can run on the physical hardware of the host machine and simulate a complete hardware environment including CPU, memory, disk, network equipment, etc. through virtualization technology. Each virtual machine runs its own operating system and applications, just like an independent physical machine. For example, in the automotive operating system, the Linux system is used as the operating system of one virtual machine, and the Android system is used as the operating system of another virtual machine, thereby achieving cross-domain integration.

[0029] Starting a configured virtual machine means loading and executing a pre-configured virtual machine instance on a virtualization platform (such as VMware ESXi, Hyper-V, KVM, etc.), which already contains the operating system, applications, and possible other configuration information (such as network settings, storage configuration, etc.). The startup process includes loading the virtual machine's operating system, initializing system services, loading necessary drivers, etc., and finally presenting a usable computing environment to the user.

[0030] A virtual processor (VCPU) is a simulated CPU in a virtual machine. A VCPU is a virtualized representation of a physical CPU, allowing the operating system and applications in the virtual machine to think that they are directly accessing the real physical CPU. The number of virtual processors can be configured as needed to improve the performance of the virtual machine.

[0031] In addition to the virtual processor, the virtual machine is also configured with various other components to simulate a complete computer system. For example, other components include but are not limited to: virtual memory, virtual disk, virtual network interface card (vNIC), virtual USB device, virtual graphics card, etc.

[0032] Optionally, the vehicle-mounted terminal determines a configured virtual machine and sends a startup command to the virtual machine. After receiving the startup command, the virtual machine starts to load the operating system and other components of the virtual machine.

[0033] Step S204: Capture power management requests sent by multiple virtual processors through the specified trap mechanism through the virtual monitor, and simulate the response behavior of the power management device to the power management request through the virtual monitor to obtain a first interaction result.

[0034] Among them, the virtual monitor (Hypervisor) is an intermediate software layer running between the basic hardware and the operating system, which allows multiple operating systems and applications to share hardware. It can also be called VMM (virtual machine monitor). Hypervisors are a "meta" operating system in a virtual environment that can access all physical devices and virtual machines. Figure 3 FIG. 1 is a schematic diagram of the overall architecture of virtualization in an embodiment. Figure 3 As shown in the figure, Hypervisor is the core of all virtualization technologies. When virtualization is started and Hypervisor is executed, Hypervisor will load the operating systems of all virtual machines and allocate appropriate hardware resources such as memory, CPU, network and disk to each virtual machine.

[0035] It should be noted that virtualization technology is mainly divided into Type I (bare metal virtualization) and Type II (host virtualization). The virtualization technology used in the embodiment of the present application is bare metal virtualization. Figure 4 FIG. 1 is a schematic diagram of a bare metal virtualization structure in an embodiment. Figure 4 As shown in the figure, bare metal virtualization does not require the underlying HOST OS (the underlying host operating system refers to the operating system running on physical hardware (such as a server or PC)), or the Hypervisor can be regarded as a customized Host OS. In addition to playing the role of VMM, other applications cannot be installed on it. The advantage of this virtualization is that it does not depend on the operating system and supports multiple operating systems and multiple applications.

[0036] It should be noted that CPU virtualization is an important part of virtualization technology. Figure 5 FIG. 1 is a schematic diagram of CPU virtualization in one embodiment. Figure 5 As shown in the figure, to realize CPU simulation, the physical CPU must first be abstracted into a VCPU. When the Hypervisor starts, a VM instance is created, and then a VCPU instance is created and initialized. The VCPU instance can exist as a Task (process) in the Hypervisor and set its affinity. For the VM, it has a similar logical execution environment. The Hypervisor can perform context switching and scheduling, as well as sleep / wake-up simulation.

[0037] A specified trap mechanism is a predetermined way of sending a request or signal from a virtual machine to a virtual monitor (Hypervisor). For example, the specified trap mechanism can be an HVC (Hypervisor Call) mechanism. In a virtualized environment, a virtual machine usually cannot directly access the underlying hardware, but indirectly accesses hardware resources through a virtual monitor. When a virtual machine needs to perform certain operations that can only be performed by a virtual monitor (such as power management, device I / O operations, etc.), it triggers a trap (Trap) through a specific trap instruction (such as an HVC instruction) to transfer control to the virtual monitor. The virtual monitor then processes the request and performs corresponding operations as needed.

[0038] A power management request refers to a request for a specific power state transition (such as entering a sleep state, waking up, etc.) in a virtualized environment. Generally, a power management request is initiated by a virtual machine. For example, a virtual machine can send power management requests such as sleep and wake up through the interface provided by the operating system. The power management request is sent to the virtual monitor through a specified trap mechanism (such as the HVC mechanism), and the virtual monitor is responsible for simulating the behavior of the power management device and processing the power management request.

[0039] According to the above description of virtualization system and CPU virtualization, a VM (virtual machine) may be configured with multiple VCPUs to improve its operating performance. For Linux or Android systems, PSCI (Power State Coordination Interface) is usually used to start multiple CPU cores. Among them, PSCI is an interface defined by the ARM architecture, which is used to coordinate power management operations between the operating system of the virtual machine and the power management device, such as CPU startup, stop, suspension and wake-up. In a virtualized environment, each virtual machine contains a set of virtual processors that simulate the behavior of the physical CPU. When the operating system or application in the virtual machine needs to perform operations related to power management, the PSCI interface is usually called through the virtual processor. However, since the virtual machine does not directly access the physical hardware, these PSCI calls are actually indirectly completed through the Hypervisor. Therefore, in a multi-core started virtualized environment, the virtual processor is the main body for performing operations related to the PSCI interface, but the actual execution of these operations is completed by the Hypervisor. This mechanism ensures the stability and security of the virtualized environment while providing flexible support for power management.

[0040] Response behavior refers to the actions taken by the virtual monitor after receiving a power management request from the virtual machine, including parsing the content of the request, determining the type of request (such as entering sleep, waking up, etc.), simulating the behavior of the power management device (such as adjusting the power state, updating the power management register, etc.), and sending a response to the virtual machine (usually a confirmation of success or the reason for failure).

[0041] The first interaction result refers to the result obtained by the virtual monitor after processing the power management request from the virtual machine. For example, the first interaction result includes whether the request is successfully processed, whether the power state changes as expected, whether any errors or exceptions occur, etc. According to the first interaction result, the virtual machine can further perform subsequent operations or perform error handling as needed.

[0042] Optionally, the vehicle terminal pre-configures a virtual monitor so that the virtual monitor captures power management requests sent by multiple virtual processors from the virtual machine through a specified trap mechanism, and simulates the PSCI interface in the virtual monitor and implements the processing logic of PSCI-related instructions. After the virtual machine triggers a power management request, the power management requests sent by multiple virtual processors through the specified trap mechanism are captured by the virtual monitor, and the response behavior of the power management device to the power management request is simulated by the virtual monitor to obtain a first interaction result.

[0043] Step S206: directly perform hardware interaction with the power management device through other components to obtain a second interaction result.

[0044] Among them, power management equipment refers to the hardware or software components responsible for controlling and optimizing the power usage of vehicle terminals. Power management equipment can monitor the current status of the power supply (such as power, voltage, current, etc.) and adjust the power usage mode of the vehicle terminal according to preset strategies or user instructions to achieve the purpose of saving energy, extending battery life or protecting equipment.

[0045] Hardware interaction refers to the direct communication between the power management device and other components of the virtual machine (such as memory, hard disk, graphics card, etc.) through electrical signals, data buses or other physical connections. Hardware interaction is based on specific hardware interface protocols or standards to ensure that power management instructions can be correctly received and executed.

[0046] It should be noted that: in order to solve the problem of large amount of Hypervisor simulation in related technologies, the virtual machine can also interact directly with the power management device, thereby omitting the process of Hypervisor simulation. However, this method is prone to cause conflicts between multiple virtual machines. In the embodiment of the present application, the Hypervisor simulates the operations related to the PSCI interface, and directly interacts with the power management device through other components. The Hypervisor simulation and direct hardware interaction are combined to effectively reduce the amount of Hypervisor simulation, and also avoid conflicts between multiple virtual machines, so as to realize the multi-CPU core startup of the virtual machine, so as to improve the performance of the virtual machine and the user experience.

[0047] The second interaction result refers to the result obtained by the power management device after processing the power management request sent by other components of the virtual machine. For example, the second interaction result includes the success / failure status of the power management request execution, power status update, performance parameter adjustment, resource allocation information, etc.

[0048] Optionally, the vehicle terminal determines the hardware interface type and communication protocol between other components in the virtual machine except the virtual controller and the power management device, connects other components in the virtual machine except the virtual controller to the hardware interface of the power management device through appropriate cables, connectors or circuit board layouts, and controls other components to communicate with the power management device through a driver. Other components receive response data from the power management device, parse the response data, and extract required information as the second interaction result.

[0049] Step S208: Based on the first interaction result and the second interaction result, start multiple virtual processors of the virtual machine.

[0050] Optionally, the vehicle-mounted terminal determines the correctness of the first interaction result and the second interaction result, and when the correctness of the first interaction result and the correctness of the second interaction result are both correct, starts multiple virtual processors of the virtual machine.

[0051] Through the above steps S202 to S208, the virtual machine is allowed to interact directly with the power management device to start devices other than the virtual processor (CPU core), that is, the devices other than the virtual processor in the virtual machine directly interact with the power management device without being simulated by the virtual monitor, and the startup of the virtual processor is trapped in the virtual monitor for simulation through a specified trap mechanism, thereby reducing the simulation amount of the virtual monitor; by separating the startup of the virtual processor from the direct interaction with the power management device, it is possible to effectively avoid conflicts when multiple virtual machines try to interact with the power management device at the same time. The startup of the virtual processor is controlled by the virtual monitor, while the interaction of other devices is directly carried out, which can not only ensure the correct startup of the virtual processor, but also reduce the load and complexity of the virtual monitor.

[0052] In an exemplary embodiment, before starting the configured virtual machine, the virtual machine multi-core startup method further includes:

[0053] When the operating system of the virtual machine is initialized, a virtual monitor call bit of a register within the virtual monitor is set to enable other components to directly perform hardware interaction with the power management device.

[0054] The operating system of a virtual machine refers to the operating system running inside the virtual machine. These virtual machines are independent computing environments created by abstracting and virtualizing the resources of a physical computer (such as CPU, memory, hard disk, etc.) through virtualization technology. For example, the operating system of a virtual machine can be Linux or Android.

[0055] System initialization is a series of steps performed by the operating system of a virtual machine during the startup process, which is designed to prepare the system hardware and software environment to run the operating system. In a virtualized environment, the system initialization of the operating system of a virtual machine specifically includes initializing the hardware abstraction layer of the virtual machine (VM), including the CPU, memory, I / O devices, etc. For the operating system of a virtual machine, the system initialization process is similar to that on a physical machine, but all hardware is virtual and provided by the virtual machine monitor (Hypervisor) or the operating system of the host machine.

[0056] The register is a special register in the ARMV8 architecture that is used to control the behavior of virtualization. Specific virtualization functions can be enabled or disabled through the register. For example, the register can be the HCR_EL2 register in the ARMV8 architecture, which is located at EL2 (Hypervisor Exception Level) and is one of the key registers used by the Hypervisor to configure and manage virtualization. HCR_EL2 contains multiple fields that are used to enable or disable specific virtualization functions, such as trapping specific instructions or exceptions to EL2, and controlling the behavior of the virtual machine.

[0057] It should be noted that: Figure 6 FIG. 1 is a schematic diagram of ARMV8 exception levels in an embodiment. Figure 6 As shown in the figure, in the ARMV8 architecture, there are four exception levels, corresponding to the four privilege levels of software execution. These four privilege levels logically separate the privileges required for software execution. The privilege levels of typical software operation are as follows:

[0058] EL0: Normal user application

[0059] EL1: operating system kernel or guest OS kernel

[0060] EL2: Hypervisor

[0061] EL3: Secure monitor

[0062] VMs run at two levels: EL0 and EL1. EL0 runs the client's application. EL1 runs the operating system. Hypervisor runs on EL2. If the VM needs to interact with the hardware, it can be EL2, which means it is simulated by the hypervisor, or it can interact directly with the hardware.

[0063] The virtual monitor call bit refers to the control bit in the register that controls which instructions or exceptions will be captured to EL2, allowing the Hypervisor to intervene and possibly perform operations related to power management. Taking the HCR_EL2 register as an example, Figure 7 FIG. 4 is a schematic diagram of the control bits of the HCR_EL2 register in one embodiment. Figure 7 As shown, the virtual monitor call bit of the HCR_EL2 register is the 19th bit of the register: the TSC bit. If the TSC bit is set to 0, when it is necessary to interact with the hardware through the SMC, it will interact with the hardware directly, so that the SMC instruction will not fall into the Hypervisor; if the TSC bit is set to 1, it will fall into EL2, that is, it will be simulated by the Hypervisor.

[0064] Optionally, Figure 8 A PSCI instruction simulation flow chart in one embodiment is shown as follows: Figure 8 As shown, when the vehicle terminal initializes the operating system of the virtual machine, it sets the virtual monitor call bit of the register (such as the HCR_EL2 register) in the virtual monitor (such as setting the TSC bit to 0), so that the instructions issued by other components will not fall into the Hypervisor and will directly interact with the power management device in hardware.

[0065] Through this embodiment, when the operating system of the virtual machine is initialized, the virtual monitor call bit of the register in the virtual monitor is set so that instructions issued by other components will not fall into the Hypervisor. In this way, the Hypervisor will not simulate instructions issued by other components of the virtual machine, and other components directly perform hardware interaction with the power management device, thereby reducing the simulation amount of the Hypervisor.

[0066] In an exemplary embodiment, before starting the configured virtual machine, the virtual machine multi-core startup method further includes:

[0067] 1. Scan the first device tree of the virtual monitor and the second device tree of the virtual machine.

[0068] The first device tree is a data structure that describes hardware. It represents the device information in the system in a tree form, and mainly describes the physical hardware resources (including but not limited to CPU, memory, storage devices, network devices, etc.) that the Hypervisor can identify, access, and manage. Through the first device tree of the virtual monitor, the Hypervisor can ensure that each virtual machine can obtain the hardware resources it needs, and these resources are isolated from each other to ensure the security and stability of the virtual machine.

[0069] The second device tree is a data structure that describes hardware. It represents the device information in the system in a tree format, and mainly describes the hardware resources seen inside the virtual machine. These hardware resources are actually virtualized by the Hypervisor, not real physical hardware. The second device tree of the virtual machine includes detailed information about virtual hardware such as CPU, memory, disk, network interface, etc.

[0070] Optionally, the vehicle terminal provides an API or command line tool through the virtualization platform to access the first device tree of the virtual monitor, or the first device tree of the virtual monitor can be obtained by viewing log files, using debugging tools, or consulting official documents. Inside the virtual machine, the operating system of the virtual machine usually exposes the device tree information in some way. Therefore, the vehicle terminal can obtain the second device tree of the virtual machine by viewing system files (such as the / proc / device-tree directory in the Linux system), using command line tools (such as lspci, lsusb, etc.), or viewing system logs.

[0071] 2. Modify the properties of the power management node in the first device tree so that the virtual monitor captures the power management requests sent by the multiple virtual processors according to the specified trap mechanism.

[0072] Among them, the power management node (PSCI node) in the first device tree represents an interface of the Hypervisor, which allows the virtual machine (or more specifically, the operating system in the virtual machine) to communicate with the virtual monitor (Hypervisor) to perform power management related operations, such as CPU suspension, resumption, shutdown, etc.

[0073] The properties of the power management node are used to define the specific behavior, version, supported calling methods, etc. of the interface. For example, the properties of the power management node include the version of the PSCI interface, the trap mechanism of the PSCI instruction, etc.

[0074] Optionally, the vehicle terminal finds the PSCI node in the first device tree of the virtual monitor, modifies the attributes of the PSCI node, for example, modifies the attributes in the PSCI node or adds / modifies specific version attributes, and specifies the trap mechanism of the PSCI node.

[0075] 3. Modify the properties of the power management node in the second device tree so that the multiple virtual processors send power management requests according to the specified trap mechanism.

[0076] Among them, the power management node in the second device tree represents an interface of the virtual machine, which allows the virtual machine (or more specifically, the operating system in the virtual machine) to communicate with the virtual monitor (Hypervisor) to perform power management related operations, such as CPU suspension, resumption, shutdown, etc.

[0077] Optionally, the vehicle terminal finds the PSCI node in the second device tree of the virtual machine, modifies the attributes of the PSCI node, for example, modifies the attributes in the PSCI node or adds / modifies specific version attributes, and specifies the trap mechanism of the PSCI node.

[0078] Through this embodiment, the properties of the power management nodes in the first device tree and the second device tree are modified so that the virtual monitor captures the power management requests sent by multiple virtual processors according to the specified trap mechanism, so that multiple virtual processors send power management requests according to the specified trap mechanism. Through the above modification, PSCI can trap into the Hypervisor when it is started, thereby realizing multi-core startup of virtual machines based on HVC trap and simulation.

[0079] In an exemplary embodiment, the method for modifying the properties of the power management node in the first device tree and the second device tree is the same, and only the steps of modifying the properties of the power management node in the first device tree are introduced here, which specifically include:

[0080] A power management node is added to the first device tree, a version number used by a power management interface corresponding to the power management node is set, and the power management node is set to capture a power management request according to a specified trap mechanism.

[0081] Optionally, the vehicle terminal uses the following code to modify the properties of the power management node in the first device tree:

[0082] psci{

[0083] compatible="arm,psci-0.2";

[0084] method = "hvc";

[0085] …

[0086] };

[0087] This code means: add a PSCI node to the first device tree of the Hypervisor and set its property to "arm,psci-0.2", indicating that this PSCI interface complies with the ARM version 0.2 specification. At the same time, set the method property to "hvc", indicating that when a PSCI operation needs to be performed, the Hypervisor should be called through the HVC mechanism.

[0088] Through this embodiment, a power management node is added to the first device tree, the version number used by the power management interface corresponding to the power management node is set, and the power management node is set to capture power management requests according to a specified trap mechanism, so that PSCI can trap into the Hypervisor when it starts.

[0089] In an exemplary embodiment, before starting the configured virtual machine, the virtual machine multi-core startup method further includes:

[0090] A simulation code is added in the virtual monitor, wherein the simulation code is used to simulate the response behavior of the power management device to the power management requests sent by the multiple virtual processors.

[0091] The simulation code refers to adding specific code segments in the implementation of the virtual monitor. These code segments are used to simulate the functions of the power management device to monitor and control the power status of the system, such as energy saving mode, sleep, wake-up, etc.

[0092] Alternatively, if Figure 8 As shown, the vehicle terminal adds codes for simulating PSCI related instructions in the virtual monitor to register PSCI and simulate the functions of the power management device to monitor and control the power status of the system.

[0093] Through this embodiment, by adding codes for simulating related functions in the virtual monitor, multi-core startup of virtual machines based on HVC trapping and simulation can be achieved.

[0094] In an exemplary embodiment, before starting the configured virtual machine, the virtual machine multi-core startup method further includes:

[0095] 1. Determine parameter values ​​of calling parameters required for the virtual monitor to simulate the response behavior of the power management device to the power management request.

[0096] The calling parameter refers to the parameter value passed to the function by the virtual monitor when the function is called, which is used to guide the behavior of the function or provide the data required for the function to execute. The parameter value of the calling parameter is defined by the hypervisor's documentation or implementation, and is used to instruct the hypervisor how to respond to a specific power management request. For example, one calling parameter may specify the requested power state (such as CPU_OFF, SUSPEND, etc.), and another calling parameter may contain the necessary context information (such as the CPU identifier or the address of the state save area).

[0097] Optionally, the vehicle terminal determines, based on the Hypervisor's documentation, which parameter values ​​the Hypervisor expects for the power management request, and determines the determined parameter values ​​as the parameter values ​​of the call parameters required for the virtual monitor to simulate the power management device's response behavior to the power management request.

[0098] 2. In the kernel of the virtual machine, determine the calling function used by the virtual machine to start the power management operation, and modify the parameter value of the calling function so that the parameter value of the calling function is consistent with the parameter value of the calling parameter.

[0099] The calling function refers to the function used to initiate a system management call (SMC) in an ARM architecture virtual machine. These calls are usually used to interact with the hypervisor, including power management requests. For example, the calling function may be the arm_smccc_hvc function, which is a standard function used to initiate a system management call in the ARM architecture, allowing the virtual machine kernel to communicate with the hypervisor in a standardized manner.

[0100] To ensure that the power management request of the virtual machine kernel can be correctly understood and responded to by the hypervisor, the parameter values ​​passed when calling the calling function (such as the arm_smccc_hvc function) need to be modified to match the parameter values ​​expected by the hypervisor. The parameter values ​​of the calling function include the function ID (specifies the type of operation to be performed, such as power management), the power state (specifies the requested power state), the context ID (which may contain information about the requester or the address of the state saving area), etc. These parameter values ​​need to be set according to the documentation or requirements of the hypervisor.

[0101] Modifications in the kernel of the virtual machine to support a specific virtualization platform, especially the interaction with PSCI (Power State Coordination Interface) and the hypervisor, involve modifications to the kernel source code and possible compilation. The following is a series of steps to guide you on how to modify the parameters of the arm_smccc_hvc function call during the PSCI boot process in the kernel of the virtual machine to match the parameters required by the hypervisor emulation.

[0102] Optionally, the vehicle terminal finds the calling point of the calling function (such as the arm_smccc_hvc function) in the kernel source code of the virtual machine and understands its context and purpose. At the calling point, the parameter value passed to the calling function is modified to ensure that it is consistent with the parameter value of the calling parameter expected by the Hypervisor.

[0103] Through this embodiment, in the kernel of the virtual machine, the parameter value of the calling function used by the virtual machine to start the power management operation is modified so that the parameter value of the calling function is consistent with the parameter value of the calling parameter expected by the Hypervisor, thereby ensuring the correct interaction between the virtual machine and the Hypervisor, reducing system crashes or instability caused by communication errors or parameter mismatches, and reducing unnecessary resource consumption and delays.

[0104] In an exemplary embodiment, based on the first interaction result and the second interaction result, starting multiple virtual processors of the virtual machine includes:

[0105] When the first interaction result indicates that the multiple virtual processors are in normal state and the second interaction result indicates that the other components are in normal state, the multiple virtual processors of the virtual machine are started.

[0106] Optionally, the vehicle terminal obtains the first interaction result and the second interaction result, verifies the correctness of the first interaction result and the second interaction result, and starts the multiple virtual processors of the virtual machine when both the first interaction result and the second interaction result are correct, that is, when the first interaction result indicates that the multiple virtual processors are in normal state and the second interaction result indicates that the other components are in normal state. When the first interaction result and / or the second interaction result are incorrect, that is, when the first interaction result indicates that the multiple virtual processors are in abnormal state and / or the second interaction result indicates that the other components are in abnormal state, outputs indication information of abnormal startup of multiple virtual processors.

[0107] Through this embodiment, the correctness of the first interaction result (multiple virtual processor states) and the second interaction result (other component states) is verified to ensure that all key components are in a normal state before the virtual machine is started, thereby avoiding virtual machine startup failure or unstable operation due to component failure.

[0108] In a detailed embodiment, a method for starting a multi-core virtual machine includes the following steps:

[0109] 1. Scan the first device tree of the virtual monitor and the second device tree of the virtual machine.

[0110] 2. Add a power management node in the first device tree, set the version number used by the power management interface corresponding to the power management node, and set the power management node to capture power management requests according to the specified trap mechanism.

[0111] 3. Modify the properties of the power management node in the second device tree so that the multiple virtual processors send power management requests according to the specified trap mechanism.

[0112] 4. When the operating system of the virtual machine is initialized, a virtual monitor call bit of a register within the virtual monitor is set so that other components can directly perform hardware interaction with the power management device.

[0113] 5. Add simulation code in the virtual monitor, wherein the simulation code is used to simulate the response behavior of the power management device to the power management requests sent by the multiple virtual processors.

[0114] 6. Determine parameter values ​​of calling parameters required for the virtual monitor to simulate the response behavior of the power management device to the power management request.

[0115] 7. In the kernel of the virtual machine, determine the calling function used by the virtual machine to start the power management operation, and modify the parameter value of the calling function so that the parameter value of the calling function is consistent with the parameter value of the calling parameter.

[0116] 8. Start the configured virtual machine; the virtual machine is configured with multiple virtual processors and other components except the multiple virtual processors.

[0117] 9. Capturing power management requests sent by multiple virtual processors through a specified trap mechanism through a virtual monitor, and simulating a response behavior of a power management device to the power management request through the virtual monitor to obtain a first interaction result.

[0118] 10. Perform hardware interaction directly with the power management device through other components to obtain a second interaction result.

[0119] 11. When the first interaction result indicates that the multiple virtual processors are in a normal state and the second interaction result indicates that the other components are in a normal state, start the multiple virtual processors of the virtual machine.

[0120] 12. When the first interaction result indicates that the states of multiple virtual processors are abnormal or the second interaction result indicates that the states of other components are abnormal, output indication information of abnormal startup of multiple virtual processors.

[0121] Through this embodiment, the virtual machine is allowed to interact directly with the power management device to start devices other than the virtual processor (CPU core), that is, the devices other than the virtual processor in the virtual machine directly interact with the power management device without being simulated by the virtual monitor, and the startup of the virtual processor is trapped in the virtual monitor for simulation through a specified trap mechanism, thereby reducing the simulation amount of the virtual monitor; by separating the startup of the virtual processor from the direct interaction with the power management device, it is possible to effectively avoid conflicts when multiple virtual machines try to interact with the power management device at the same time. The startup of the virtual processor is controlled by the virtual monitor, while the interaction of other devices is carried out directly, which can not only ensure the correct startup of the virtual processor, but also reduce the load and complexity of the virtual monitor.

[0122] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0123] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware server, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM (Read-Only Memory) / RAM (Random Access Memory), a disk, or an optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods of each embodiment of the present application.

[0124] According to another aspect of the embodiments of the present application, a virtual machine multi-core startup device is also provided, which is used to implement the virtual machine multi-core startup method provided in the above embodiments, and will not be repeated hereafter. As used below, the term "module" can implement a combination of software and / or hardware for a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0125] Fig. 9 is a structural block diagram of an optional virtual machine multi-core startup device according to an embodiment of the present application, such as Fig. 9 As shown, the device may include:

[0126] Configuration startup module 901, used to start the configured virtual machine; the virtual machine is configured with multiple virtual processors and other components except the multiple virtual processors;

[0127] The simulation module 902 is used to capture the power management requests sent by multiple virtual processors through the specified trap mechanism through the virtual monitor, and simulate the response behavior of the power management device to the power management request through the virtual monitor to obtain a first interaction result;

[0128] The hardware interaction module 903 is used to directly perform hardware interaction with the power management device through other components to obtain a second interaction result;

[0129] The multi-core startup module 904 is used to start multiple virtual processors of the virtual machine based on the first interaction result and the second interaction result.

[0130] In an exemplary embodiment, before starting the configured virtual machine, the startup module 901 is configured to set the virtual monitor call bit of the register within the virtual monitor when the operating system of the virtual machine is initialized, so that other components can directly interact with the power management device through hardware.

[0131] In an exemplary embodiment, before starting a configured virtual machine, a startup module 901 is configured to scan a first device tree of a virtual monitor and a second device tree of a virtual machine; modify properties of a power management node in the first device tree so that the virtual monitor captures power management requests sent by multiple virtual processors according to a specified trap mechanism; and modify properties of a power management node in the second device tree so that multiple virtual processors send power management requests according to a specified trap mechanism.

[0132] In an exemplary embodiment, the configuration startup module 901 is also used to add a power management node in the first device tree, set the version number used by the power management interface corresponding to the power management node, and set the power management node to capture power management requests according to a specified trap mechanism.

[0133] In an exemplary embodiment, before starting the configured virtual machine, the startup module 901 is configured to add simulation code in the virtual monitor, wherein the simulation code is used to simulate the response behavior of the power management device to the power management requests sent by multiple virtual processors.

[0134] In an exemplary embodiment, before starting a configured virtual machine, a startup module 901 is configured to determine the parameter values ​​of the calling parameters required for the virtual monitor to simulate the response behavior of the power management device to the power management request; in the kernel of the virtual machine, the calling function used by the virtual machine to start the power management operation is determined, and the parameter value of the calling function is modified to make the parameter value of the calling function consistent with the parameter value of the calling parameter.

[0135] In an exemplary embodiment, the multi-core startup module 904 is further configured to start multiple virtual processors of the virtual machine when the first interaction result indicates that the multiple virtual processors are in normal state and the second interaction result indicates that the other components are in normal state.

[0136] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the contents disclosed in the above embodiments. It should be noted that the above modules as part of the device can be run in Figure 1 In the hardware environment shown, it can be implemented by software or by hardware, wherein the hardware environment includes a network environment.

[0137] According to another aspect of the embodiments of the present application, a storage medium is further provided. Optionally, in this embodiment, the storage medium can be used to execute the program code of any of the above-mentioned virtual machine multi-core startup methods in the embodiments of the present application.

[0138] Optionally, in this embodiment, the storage medium may be located on at least one network device among a plurality of network devices in the network shown in the above embodiment.

[0139] Optionally, in this embodiment, the storage medium is configured to store a program code for executing any of the above-mentioned virtual machine multi-core startup methods.

[0140] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, which will not be described in detail in this embodiment.

[0141] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media that can store program codes, such as a USB flash drive, a ROM, a RAM, a mobile hard disk, a magnetic disk, or an optical disk.

[0142] According to another aspect of an embodiment of the present application, an electronic device for implementing the above-mentioned virtual machine multi-core startup method is also provided. The electronic device may be a smart device, a server, a terminal, or a combination thereof.

[0143] Fig.10 is a structural block diagram of an optional electronic device according to an embodiment of the present application, such as Fig.10 As shown, it includes a processor 1002, a communication interface 1004, a memory 1006 and a communication bus 1008, wherein the processor 1002, the communication interface 1004 and the memory 1006 communicate with each other through the communication bus 1008, wherein the memory 1006 is used to store computer programs; the processor 1002 is used to implement the program code of any of the above-mentioned virtual machine multi-core startup methods when executing the computer program stored in the memory 1006.

[0144] Optionally, the communication bus may be a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.10 The communication interface is used for communication between the above electronic device and other devices.

[0145] The memory may include RAM, or may include non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0146] As an example, the memory 1006 may include but is not limited to each module in the multi-core startup device for a virtual machine. In addition, it may also include but is not limited to other module units in the multi-core startup device for a virtual machine, which will not be described in detail in this example.

[0147] The above-mentioned processor can be a general-purpose processor, which can include but not be limited to: CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be DSP (Digital Signal Processing), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0148] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, and this embodiment will not be described in detail here.

[0149] It can be understood by those skilled in the art that Fig.10 The structure shown is for illustration only. The device for implementing the above-mentioned virtual machine multi-core startup method can be a terminal device, which can be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile Internet device (Mobile Internet Devices, MID), a PAD, and other terminal devices. Fig.10 The structure of the electronic device is not limited. Fig.10 More or fewer components (such as network interfaces, display devices, etc.) shown in, or having Fig.10 Different configurations shown.

[0150] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0151] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0152] The embodiments of the present application also provide a computer program, which includes computer instructions, which are stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the steps in any one of the above method embodiments.

[0153] A person of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, which can include: a flash drive, ROM, RAM, a magnetic disk or an optical disk, etc.

[0154] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0155] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.

[0156] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0157] In the several embodiments provided in the present application, it should be understood that the disclosed client can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0158] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution provided in this embodiment.

[0159] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, each unit may exist physically separately, or at least two units may be integrated into one unit. The above integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0160] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for starting a multi-core virtual machine, characterized in that: include: Start the configured virtual machine; The virtual machine is configured with a plurality of virtual processors and other components except the plurality of virtual processors; Capturing, by means of a virtual monitor, power management requests sent by the plurality of virtual processors through a specified trap mechanism, and simulating, by means of the virtual monitor, a response behavior of a power management device to the power management request, to obtain a first interaction result; Performing hardware interaction directly with the power management device through the other components to obtain a second interaction result; Based on the first interaction result and the second interaction result, the multiple virtual processors of the virtual machine are started.

2. The method according to claim 1, characterized in that Before starting the configured virtual machine, the method further includes: When the operating system of the virtual machine is initialized, the virtual monitor call bit of the register in the virtual monitor is set so that the other components directly perform hardware interaction with the power management device.

3. The method according to claim 1, characterized in that Before starting the configured virtual machine, the method further includes: Scanning a first device tree of the virtual monitor and a second device tree of the virtual machine; Modify the properties of the power management node in the first device tree so that the virtual monitor captures the power management requests sent by the multiple virtual processors according to the specified trap mechanism; Modify the properties of the power management node in the second device tree so that the multiple virtual processors send the power management request according to the specified trap mechanism.

4. The method according to claim 3, characterized in that The modifying the property of the power management node in the first device tree includes: A power management node is added to the first device tree, a version number used by a power management interface corresponding to the power management node is set, and the power management node is set to capture the power management request according to the specified trap mechanism.

5. The method according to claim 1, characterized in that Before starting the configured virtual machine, the method further includes: A simulation code is added in the virtual monitor, wherein the simulation code is used to simulate the response behavior of the power management device to the power management requests sent by the multiple virtual processors.

6. The method according to claim 1, characterized in that Before starting the configured virtual machine, the method further includes: Determining parameter values ​​of call parameters required for the virtual monitor to simulate a response behavior of the power management device to the power management request; In the kernel of the virtual machine, a calling function used by the virtual machine to start a power management operation is determined, and a parameter value of the calling function is modified so that the parameter value of the calling function is consistent with the parameter value of the calling parameter.

7. The method according to any one of claims 1 to 6, characterized in that The step of starting the multiple virtual processors of the virtual machine based on the first interaction result and the second interaction result includes: When the first interaction result indicates that the multiple virtual processors are in a normal state and the second interaction result indicates that the other components are in a normal state, the multiple virtual processors of the virtual machine are started.

8. A multi-core startup device for a virtual machine, characterized in that: include: Configure the startup module to start the configured virtual machine; The virtual machine is configured with a plurality of virtual processors and other components except the plurality of virtual processors; A simulation module, configured to capture, through a virtual monitor, power management requests sent by the plurality of virtual processors through a specified trap mechanism, and simulate, through the virtual monitor, a response behavior of a power management device to the power management request to obtain a first interaction result; A hardware interaction module, used to directly perform hardware interaction with the power management device through the other components to obtain a second interaction result; A multi-core startup module is used to start the multiple virtual processors of the virtual machine based on the first interaction result and the second interaction result.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program implements the steps of any one of the methods of claims 1 to 7 when executed by a processor.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

Images