Handling method for virtual-machine crash event, and device and storage medium

Abstract

Provided in the present application are a handling method for a virtual-machine crash event, and a device and a storage medium. In the method, when a crash event has occurred in a second virtual machine oriented to a hardware layer of an electronic device, a first virtual machine that has not experienced a crash event and carries an operating system temporarily takes over resources occupied by the second virtual machine, and the second virtual machine is individually restarted; and after the second virtual machine is restarted, the resources of the second virtual machine that have been taken over by the first virtual machine are returned to the second virtual machine. In this way, only a second virtual machine that experienced a crash event is self-recovered, without triggering the restarting of the whole electronic device, thereby reducing the perception of a user, and improving the usage experience of the user.

Description

Method, device and storage medium for processing virtual machine crash events

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on November 7, 2023, with application number 202311479735.2 and invention name “Method, device and storage medium for handling virtual machine crash events”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of virtualization technology, and in particular to a method, device, and storage medium for processing a virtual machine crash event. Background Art

[0003] With the increasing application of virtualization technology, the system on chip (SOC) architecture used in current electronic devices has made extensive use of virtual machine architecture. This not only isolates business scenarios but also facilitates decoupling. However, it can also cause the entire electronic device to malfunction due to the crash of the virtual machine.

[0004] Currently, virtual machine crashes are typically handled by forcing the entire device to restart, restoring normal operation. However, this forced restart causes the device to go black, reappearing the startup screen before entering the operating system and displaying the desktop. This not only slows down the process but also impacts the user experience.

[0005] Summary of the Invention

[0006] In order to solve the above technical problems, the present application provides a method, device and storage medium for handling virtual machine crash events, aiming that when a crash event occurs in a hardware layer virtual machine, a virtual machine that has not experienced a crash event and hosts an operating system will assist the virtual machine that has experienced a crash event to recover to normal without triggering a restart of the entire machine, thereby reducing user perception and improving user experience.

[0007] In a first aspect, the present application provides a method for handling a virtual machine crash event, which is applied to an electronic device. A first virtual machine and a second virtual machine are running on the electronic device, where the first virtual machine is a virtual machine that hosts the operating system of the electronic device, and the second virtual machine is a virtual machine that is oriented to the hardware layer of the electronic device. The method includes: in response to a crash event of the second virtual machine, releasing the first resource occupied by the second virtual machine, and having the first virtual machine take over the first resource; reallocating memory resources to the second virtual machine and restarting the second virtual machine; after the second virtual machine successfully restarts, releasing the first resource taken over by the first virtual machine; after the second virtual machine obtains the first resource, re-establishing the service link between the second virtual machine and the service responsible for the second virtual machine, and restoring the processing capability of the service.

[0008] Taking the operating system of the electronic device as the Android system as an example, the first virtual machine is a virtual machine that carries the Android system. In some implementations, it can be called a primary virtual machine (PVM), which can be responsible for most of the business processing logic of the Android system.

[0009] Among them, the second virtual machine facing the hardware layer can be described as a hardware layer virtual machine in some implementation methods, such as the hardware layer virtual machine A listed in this application, which is responsible for fingerprint, face, gesture and other recognition and processing services; for example, the hardware layer virtual machine B listed in this application, which is responsible for electronic identity identification, mobile POS (Point of sales) and other services; for example, the hardware layer virtual machine C listed in this application, which is responsible for the system reliability of the central processing unit (CPU) of the electronic device.

[0010] The crash event of the second virtual machine is specifically a common crash (crash / flash back) problem in Android.

[0011] Among them, sensing the crash of the second virtual machine, notifying the second virtual machine to release the first resource, the first virtual machine taking over the first resource, and reallocating memory resources to the second virtual machine to trigger the restart of the second virtual machine can be implemented by the virtual machine management service (Hyper-V).

[0012] The virtual machine management service is a tool that can be used to create virtual machines, shut down virtual machines, start virtual machines, and migrate virtual machines.

[0013] Therefore, when the second virtual machine crashes, the first virtual machine, which has not crashed and is hosting the operating system, temporarily takes over the resources occupied by the second virtual machine and restarts the second virtual machine separately. After the second virtual machine restarts, the resources of the second virtual machine taken over by the first virtual machine are returned to the second virtual machine. In this way, only the second virtual machine that crashed is self-recovered, and the entire electronic device is not triggered to restart, thereby reducing user perception and improving the user experience.

[0014] According to the first aspect, releasing the first resource occupied by the second virtual machine includes: closing the input and output IO resources and interrupt resources of the first driver, which is the driver to be called by the second virtual machine when processing business; and clearing the contents of the queues corresponding to the IO resources and interrupt resources.

[0015] The first driver is related to the second virtual machine where the crash occurs.

[0016] For example, when the second virtual machine where the crash occurs is a virtual machine responsible for fingerprint, face, gesture and other recognition and processing services, the first driver may include a touch driver, a display driver, a camera driver and the like.

[0017] Therefore, when the second virtual machine crashes, the IO resources and interrupt resources of each driver called by the second virtual machine are closed, and the contents of the queues corresponding to the IO resources and interrupt resources are cleared, thereby releasing the first resources occupied by the second virtual machine, avoiding memory leaks, and further causing performance degradation or even crashes of other virtual machines that have not crashed.

[0018] According to the first aspect, or any implementation method of the above first aspect, clearing the contents in the queues corresponding to the IO resources and interrupt resources includes: clearing the events in the first-in-first-out queues corresponding to the IO resources and interrupt resources, and clearing the messages in the message queues corresponding to the IO resources and interrupt resources.

[0019] In this way, various resources occupied by the second virtual machine are released.

[0020] According to the first aspect, or any implementation of the first aspect above, after clearing the contents in the queues corresponding to the IO resources and the interrupt resources, the method further includes: reclaiming the memory resources occupied by the second virtual machine.

[0021] Therefore, by reclaiming the memory resources occupied by the second virtual machine, memory pressure is relieved, thereby ensuring the normal operation of other virtual machines and programs and the normal processing of services.

[0022] According to the first aspect, or any implementation of the first aspect above, the method further includes: the first virtual machine taking over the reclaimed memory resources.

[0023] According to the first aspect, or any implementation method of the above first aspect, reallocating memory resources for the second virtual machine and restarting the second virtual machine include: reallocating memory resources for the second virtual machine and re-establishing the mapping between the second virtual machine and the memory resources; calling the second driver to load the image of the second virtual machine; and restarting the operating system running on the second virtual machine.

[0024] Thus, the second virtual machine that crashed is restarted.

[0025] According to the first aspect, or any implementation of the first aspect above, in response to a crash event of the second virtual machine, the method further includes: obtaining data in the memory resources corresponding to the second virtual machine, and dumping the data to a storage medium of the electronic device.

[0026] When the second virtual machine crashes, the data in the memory resources corresponding to the second virtual machine obtained are dynamic or volatile data, that is, data that will be lost after use or when an exception occurs.

[0027] Dump refers to converting dynamic data in memory resources into a static form, such as dumping into a file (hereinafter referred to as a dump file), which is then stored in a storage medium of an electronic device.

[0028] The storage medium may be an internal memory of the electronic device or a connected external memory.

[0029] Therefore, when the second virtual machine crashes, by collecting and dumping data related to the second virtual machine, it is convenient to locate the problem later according to the dump file in the storage medium.

[0030] According to the first aspect, or any implementation of the first aspect above, the method also includes: in the process of creating the first virtual machine and the second virtual machine, configuring monitoring for the first virtual machine and the second virtual machine; using monitoring to collect system event information of the first virtual machine and the second virtual machine, the system event information including an event type; when the event type indicates that the system event currently occurring in the second virtual machine is a crash event, executing steps in response to the crash event occurring in the second virtual machine.

[0031] The creation of the first virtual machine and the second virtual machine is achieved, for example, through a virtual machine management service (Hyper-V).

[0032] The configuration of monitoring, interaction with the created first virtual machine and second virtual machine, acquisition of system event information collected by monitoring, and determination of whether a crash event occurs are all implemented by the virtual machine management service.

[0033] According to the first aspect, or any implementation of the first aspect above, the method further includes: when the event type indicates that the system event currently occurring in the first virtual machine is a crash event, in response to the crash event occurring in the first virtual machine, restarting the entire electronic device.

[0034] A full reboot specifically refers to an operating system-level reboot, meaning it directly restarts the operating system or reloads the kernel without repowering the device. Because the operating system or kernel needs to be restarted, the screen goes black, the reboot animation appears, and the system boots back into place.

[0035] According to the first aspect, or any implementation method of the first aspect above, when the event type indicates that the current system event occurring in the first virtual machine is a crash event, the entire electronic device is restarted in response to the crash event occurring in the first virtual machine, including: when the crash event is a panic exception, the entire electronic device is restarted in response to the crash event occurring in the first virtual machine.

[0036] A panic is a type of error handling that indicates an unhandled error has occurred, preventing the program from continuing. A panic forces the program to stop running, and developers must handle it effectively. Otherwise, the program may crash and disrupt normal business processes.

[0037] Because the first VM hosts most of the Android system's business logic, a full machine restart is required to restore normal Android system operation if the first VM panics. Other types of anomalies, such as Bluetooth or cellular network issues, can be recovered by restarting the function in question, without requiring a full machine restart.

[0038] Therefore, only when a panic occurs in the first virtual machine is the electronic device controlled to restart the entire machine, which greatly reduces the probability of the entire machine restarting.

[0039] In a second aspect, the present application provides an electronic device. The electronic device includes: a memory and a processor, the memory and the processor being coupled; the memory storing program instructions, which, when executed by the processor, cause the electronic device to execute instructions of the method of the first aspect or any possible implementation of the first aspect.

[0040] The second aspect and any implementation of the second aspect correspond to the first aspect and any implementation of the first aspect, respectively. The technical effects corresponding to the second aspect and any implementation of the second aspect can be referred to the technical effects corresponding to the first aspect and any implementation of the first aspect, and will not be repeated here.

[0041] In a third aspect, the present application provides a computer-readable medium for storing a computer program, wherein the computer program includes instructions for executing the method in the first aspect or any possible implementation of the first aspect.

[0042] The third aspect and any implementation of the third aspect correspond to the first aspect and any implementation of the first aspect, respectively. The technical effects corresponding to the third aspect and any implementation of the third aspect can be referred to the technical effects corresponding to the first aspect and any implementation of the first aspect, and will not be repeated here.

[0043] In a fourth aspect, the present application provides a computer program comprising instructions for executing the method in the first aspect or any possible implementation of the first aspect.

[0044] The fourth aspect and any implementation of the fourth aspect correspond to the first aspect and any implementation of the first aspect, respectively. The technical effects corresponding to the fourth aspect and any implementation of the fourth aspect can be referred to the technical effects corresponding to the first aspect and any implementation of the first aspect, and will not be repeated here.

[0045] In a fifth aspect, the present application provides a chip comprising a processing circuit and a transceiver pin. The transceiver pin and the processing circuit communicate with each other via an internal connection path, and the processing circuit executes the method of the first aspect or any possible implementation of the first aspect to control the receive pin to receive a signal and to control the transmit pin to send a signal.

[0046] The fifth aspect and any implementation of the fifth aspect correspond to the first aspect and any implementation of the first aspect, respectively. The technical effects corresponding to the fifth aspect and any implementation of the fifth aspect can be referred to the technical effects corresponding to the first aspect and any implementation of the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] FIG1 is a schematic diagram showing a hardware structure of an electronic device;

[0048] FIG2 is a schematic diagram illustrating a software structure of an electronic device;

[0049] FIG3 is a schematic diagram illustrating virtual machines running on a system on a chip in an electronic device, services handled by each virtual machine, and operations after a crash event occurs;

[0050] 4A and 4B are schematic diagrams illustrating interface changes when a virtual machine crashes and the entire machine is restarted;

[0051] FIG5 is a schematic diagram illustrating, by way of example, the operations of virtual machines running on a system-on-chip in an electronic device and the services managed by each virtual machine after a crash event occurs, after the self-recovery logic of the method for handling a virtual machine crash event provided by an embodiment of the present application is deployed;

[0052] FIG6 is a flow chart illustrating a method for handling a virtual machine crash event according to an embodiment of the present application;

[0053] FIG7 is a flow chart illustrating another method for handling a virtual machine crash event provided in an embodiment of the present application. DETAILED DESCRIPTION

[0054] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0055] The term "and / or" in this article is merely a description of the association relationship between associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0056] In the description and claims of the embodiments of this application, the terms "first" and "second" are used to distinguish different objects, rather than to describe a specific order of objects. For example, the terms "first target object" and "second target object" are used to distinguish different objects, rather than to describe a specific order of objects.

[0057] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0058] In the description of the embodiments of this application, unless otherwise specified, "multiple" means two or more. For example, "multiple processing units" means two or more processing units; "multiple systems" means two or more systems.

[0059] To better understand the technical solutions provided by the embodiments of the present application, before describing the technical solutions of the embodiments of the present application, the hardware structure of the electronic devices (such as mobile phones, tablet computers, smart wearable devices, etc.) to which the embodiments of the present application are applicable is first described in conjunction with the accompanying drawings. For ease of explanation, Figure 1 takes a mobile phone as an example for description.

[0060] 1 , the mobile phone 100 may include: a system on chip (SOC) 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0061] Understandably, SOC 110 can also be referred to as a system-on-chip, which is a miniature system. Specifically in practical applications, SOC 110 may include one or more processing units. For example, an application processor (AP), a modem processor (Modem), a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc., which are not listed here one by one and are not limited in this application.

[0062] Regarding the SOC 110 including the above-mentioned processing units, in some implementations, the different processing units may be independent devices. That is, each processing unit may be considered a processor. In other implementations, the different processing units may also be integrated into one or more processors.

[0063] It should be understood that the above description is merely an example listed for a better understanding of the technical solution of this embodiment, and is not intended to be the sole limitation on this embodiment.

[0064] In addition, the SOC 110 may further include one or more interfaces. The interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc. These interfaces are not listed here one by one and are not limited in this application.

[0065] In addition, SOC 110 may also include a memory for storing instructions and data. In some implementations, the memory in SOC 110 is a cache memory. This memory can store instructions and data that have just been used or are being recycled by SOC 110. Thus, if SOC 110 needs to use these instructions or data again, it can directly call them from this memory. This avoids repeated access to storage media, such as internal memory 121 or an external memory card, reduces SOC 110 latency, and improves system efficiency.

[0066] The external memory interface 120 can be used to connect an external memory card, such as a MicroSD card, to expand the storage capacity of the mobile phone 100. The external memory card communicates with the SOC 110 through the external memory interface 120 to implement data storage function.

[0067] Specifically, in the technical solution provided in the embodiment of the present application, when a virtual machine at the hardware layer of an electronic device crashes, the dump file collected and dumped by the virtual machine management service can be stored in the external memory card connected to the external memory interface 120.

[0068] The internal memory 121 can be used to store computer executable program code, which includes instructions. The SOC 110 executes various functional applications and data processing of the mobile phone 100 by running the instructions stored in the internal memory 121. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area can store an operating system (such as an Android system) and an application required for at least one function (such as programs corresponding to fingerprint recognition, gesture recognition, face recognition, etc.). The data storage area can store data created during the use of the mobile phone 100, etc.

[0069] Specifically, in the technical solution provided in the embodiment of the present application, when a crash occurs in the virtual machine at the hardware layer of the electronic device, the dump file collected and dumped by the virtual machine management service can be stored in the storage data area of ​​the internal memory 121.

[0070] In addition, the internal memory 121 may include a high-speed random access memory and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0071] The charging management module 140 is configured to receive charging input from a charger. The charger can be either a wireless charger or a wired charger. In some wired charging implementations, the charging management module 140 can receive charging input from the wired charger via the USB interface 130. In some wireless charging implementations, the charging management module 140 can receive wireless charging input via the wireless charging coil of the mobile phone 100. While charging the battery 142, the charging management module 140 can also power the electronic device through the power management module 141.

[0072] The power management module 141 is used to connect the battery 142, the charging management module 140, and the SOC 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 and provides power to the SOC 110, the internal memory 121, the external memory, the display 194, the camera 193, the wireless communication module 160, and the like. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage, impedance). In some other implementations, the power management module 141 can also be provided in the SOC 110. In other implementations, the power management module 141 and the charging management module 140 can also be provided in the same device.

[0073] The wireless communication function of the mobile phone 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

[0074] It should be noted that antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in mobile phone 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other implementations, the antennas can be used in conjunction with a tuning switch.

[0075] The mobile communication module 150 can provide wireless communication solutions including 2G / 3G / 4G / 5G applied on the mobile phone 100.

[0076] The wireless communication module 160 can provide wireless communication solutions for application on the mobile phone 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) network), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication technology (NFC), infrared technology (IR), etc.

[0077] The audio module 170 may include a speaker 170A, a receiver 170B, a microphone 170C, an earphone jack 170D, and the like.

[0078] The sensor module 180 may include a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, etc., which are not listed here one by one and are not limited in this application.

[0079] Keys 190 include a power button, a volume button, and the like. Keys 190 may be mechanical keys or touch-sensitive keys. Mobile phone 100 may receive key inputs and generate key signal inputs related to user settings and function control of mobile phone 100.

[0080] Motor 191 can generate vibration prompts. Motor 191 can be used for incoming call vibration prompts and can also be used for touch vibration feedback.

[0081] The indicator 192 may be an indicator light, which may be used to indicate the charging status, power level changes, messages, missed calls, notifications, etc.

[0082] The camera 193 is used to capture still images or videos. In some implementations, the mobile phone 100 may include 1 or N cameras 193, where N is a positive integer greater than 1.

[0083] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. In some implementations, the mobile phone 100 may include one or N display screens 194, where N is a positive integer greater than one.

[0084] This concludes the introduction to the hardware structure of mobile phone 100. It should be understood that the mobile phone 100 shown in FIG1 is merely an example. In a specific implementation, mobile phone 100 may have more or fewer components than shown, may combine two or more components, or may have a different component configuration. The various components shown in FIG1 may be implemented in hardware, including one or more signal processing and / or application-specific integrated circuits, software, or a combination of hardware and software.

[0085] With the increasing application of virtualization technology, a large number of virtual machines are running in the SOCs used in current electronic devices, such as the virtual machine that carries the operating system of the electronic device (referred to as the first virtual machine for ease of distinction) and the virtual machine facing the hardware layer (referred to as the second virtual machine for ease of distinction).

[0086] In order to better understand the software structure of the electronic device of this structure, an electronic device such as a mobile phone is still taken as an example and explained in conjunction with FIG2 .

[0087] Before describing the software structure of the mobile phone 100 , the architecture that can be adopted by the software system of the mobile phone 100 will be described first.

[0088] Specifically, in actual applications, the software system of the mobile phone 100 may adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture.

[0089] In addition, it is understandable that the software systems used by current mainstream electronic devices include but are not limited to Windows systems, Android systems, and iOS systems. For ease of explanation, the embodiment of the present application takes the layered architecture Android system as an example to exemplify the software structure of the mobile phone 100.

[0090] In addition, the subsequent method for handling virtual machine crash events provided in the embodiments of the present application is also applicable to other systems in specific implementations.

[0091] See FIG2 , which is a software structure block diagram of the mobile phone 100 according to an embodiment of the present application.

[0092] As shown in Figure 2, the layered architecture of the mobile phone 100 divides the software into several layers, each with a clear role and division of labor. The layers communicate with each other through software interfaces. In some implementations, the Android system is divided into five layers, from top to bottom: the application layer (Application Layer, APP layer, also known as: application layer), the application framework layer (Application Framework Layer, FWK layer, also known as: framework layer), the Android runtime (Android Runtime) and system library, the hardware abstraction layer (HAL layer) and the kernel layer (Linux Kernel Layer, Linux kernel layer, also known as: Linux kernel).

[0093] The application layer may include a series of application packages. As shown in FIG2 , the application package may include camera, game, video, live broadcast and other applications, which are not listed here one by one and are not limited in this application.

[0094] The framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. In some implementations, these programming interfaces and programming frameworks can be described as functions (or services or functional modules). As shown in Figure 2, the framework layer may include functions such as a content provider, a window manager, a resource manager, and a phone manager. These functions are not listed here and are not limited in this application.

[0095] The Android Runtime includes the core library and the virtual machine. The Android Runtime is responsible for scheduling and management of the Android system.

[0096] The core library consists of two parts: one is the function that needs to be called by the Java language, and the other is the Android core library.

[0097] The application layer and application framework layer run in a virtual machine. The virtual machine executes Java files in the application layer and application framework layer as binary files. The virtual machine manages object lifecycles, stack management, thread management, security and exception management, and garbage collection.

[0098] The virtual machines shown in FIG. 2 may be a first virtual machine and a second virtual machine running in a SOC.

[0099] The system library can include multiple functional modules, such as a surface manager, media libraries, a 3D graphics processing library (e.g., OpenGL ES), and a 2D graphics engine (e.g., SGL).

[0100] The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications.

[0101] The media library supports playback and recording of a variety of common audio and video formats, as well as static image files. The media library can support a variety of audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0102] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0103] It can be understood that the 2D graphics engine mentioned above is a drawing engine for 2D drawing.

[0104] Among them, the hardware abstraction layer is used to encapsulate the hardware driver and provide a unified interface to the upper-level framework.

[0105] Among them, the Linux kernel layer is the layer between hardware and software, including various processes, threads, power management, and various hardware drivers, such as sensor drivers, display drivers, microphone drivers, WLAN drivers, camera drivers, etc.

[0106] This concludes the introduction to the software structure of the mobile phone 100. It should be understood that the layers in the software structure shown in FIG2 and the components contained in each layer do not constitute a specific limitation on the mobile phone 100. In other embodiments of the present application, the mobile phone 100 may include more or fewer layers than shown, and each layer may include more or fewer components, and this application does not impose any limitations thereon.

[0107] Each virtual machine running in the SoC is assigned its own set of virtual hardware resources, so the functions, logic, and services of each virtual machine are isolated from each other.

[0108] That is to say, by running virtual machines (a first virtual machine and a second virtual machine) in the SOC, it is possible to isolate business scenarios and facilitate decoupling.

[0109] It should be noted that, generally, there is only one first virtual machine that carries the operating system of the electronic device, such as most of the business logic of the Android system. In a possible implementation, the first virtual machine is, for example, a primary virtual machine (PVM), as shown in FIG3 .

[0110] Exemplarily, the PVM mainly runs the Android system and is therefore responsible for most of the logic of the Android system, which includes logic from the underlying Linux kernel to the upper application layer.

[0111] It's important to note that for most of the Android system logic managed by the PVM, any anomalies can be resolved by individually restarting the program for that function. For example, if a Bluetooth anomaly occurs, it can be restored by turning it off and then back on again. This means that the issue can be resolved without requiring a full device reboot. A full device reboot is only necessary if a panic occurs.

[0112] A panic is a way of handling errors. It indicates that an unhandled error has occurred, preventing the program from continuing. For example, attempting to access a null pointer will result in a panic error. A panic error forces the program to stop running. If left unhandled, the program may crash and disrupt normal business processes.

[0113] The second virtual machine for the hardware layer of the electronic device can be divided into multiple virtual machines based on the functions to be implemented and the services it is responsible for. For ease of illustration, let's take the example of three second virtual machines included in the SOC. These three second virtual machines can be described as hardware layer virtual machine A, hardware layer virtual machine B, and hardware layer virtual machine C.

[0114] As shown in Figure 3, hardware-layer virtual machine A can be responsible for fingerprint, face, and gesture recognition services. Hardware-layer virtual machine B can be responsible for electronic ID (eID) and mobile POS services. Hardware-layer virtual machine C can be responsible for CPU system reliability services.

[0115] Therefore, by running PVM, hardware layer virtual machine A, hardware layer virtual machine B and hardware layer virtual machine C in the SOC, not only can the business scenarios be isolated, but also decoupling can be facilitated.

[0116] However, problems such as misoperation, insufficient resources, and malicious access may cause the virtual machine to crash, which in turn may cause the entire electronic device to malfunction and panic.

[0117] Currently, for chip platforms that provide SOCs, virtual machine crashes are typically handled by forcing a full reboot to restore normal operation. As shown in Figure 3, if the PVM crash is a panic or issue, the phone will reboot. If any of the hardware-layer virtual machines (VMs A, B, or C) crash, the phone will reboot.

[0118] Referring to (1) in FIG. 4A , for example, in one possible implementation, when a user clicks on the icon of the gallery application displayed in interface 10a , the mobile phone can jump to interface 10b shown in (2) in FIG. 4A in response to the operation.

[0119] For example, when the user is browsing the pictures displayed in the interface 10b, the mobile phone may crash the first virtual machine or the second virtual machine due to insufficient resources or user error. Based on the existing virtual machine crash event processing strategy, the mobile phone will directly restart the entire machine.

[0120] It should be noted that the whole machine restart mentioned in each embodiment of the present application is specifically a restart at the operating system level of the electronic device, that is, a restart method that directly restarts the operating system or reloads the system kernel without re-powering on. Therefore, after the virtual machine crashes, the mobile phone directly restarts the whole machine. During the process of restarting the operating system or the system kernel, the interface of the mobile phone will change from the interface 10b shown in (2) of Figure 4A to the interface 10c shown in (1) of Figure 4B, that is, a black screen. In addition, as time goes by, the corresponding restart screen can also be displayed in this process. For example, in a possible implementation method, the interface of the mobile phone will change from the interface 10c shown in (1) of Figure 4B to the interface 10d shown in (2) of Figure 4B. After the operating system of the mobile phone is successfully started, the mobile phone desktop will be displayed, such as the interface 10a shown in (1) of Figure 4A.

[0121] That is to say, in the process of restoring the electronic device to normal use by forcing the entire device to restart, the interface of the electronic device will change from interface 10b shown in (2) of FIG. 4A , to interface 10c shown in (1) of FIG. 4B , to interface 10d shown in (2) of FIG. 4B , and finally to interface 10a shown in (1) of FIG. 4A .

[0122] It should be understood that the above description is merely an example listed for a better understanding of the technical solution of this embodiment, and is not intended to be the sole limitation on this embodiment.

[0123] While this forced full reboot can help a crashed virtual machine recover, it will cause the phone screen to go black, reappearing the startup screen before entering the operating system and displaying the desktop. This not only slows down processing speed but also impacts the user experience.

[0124] In light of this, an embodiment of the present application provides a method for handling virtual machine crashes, aiming to deploy self-recovery logic for a second virtual machine, as shown in Figure 5. When a second virtual machine crashes, the first virtual machine, which has not crashed and is hosting the operating system, assists the crashed second virtual machine in recovering to normal, based on this self-recovery logic. This allows only the virtual machine responsible for a portion of the electronic device's operations to be restarted without triggering a full machine restart, thereby minimizing user perception and improving the user experience.

[0125] Regarding the self-recovery logic mentioned above, it can be divided into electronic devices for user use (hereinafter referred to as: commercial machines) and electronic devices used in the research and development stage (hereinafter referred to as: internal test machines).

[0126] Specifically, considering user privacy issues, the self-recovery logic of commercial machines may not involve the collection and storage of log information when a crash occurs; while internal test machines need to be designed to collect and store log information so that R&D personnel can locate and solve problems based on the data obtained from the memory when a crash occurs.

[0127] The following describes the process of a method for handling a virtual machine crash event based on the self-recovery logic deployed in these two types of electronic devices with reference to the accompanying drawings.

[0128] 6 , which exemplifies a method for handling a virtual machine crash event applied to a commercial machine, specifically comprising:

[0129] 101. The virtual machine management service notifies the hardware layer virtual machine where the crash occurs to process the current resources.

[0130] Specifically, the virtual machine management service in this embodiment is Hyper-V, which can be used to create a virtual machine, shut down a virtual machine, start a virtual machine, and perform migration operations on a virtual machine.

[0131] That is, during the startup of the electronic device, the virtual machine management service creates each virtual machine that can run in the SOC. Specifically, in the embodiment of the present application, it is responsible for hosting the first virtual machine of the operating system, such as the Android system, and each second virtual machine facing the hardware layer.

[0132] For ease of explanation, this embodiment still takes the first virtual machine as the primary virtual machine (PVM) physical shown in Figures 3 and 5, and the second virtual machine includes the hardware layer virtual machine A, hardware layer virtual machine B and hardware layer virtual machine C shown in Figures 3 and 5 as an example.

[0133] For example, for a SOC with this architecture, the virtual machine service first creates a PVM, hardware-layer virtual machine A, hardware-layer virtual machine B, and hardware-layer virtual machine C, and configures listeners for these virtual machines. Thus, while these virtual machines are operating, the virtual machine management service can use the configured listeners to collect system event information from the PVM, hardware-layer virtual machine A, hardware-layer virtual machine B, and hardware-layer virtual machine C.

[0134] It should be noted that, in this embodiment, the system event information includes the type of the currently occurring event, wherein the event type can identify what type of event the currently occurring system event is.

[0135] In addition, the system event information can also carry the source, that is, which virtual machine it came from. In this way, based on the event type in the system event information, it is possible to determine which virtual machine has crashed.

[0136] Furthermore, the virtual machine management service can act as a virtual machine manager, responsible for interacting with each virtual machine. Therefore, when the virtual machine management service uses the system event information collected through monitoring to determine that a hardware-layer virtual machine, such as hardware-layer virtual machine A, has crashed, it can interact with the crashed hardware-layer virtual machine A, specifically by sending instructions to hardware-layer virtual machine A, thereby notifying hardware-layer virtual machine A to release currently occupied resources, i.e., executing step 101.

[0137] It should be noted that when the hardware layer virtual machine A is started, some IO resources and interrupt resources of the electronic device are taken over by the hardware layer virtual machine A. Therefore, when the hardware layer virtual machine A crashes, these resources need to be released first.

[0138] 6 , illustratively, after the hardware layer virtual machine A receives the instruction from the virtual machine management service to release the occupied resources, it will close the IO and interrupt of the driver to be called when processing the business it is responsible for, and clean up the events and messages in the queues corresponding to these driver IO and interrupts.

[0139] 3 and 5 , the services handled by hardware layer virtual machine A may include fingerprint, face, gesture, and other recognition and processing services. For ease of explanation, this embodiment takes the fingerprint and gesture recognition services handled by hardware layer virtual machine A as an example.

[0140] Understandably, when implementing fingerprint recognition and gesture recognition services, it is necessary to call the touch driver and display driver of the electronic device. Therefore, in this embodiment, the hardware layer virtual machine A needs to disable the touch driver's IO and interrupts (execute step 1011), clear the events and messages in the queues corresponding to the touch driver's IO and interrupts (execute step 1012), and disable the display driver's IO and interrupts (execute step 1011'), and clear the events and messages in the queues corresponding to the display driver's IO and interrupts (execute step 1012').

[0141] For example, in one possible implementation, the queues corresponding to the touch driver's IO and interrupts may include a first-in-first-out (FIFO) queue and a message queue (MSGQ). The queues corresponding to the display driver's IO and interrupts may also include a FIFO queue and a MSGQ.

[0142] Each FIFO queue can cache events not processed by hardware layer VM A, and each MSGQ can cache messages not processed by hardware layer VM A. Therefore, the processing required by hardware layer VM A can include clearing events from each FIFO queue and clearing messages from each MSGQ.

[0143] It should be understood that the above description is merely an example listed for a better understanding of the technical solution of this embodiment, and is not intended to be the sole limitation on this embodiment.

[0144] 6 , illustratively, after the hardware layer virtual machine A that crashes completes the release of occupied resources, the virtual machine management service reclaims the memory resources occupied by the hardware layer virtual machine A and hands the memory resources over to the PVM.

[0145] 102. The virtual machine management service notifies the primary virtual machine to take over the resources of the hardware layer virtual machine where the crash event occurs.

[0146] Because the virtual machine management service acts as a virtual machine manager and is responsible for interacting with each virtual machine, if hardware-layer virtual machine A crashes but the PVM does not (specifically, no panic exception or problem occurs), the virtual machine management service can send instructions to the PVM, instructing it to take over the I / O resources, interrupt resources, memory resources, etc. released by hardware-layer virtual machine A.

[0147] In this way, the PVM can temporarily store the corresponding IO resources and interrupt resources for the hardware layer virtual machine A, and the recovered memory resources can also be used by the PVM to avoid the PVM from crashing due to insufficient resources.

[0148] 103. The primary virtual machine takes over the IO resources, interrupt resources, and reclaimed memory resources of the hardware layer virtual machine that crashed.

[0149] 104. After the primary virtual machine takes over the resources of the hardware virtual machine that crashed, the virtual machine management service coordinates the memory resources of the hardware layer virtual machine, re-establishes the mapping, and calls the kernel driver to reload the image of the hardware layer virtual machine that crashed, and restarts the hardware layer virtual machine that crashed.

[0150] In this way, it is possible to self-recover only the hardware layer virtual machine A that has crashed, that is, to restart only the business that the hardware layer virtual machine A is responsible for without affecting other normal businesses.

[0151] 105. After the hardware layer virtual machine where the crash occurred is successfully restarted, the primary virtual machine releases the IO resources and interrupt resources of the touch driver and the display driver.

[0152] That is, the control of the IO resources and interrupt resources of the touch driver and display driver is transferred back to the hardware layer virtual machine A.

[0153] 106. After the restarted hardware layer virtual machine obtains the IO resources and interrupt resources of the touch driver and display driver, it re-establishes the service link and resumes the service.

[0154] In this way, the hardware layer virtual machine A can resume the business it is responsible for.

[0155] Therefore, based on this self-recovery logic, when a hardware-layer virtual machine crashes, the primary virtual machine (which hasn't crashed and is hosting the operating system) temporarily takes over the resources occupied by the hardware-layer virtual machine and restarts the hardware-layer virtual machine separately. After the hardware-layer virtual machine restarts, the resources of the hardware-layer virtual machine taken over by the primary virtual machine are returned to the hardware-layer virtual machine. In this way, only the hardware-layer virtual machine that crashed is self-recovered, and the entire electronic device is not triggered to restart, thereby reducing user perception and improving the user experience.

[0156] In addition, when a hardware-layer virtual machine crashes, data in the electronic device's memory is not collected for dumping during self-recovery, thus avoiding the leakage of user data and protecting user privacy.

[0157] In addition, the method for handling virtual machine crash events provided in the embodiments of the present application can be used as a platform-based solution. That is, the virtual machines in the SOC provided by the chip platform with such problems can be gradually iterated and inherited to be backward compatible with the new platform.

[0158] 7 , a method for handling a virtual machine crash event applied to an internal test machine is exemplarily shown, specifically comprising:

[0159] 201. The virtual machine management service collects dump information and writes it to the specified partition.

[0160] It should be noted that in the computer field, dump is generally translated as dump. Because when a program is running in an electronic device, the data on the memory, CPU, IO, etc. are dynamic (or volatile), that is to say, the data will be lost after it is used up or an exception occurs. Therefore, in the research and development stage, if you want to obtain the data at the moment when the crash occurs, that is, the dump information mentioned in the embodiment of the present application, you need to dump these data into a static form (such as a file, hereinafter referred to as a dump file) and store it in a non-volatile storage medium, such as an internal memory, an external memory / card, that is, the disk is dropped to a specified partition as mentioned in the embodiment of the present application. In this way, R&D personnel can locate and solve problems based on the content recorded in the dump file.

[0161] 202. The virtual machine management service notifies the hardware layer virtual machine where the crash occurs to process current resources.

[0162] Still taking the example of the hardware layer virtual machine that is responsible for the business when the crash event occurs, the drivers to be called include the touch driver and the display driver. On this basis, step 202 in the embodiment of the present application is roughly the same as step 101 in the embodiment shown in Figure 6. That is, the hardware virtual machine that crashes will turn off the IO and interrupt of the touch driver (execute step 2021), clean up the events and messages in the queue corresponding to the IO and interrupt of the touch driver (execute step 2022), and turn off the IO and interrupt of the display driver (execute step 2021'), clean up the events and messages in the queue corresponding to the IO and interrupt of the display driver (execute step 2022').

[0163] For specific implementation details of the above steps, please refer to step 101 in the embodiment shown in Figure 6, and the description of steps 1011, 1011', 1012, and 1012' included in step 101, which will not be repeated here.

[0164] 7 , illustratively, after the hardware layer virtual machine that crashes completes the release of occupied resources, the virtual machine management service reclaims the memory resources occupied by the hardware layer virtual machine and hands the memory resources over to the primary virtual machine.

[0165] 203. The virtual machine management service notifies the primary virtual machine to take over the resources of the hardware layer virtual machine where the crash occurs.

[0166] 204 , the primary virtual machine takes over the IO resources, interrupt resources, and reclaimed memory resources of the hardware layer virtual machine that crashed.

[0167] 205. After the primary virtual machine takes over the resources of the hardware virtual machine that crashed, the virtual machine management service coordinates the memory resources of the hardware layer virtual machine, re-establishes the mapping, and calls the kernel driver to reload the image of the hardware layer virtual machine that crashed, and restarts the hardware layer virtual machine that crashed.

[0168] 206. After the hardware layer virtual machine where the crash occurred is successfully restarted, the primary virtual machine releases the IO resources and interrupt resources of the touch driver and the display driver.

[0169] 207 , after the restarted hardware layer virtual machine obtains the IO resources and interrupt resources of the touch driver and display driver, it re-establishes the service link and resumes the service.

[0170] It should be noted that steps 203 to 207 in the embodiment of the present application are roughly the same as steps 102 to 106 in the embodiment shown in Figure 6. For specific implementation details, please refer to the description of steps 102 to 106 in the embodiment shown in Figure 6, and will not be repeated here.

[0171] Therefore, based on this self-recovery logic, when a hardware-layer virtual machine crashes, the primary virtual machine (which hasn't crashed and is hosting the operating system) temporarily takes over the resources occupied by the hardware-layer virtual machine and restarts the hardware-layer virtual machine separately. After the hardware-layer virtual machine restarts, the resources of the hardware-layer virtual machine taken over by the primary virtual machine are returned to the hardware-layer virtual machine. In this way, only the hardware-layer virtual machine that crashed is self-recovered, and the entire electronic device is not triggered to restart, thereby reducing user perception and improving the user experience.

[0172] In addition, when a hardware-layer virtual machine crashes, triggering the hardware-layer virtual machine to release resources, the main virtual machine takes over the resources released by the hardware-layer virtual machine and the occupied memory resources, and also dumps the current data in the memory of the electronic device. This enables R&D personnel to quickly locate and solve problems based on the dumped dump files during the R&D phase.

[0173] In addition, it is understandable that, in order to implement the above functions, the electronic device includes hardware and / or software modules corresponding to the execution of each function. In combination with the algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in combination with the embodiments, but such implementation should not be considered to be beyond the scope of this application.

[0174] In addition, it should be noted that the methods for handling virtual machine crash events provided in the above embodiments implemented by electronic devices in actual application scenarios can also be performed by a chip system included in the electronic device, wherein the chip system may include a processor. The chip system can be coupled to a memory so that when the chip system is running, it calls a computer program stored in the memory to implement the steps performed by the above electronic device. The processor in the chip system can be an application processor or a processor other than an application processor.

[0175] In addition, an embodiment of the present application also provides a computer-readable storage medium, which stores computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes the above-mentioned related method steps to implement the method for handling the virtual machine crash event in the above-mentioned embodiment.

[0176] In addition, an embodiment of the present application further provides a computer program product. When the computer program product is run on an electronic device, the electronic device executes the above-mentioned related steps to implement the method for handling a virtual machine crash event in the above-mentioned embodiment.

[0177] In addition, an embodiment of the present application also provides a chip (which may also be a component or module), which may include one or more processing circuits and one or more transceiver pins; wherein, the transceiver pins and the processing circuit communicate with each other through an internal connection path, and the processing circuit executes the above-mentioned related method steps to implement the method for handling the virtual machine crash event in the above-mentioned embodiment, so as to control the receiving pin to receive the signal, so as to control the sending pin to send the signal.

[0178] In addition, it can be seen from the above description that the electronic device, computer-readable storage medium, computer program product or chip provided in the embodiments of the present application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0179] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for processing a virtual machine crash event, characterized in that: Applied to an electronic device, a first virtual machine and a second virtual machine are running on the electronic device, the first virtual machine is a virtual machine that carries the operating system of the electronic device, and the second virtual machine is a virtual machine for the hardware layer of the electronic device; The method comprises: In response to a crash event of the second virtual machine, releasing the first resource occupied by the second virtual machine, and having the first virtual machine take over the first resource; reallocating memory resources for the second virtual machine and restarting the second virtual machine; After the second virtual machine is successfully restarted, releasing the first resource taken over by the first virtual machine; After the second virtual machine obtains the first resource, a service link between the second virtual machine and the service for which the second virtual machine is responsible is re-established to restore the processing capability of the service.

2. The method according to claim 1, characterized in that The releasing the first resource occupied by the second virtual machine includes: Disabling input / output (IO) resources and interrupt resources of a first driver, where the first driver is the driver to be called by the second virtual machine when processing the service; Clear the contents of the queues corresponding to the IO resources and the interrupt resources.

3. The method according to claim 2, characterized in that The clearing of the contents in the queues corresponding to the IO resources and the interrupt resources includes: Clean up the events in the first-in-first-out queues corresponding to the IO resources and the interrupt resources, as well as, Messages in the message queues corresponding to the IO resources and the interrupt resources are cleared.

4. The method according to claim 2, characterized in that After clearing the contents of the queues corresponding to the IO resources and the interrupt resources, the method further includes: Reclaim the memory resources occupied by the second virtual machine.

5. The method according to claim 4, characterized in that The method further comprises: The first virtual machine takes over the reclaimed memory resources.

6. The method according to claim 1, characterized in that The reallocating memory resources for the second virtual machine and restarting the second virtual machine includes: reallocating memory resources for the second virtual machine and re-establishing a mapping between the second virtual machine and the memory resources; Calling a second driver to load the image of the second virtual machine; Restart the operating system running on the second virtual machine.

7. The method according to any one of claims 1 to 6, characterized in that In response to a crash event of the second virtual machine, the method further includes: Acquire data in the memory resources corresponding to the second virtual machine, and dump the data into a storage medium of the electronic device.

8. The method according to any one of claims 1 to 6, characterized in that The method further comprises: During the process of creating the first virtual machine and the second virtual machine, configuring monitoring for the first virtual machine and the second virtual machine; Collecting system event information of the first virtual machine and the second virtual machine by using the monitoring, the system event information including event types; When the event type indicates that the system event currently occurring in the second virtual machine is a crash event, the step of responding to the crash event occurring in the second virtual machine is performed.

9. The method according to claim 8, characterized in that The method further comprises: When the event type indicates that the system event currently occurring in the first virtual machine is a crash event, in response to the crash event occurring in the first virtual machine, the electronic device is completely restarted.

10. The method according to claim 9, characterized in that When the event type indicates that the system event currently occurring in the first virtual machine is a crash event, in response to the crash event occurring in the first virtual machine, restarting the entire electronic device includes: When the crash event is a panic exception, in response to the crash event of the first virtual machine, the electronic device is completely restarted.

11. An electronic device, characterized in that: The electronic device includes: a memory and a processor, the memory and the processor are coupled; the memory stores program instructions, and when the program instructions are executed by the processor, the electronic device executes the method for handling a virtual machine crash event according to any one of claims 1 to 10.

12. A computer-readable storage medium, characterized in that The method comprises a computer program, which, when running on an electronic device, enables the electronic device to execute the method for processing a virtual machine crash event according to any one of claims 1 to 10.

Images