Fault processing method for apparatus, apparatus, system, and vehicle

Abstract

The present application relates to the field of automated fault processing, and discloses a fault processing method for an apparatus, an apparatus, a system, and a vehicle, which can improve the real-time performance and reliability of automated fault identification and processing for an apparatus, ensure reliable and safe operation of the apparatus, and guarantee a low-latency response to watchdog interrupts. According to the present application, when an FIQ event from a fault identification module is received, an ATF layer determines an SDEI event corresponding to the FIQ event, and determines, on the basis of stored first configuration information, a first fault recovery entry at a hypervisor layer corresponding to the SDEI event, and then jumps to the hypervisor layer via the entry to perform an automated fault response; and, when the fault response at the hypervisor layer fails, determines, on the basis of stored second configuration information, a second fault recovery entry at an SOS layer corresponding to the SDEI event, and jumps to the SOS layer via the entry to perform an automated fault response.

Description

Fault handling method, device, system and vehicle

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on March 29, 2024, with application number 202410392435.9 and application name “Device fault handling method, device, system and vehicle”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of automated fault handling, and in particular to a method, device, system, and vehicle for handling device faults. Background Art

[0003] Automated response to device failures has long been a key research focus across various fields. For example, in the intelligent vehicle sector, different domain controllers (DCs) may be responsible for the vehicle's powertrain, autonomous driving system, and electronic information system. To ensure the proper operation of each DC, a watchdog (WDG) is often used to monitor the operating status of each DC based on an IRQ (interrupt request) mechanism. For example, each DC within a vehicle periodically "feeds" the DC to report its operating status to the watchdog. If a DC fails to "feed" the DC within a certain timeout due to a fault, the watchdog's IRQ interrupt is triggered, initiating fault processing and automatically shutting down the faulty DC to ensure safety.

[0004] However, the above-mentioned method of identifying whether a domain controller failure occurs based on the IRQ mechanism is too dependent on the IRQ mechanism. If the IRQ is blocked, maliciously attacked, or the system is processing other IRQs, the fault handling module may not be able to identify and handle the domain controller failure in a timely manner. Summary of the Invention

[0005] The present application provides a device fault handling method, device, system and vehicle, which can improve the real-time and reliability of the device's automatic fault identification and processing, ensure the reliable and safe operation of the device and the low-latency response of the watchdog interrupt.

[0006] To achieve the above objectives, this application adopts the following technical solutions:

[0007] In a first aspect, a fault handling method for an apparatus is provided, which can be applied to a first processing module of an electronic apparatus, wherein the electronic apparatus further includes a second processing module, and the method includes: the first processing module identifying a first fast interrupt request (FIQ) event of the second processing module; in response to the first FIQ event, the first processing module performing a first recovery on the second processing module, wherein the first recovery is the responsibility of a virtual machine supervisor layer (hypervisor layer) of the first processing module.

[0008] As an example, the first processing module may include, from top to bottom, a service operating system (SOS) layer, a hypervisor layer, and a trusted firmware layer (such as an ARM trusted firmware (ATF) layer), and the second processing module is a user operating system (UOS) layer. In other words, the solution provided in this application can be applied to the scenario where the hypervisor layer of the first processing module recovers a failed UOS layer.

[0009] In the solution provided by the first aspect above, the first processing module can partition and deploy the entire system according to the security and trustworthiness attributes and business scope of the business, and adopts a solution that configures the watchdog interrupt corresponding to the second processing module as FIQ type. In this solution, if the second processing module fails to "feed the dog" due to timeout, its corresponding watchdog FIQ interrupt will be triggered, and the first processing module can automatically respond to the fault through the hypervisor layer for the FIQ interrupt. Based on this, the real-time and reliability of the automatic fault identification and processing of the device can be improved, and the reliable and safe operation of the device and the low-latency response of the watchdog interrupt can be guaranteed. For example, compared with the conventional IRQ mechanism, the fault handling method of the device provided in the present application can avoid the problem of being unable to timely identify and handle virtual machine faults and security issues caused by IRQ being blocked or malicious attacks.

[0010] As a possible implementation, first configuration information is stored in the trusted firmware layer (ATF layer) of the first processing module. The first configuration information includes a correspondence between a first software delegated exception interface (SDEI) event corresponding to a first FIQ event and a first fault recovery entry of the hypervisor layer (hypervisor layer) of the first processing module. The above-mentioned first recovery of the second processing module includes: jumping to the hypervisor layer (hypervisor layer) through the first fault recovery entry according to the first configuration information, so as to perform the first recovery of the second processing module at the hypervisor layer (hypervisor layer). Based on this, it can be ensured that the first processing module can quickly and smoothly jump to the hypervisor layer to perform the first recovery of the second processing module, thereby improving the real-time and reliability of the device's automatic fault identification and processing, ensuring the reliable and safe operation of the device and the low-latency response of the watchdog interrupt.

[0011] Exemplarily, the ATF layer of the first processing module can determine the first fault recovery entry of the hypervisor layer of the first processing module corresponding to the first SDEI event corresponding to the first FIQ event based on the correspondence between the SDEI event in the first configuration information and the first fault recovery entry of the hypervisor layer of the first processing module, and then jump to the hypervisor layer through the first fault recovery entry to perform the first recovery of the second processing module.

[0012] As a possible implementation, the method further includes: performing a second recovery on the second processing module if the first recovery fails, where the second recovery is performed by the service operating system layer (SOS layer) of the first processing module. This dual recovery mechanism at the hypervisor layer and the SOS layer further ensures the reliability of automated fault response.

[0013] Illustratively, the reasons for the above-mentioned first recovery failure include any one of the following: failure to power off the second processing module; failure to load the system image file of the second processing module; and failure to power on the second processing module.

[0014] As a possible implementation, the hypervisor layer stores second configuration information, which includes a correspondence between the first SDEI event and the second fault recovery entry of the service operating system layer (SOS layer) of the first processing module. The second recovery of the second processing module includes: jumping to the service operating system layer (SOS layer) through the second fault recovery entry according to the second configuration information, so as to perform a second recovery of the second processing module at the service operating system layer (SOS layer). This ensures that the first processing module can quickly and smoothly jump to the SOS layer to perform a second recovery of the second processing module, improving the real-time and reliability of the device's automated fault identification and processing, ensuring the reliable and safe operation of the device, and low-latency response to watchdog interrupts.

[0015] Exemplarily, the hypervisor layer of the first processing module can determine the second fault recovery entry of the SOS layer of the first processing module corresponding to the first SDEI event based on the second configuration information, and then jump to the SOS layer through the second fault recovery entry to perform a second recovery on the second processing module.

[0016] As a possible implementation, the first recovery of the second processing module includes: powering off the second processing module at the hypervisor layer; loading the system image file of the second processing module from a system disk or file system (e.g., a file system at the hypervisor layer) to memory at the hypervisor layer; and powering on the second processing module at the hypervisor layer. This ensures that the second processing module is successfully recovered and can operate normally.

[0017] As a possible implementation, when the first restoration is successful, the method further includes: notifying the trusted firmware layer (ATF layer) of the success of the first restoration via the hypervisor layer; and restoring the context of the service operating system layer (SOS layer) at the trusted firmware layer (ATF layer). This ensures that after the FIQ event response is completed, the SOS is restored to its state before the FIQ event interruption, ensuring normal operation of the device.

[0018] Exemplarily, the first processing module may send an SDEI_EVENT_COMPLETE command to the ATF layer through the hypervisor layer to notify the ATF layer that the first recovery is successful.

[0019] As a possible implementation, the second recovery of the second processing module includes: powering off the second processing module at the service operating system layer (SOS layer) or at the hypervisor layer, loading the system image file of the second processing module from a system disk or file system (such as the file system of the SOS layer) to memory at the service operating system layer (SOS layer), and powering on the second processing module at the service operating system layer (SOS layer). This ensures that the second processing module is successfully recovered and can operate normally.

[0020] As a possible implementation, when the second restoration is successful, the method further includes: notifying the hypervisor layer of the success of the second restoration via the service operating system layer (SOS layer); notifying the trusted firmware layer (ATF layer) of the success of the second restoration via the hypervisor layer; and restoring the context of the service operating system layer (SOS layer) at the trusted firmware layer (ATF layer). This ensures that after the FIQ event response is completed, the SOS is restored to the state it was in before the FIQ event interruption, ensuring normal operation of the device.

[0021] Exemplarily, the SOS layer of the first processing module may send an SDEI_EVENT_COMPLETE command to the ATF layer through the hypervisor layer to notify the ATF layer that the second recovery is successful.

[0022] As one possible implementation, powering off the second processing module includes powering off the processing core of the second processing module; and powering on the second processing module includes powering on the processing core of the second processing module. Based on this, the second processing module can be powered on and off by powering off and on the processing core, which is easy to implement.

[0023] Exemplarily, the second processing module includes one processing core. In this case, the first processing module can power off the one processing core to complete powering off the second processing module, and the first processing module can power on the one processing core to complete powering on the second processing module.

[0024] Alternatively, illustratively, the second processing module includes a main processing core and at least one slave processing core, and the above-mentioned powering off the processing cores of the second processing module includes: powering off the main processing core and at least one slave processing core of the second processing module; the above-mentioned powering on the processing cores of the second processing module includes: powering on the main processing core of the second processing module, and powering on at least one slave processing core of the second processing module through the main processing core of the second processing module after the main processing core of the second processing module is powered on.

[0025] As one possible implementation, powering off the processing core of the second processing module includes sending an IPI_CPU_CRASH_STOP inter-core interrupt command to the processing core of the second processing module to instruct the processing core of the second processing module to power off. This allows for rapid and reliable powering off of the second processing module, facilitating subsequent smooth recovery of the second processing module.

[0026] As a possible implementation method, the above method also includes: identifying the second FIQ event of the first processing module, the target object corresponding to the second FIQ event is the service operating system layer (SOS layer) of the first processing module; in response to the second FIQ event, restoring the service operating system layer (SOS layer) of the first processing module. In this solution, due to the failure of the SOS layer of the first processing module to time out and not "feed the dog", its corresponding watchdog FIQ interrupt will be triggered, and the first processing module can automatically respond to the fault through the hypervisor layer for the FIQ interrupt. Based on this, the real-time and reliability of the automatic fault identification and processing of the device can be improved, and the reliable and safe operation of the device and the low-latency response of the watchdog interrupt can be ensured. For example, compared with the conventional IRQ mechanism, the fault handling method of the device provided in the present application can avoid the problem and security problem of not being able to timely identify and handle virtual machine faults due to IRQ being blocked or malicious attacks.

[0027] As a possible implementation, the first processing module includes a master processing core and a slave processing core. Restoring the service operating system layer (SOS layer) of the first processing module includes: powering off the slave processing core of the first processing module via the master processing core of the first processing module; loading the image file of the service operating system (SOS layer) of the first processing module from a system disk or file system (such as a file system of the hypervisor layer) into memory via the virtual machine supervisory program layer (hypervisor layer); redirecting the master processing core of the first processing module to the operating system entry of the service operating system layer after the newly loaded image file; and starting up the slave processing core of the service operating system (SOS layer) of the first processing module at the master processing core of the service operating system layer (SOS layer). Based on this, the SOS of the first processing module can be successfully restored, and normal operation can be resumed.

[0028] As a possible implementation, the trusted firmware layer (ATF layer) of the first processing module stores the correspondence between the FIQ events and SDEI events of one or more target objects; the identification of the first FIQ event of the second processing module includes: receiving the first FIQ event from the fault identification module, determining the first SDEI event corresponding to the first FIQ event based on the correspondence between the FIQ events and SDEI events of the one or more target objects, and determining the first fault recovery entry corresponding to the first SDEI event based on the first configuration information; the identification of the second FIQ event of the first processing module includes: receiving the second FIQ event from the fault identification module, determining the second SDEI event corresponding to the second FIQ event based on the correspondence between the FIQ events and SDEI events of the one or more target objects, and determining the first fault recovery entry corresponding to the second SDEI event based on the first configuration information. Based on this, it can be ensured that the first processing module can quickly and reliably match the FIQ event to the SDEI event and determine the fault recovery entry for hierarchical jump corresponding to the SDEI event, thereby ensuring the smooth progress of hierarchical jump and subsequent fault processing.

[0029] Exemplarily, the fault identification module is a watchdog. Based on this, the first FIQ event and the second FIQ event are watchdog FIQ interrupts.

[0030] In a second aspect, a processing module is provided, which includes, from top to bottom, an SOS layer, a hypervisor layer, and an ATF layer. The SOS layer, the hypervisor layer, and the ATF layer are used to support the processing module to implement the method in any possible implementation of the first aspect.

[0031] In a third aspect, a processing module is provided, which includes: a memory for storing computer program instructions; and a processor for executing the computer program instructions to support the processing module in implementing the method in any possible implementation of the first aspect.

[0032] In a fourth aspect, a computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the method in any possible implementation of the first aspect is implemented.

[0033] In a fifth aspect, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to implement the method in any possible implementation of the first aspect.

[0034] In a sixth aspect, a chip system is provided, comprising a processing circuit and a storage medium storing computer program instructions; when the computer program instructions are executed by the processor, the method according to any possible implementation of the first aspect is implemented. The chip system may be composed of a chip alone or may include a chip and other discrete components. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] FIG1 is a schematic diagram showing the principle of automatic fault response based on the IRQ mechanism;

[0036] FIG2 is a schematic diagram showing another principle of automatic fault response based on the IRQ mechanism;

[0037] FIG3 is a schematic diagram of a system architecture for deploying multiple virtual machines on a single chip according to an embodiment of the present application;

[0038] FIG4 is a schematic diagram of a system architecture for deploying multiple virtual machines on a single chip in the intelligent vehicle field according to an embodiment of the present application;

[0039] FIG5 is a flow chart of a method for troubleshooting a device provided in an embodiment of the present application;

[0040] FIG6 is a schematic diagram of a fault handling process of a device provided in an embodiment of the present application;

[0041] FIG7 is a schematic diagram of a process of a power-off processing module provided in an embodiment of the present application;

[0042] FIG8 is a schematic diagram of a fault handling process of another device provided in an embodiment of the present application;

[0043] FIG9 is a schematic diagram of another power-off processing module according to an embodiment of the present application;

[0044] FIG10 is a flow chart of a fault handling method for another device provided in an embodiment of the present application;

[0045] FIG11 is a schematic diagram of a fault handling process of another device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0046] The technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings in the embodiments of the present application. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships can exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0047] Hereinafter, the terms "first," "second," and so on are used solely to distinguish different descriptive objects and have no limiting effect on the position, order, priority, quantity, or content of the described objects. For example, if the described object is a "field," the ordinal number preceding the "field" in "first field" and "second field" does not define the position or order of the "fields." "First" and "second" do not define whether the modified "fields" are in the same message, nor do they restrict the order of the "first field" and "second field." For another example, if the described object is a "level," the ordinal number preceding the "level" in "first level" and "second level" does not define the priority of the "levels." For another example, the number of described objects is not limited by the ordinal number and can be one or more. For example, in the case of "first device," the number of "devices" can be one or more. Furthermore, the objects modified by different prefixes can be the same or different. For example, if the described object is a "device," the "first device" and "second device" can be the same type of device or different types of devices. For another example, if the described object is "information," the "first information" and "second information" can be information of the same content or different contents. In short, the use of prefixes such as ordinal numbers to distinguish the described objects in the embodiments of the present application does not constitute a restriction on the described objects. For the statement of the described objects, please refer to the description in the context of the claims or embodiments, and no unnecessary restrictions should be constituted due to the use of such prefixes.

[0048] Furthermore, in the embodiments of the present application, "connection" may be a direct connection or an indirect connection; in addition, it may refer to an electrical connection or a communication connection; for example, the connection between two electrical components A and B may refer to a direct connection between A and B, or may refer to an indirect connection between A and B through other electrical components or connection media, or may refer to an indirect connection between A and B through other communication devices or communication media, as long as communication between A and B can be achieved.

[0049] As described in the background technology, currently, in some application fields, in order to ensure the normal operation of the device during operation, a watchdog is often used to follow up the operating status of each domain controller based on the IRQ mechanism, and to power off a domain controller when it times out and is not "fed the dog" to ensure safety.

[0050] As an example, please refer to Figure 1, which shows an automated response to a fault. Taking the solution as an example, a schematic diagram of the principle of automatic fault response based on the IRQ mechanism is shown. As shown in Figure 1, The software architecture of the solution includes dom0, domU and hypervisor layers from top to bottom. As an open source software architecture, The solution's software architecture supports timely monitoring of virtual machine (VM) operating status and automated fault response. As shown in Figure 1, each VM (using dom0 and domU as examples) runs a wdt_daemon background process. This process has permissions to perform watchdog operations, such as opening, starting, stopping, and kicking the watchdog. During initialization, the wdt_daemon background process opens the xen_wdt device file ( / dev / watchdog / xen_wdt in Figure 1) and periodically "feeds" the watchdog. For example, this can be done by jumping to kernel state via a system call. The kernel then calls the HVC (hypervisor call) instruction (STD HVC in Figure 1) to jump to the hypervisor layer to "feed" the virtual watchdog. If a VM fails to "feed" the watchdog in a timely manner, a timer IRQ interrupt is triggered. This triggers a hypervisor-layer timeout, such as shutting down the faulty VM. As shown in Figure 1, this solution relies on the IRQ mechanism, and IRQ can be easily blocked and maliciously attacked. Once IRQ is blocked, maliciously attacked, or the system is processing other IRQ interrupts, the virtual machine failure cannot be identified and processed in a timely manner.

[0051] As another example, please refer to Figure 2, which shows an automated response to a fault. Taking the solution as an example, a schematic diagram of the principle of automatic fault response based on the IRQ mechanism is shown. As shown in Figure 2, The software architecture of the solution can support timely follow-up of virtual machine operation status and automatic response to faults. As shown in Figure 2, The solution's guest operating system (Guest OS) runs a watchdog client (WDT client) process, which can notify the watchdog monitor service (WDT monitor service) in the partition monitor within the Drive OS Foundation Service (Drive OS Foundation Service) through the hypervisor layer to "feed the watchdog." (In addition to providing services such as partition monitoring through the partition monitor, the Drive OS Foundation Service can also provide system management and other related services through the system manager shown in Figure 2.) Based on this, if the watchdog client process running on the Guest OS fails to "feed the watchdog" in a timely manner, a timer IRQ interrupt will be triggered, which in turn will trigger the partition monitor to perform timeout processing, such as quickly recovering the Guest OS. Because this solution also uses the IRQ mechanism to track the running status of the Guest OS, it cannot avoid the problem of being unable to promptly identify and handle virtual machine failures due to IRQ blocking, malicious attacks, or when the system is processing other IRQ interrupts. In addition, the operation status monitoring and automatic fault response in this solution both rely on the partition monitor in the basic services of the autonomous driving operating system. Once the partition monitor fails, the entire operation status monitoring mechanism and the automatic fault response mechanism will be paralyzed.

[0052] In order to solve the problems existing in the conventional fault automation response mechanism shown in Figure 1 or Figure 2, a fault automation response mechanism with stronger security, real-time and reliability is provided to ensure the reliable and safe operation of the device. An embodiment of the present application provides a fault handling method for a device. The method adopts a solution that configures the watchdog interrupt as an FIQ type and combines it with the software delegated exception interface (SDEI) mechanism, reports the software delegated exception interface (SDEI) event corresponding to the FIQ event to the hypervisor layer for fault automation response, and reports the SDEI event to the service operation system (SOS) for fault automation response when the hypervisor layer fails to respond to the fault. Based on this, not only can the problem and security problem of the conventional IRQ mechanism that is easily blocked and maliciously attacked and cannot be timely identified and processed for virtual machine faults be solved, but the reliability of the fault automation response can also be guaranteed through the dual recovery mechanism of the hypervisor layer and the SOS.

[0053] The fault handling method of the device provided in the embodiment of the present application can be applied to but not limited to scenarios such as the smart car field and the smart medical field that support the deployment of multiple virtual machines on a single chip, without specific limitation.

[0054] For example, the fault handling method of the device provided in the embodiments of the present application can be applied to a vehicle. For example, the vehicle described in the embodiments of the present application can be a means of transportation (such as a car, bus, subway, high-speed rail, motorcycle, flying car, train, etc.), an industrial vehicle (such as a forklift, trailer, tractor, etc.), an engineering vehicle (such as an excavator, bulldozer, crane, etc.), agricultural equipment (such as a lawn mower, harvester, etc.), amusement equipment, a toy vehicle, a boat, an air cushion vehicle, a submarine, an airplane, a helicopter, etc. The embodiments of the present application do not limit the specific type, form, and function of the vehicle.

[0055] Of course, the fault handling method of the device provided in the embodiment of the present application can also be applied to other vehicles, such as water vehicles, air vehicles, industrial equipment, agricultural equipment or entertainment equipment.

[0056] Taking the smart car field as an example, in-vehicle virtualization technology can support multiple operating systems on the same hardware platform, such as intelligent driving domain virtual machines (VMs), instrument domain VMs, cockpit domain VMs, chassis domain VMs, power domain VMs, body domain VMs, etc., to achieve hardware integration and computing power sharing of in-vehicle computing units, as well as achieve secure isolation between different domains, while effectively reducing the cost of the entire vehicle.

[0057] The Intelligent Driving Domain VM primarily provides autonomous driving perception and decision-making services, such as image reception, image processing and judgment, data processing and calculation, navigation and route planning, and rapid real-time situation judgment and decision-making. The Intelligent Driving Domain requires processing algorithms at the three levels of perception, decision-making, and control, placing the highest demands on the domain controller's hardware and software. The Instrument Domain VM primarily provides instrumentation or user interface displays of vehicle speed, engine speed, and driving energy. The Cockpit Domain VM primarily controls various electronic information systems within the vehicle's intelligent cockpit, including the central control system, in-vehicle infotainment system, head-up display, seating system, instrumentation system, rearview mirror system, driver behavior monitoring system, and navigation system. The Chassis Domain VM primarily controls the vehicle's driving behavior and posture. Its functions include, but are not limited to, brake system management, transmission system management, driving system management, steering system management, vehicle speed sensor management, body posture sensor management, air suspension system management, and airbag system management. The power domain VM is primarily used to control the vehicle's powertrain, optimize its performance, and ensure its safety. These include engine management, transmission management, battery management, power distribution management, emissions management, speed limit management, and fuel and power conservation management. The body domain VM is primarily used to control various vehicle body functions, including but not limited to headlights, taillights, interior lights, door locks, windows, sunroof, wipers, power trunk, smart key, air conditioning, antenna, and gateway communications.

[0058] As an example, please refer to Figure 3, which shows a schematic diagram of the system architecture of a single-chip deployment of multiple virtual machines provided by an embodiment of the present application. As shown in Figure 3, the software architecture of the electronic device includes SOS, user operating system (user operation system, UOS) 0, UOS1, hypervisor layer, ARM trusted firmware (ARM trusted firmware, ATF) layer from top to bottom, wherein SOS, UOS0 and UOS1 are all virtual machines (VM), so SOS can also be called SOS VM, UOS0 and UOS1 can also be called UOS VM. Exemplarily, the electronic device described in the embodiment of the present application can be a physical device or a virtual device, such as a whole system, etc., without specific limitation.

[0059] The hypervisor layer, also known as the virtual machine monitor (VMM), allows multiple operating systems and applications to share a set of underlying physical hardware. Therefore, it can also be regarded as the "meta" operating system in the virtual environment. It can coordinate access to all physical devices and virtual machines on the server.

[0060] Among them, both the SOS VM and the hypervisor layer include a fault recovery module. As shown in Figure 3, the hypervisor layer includes a first fault recovery module, and the SOS VM includes a second fault recovery module. The first fault recovery module is used to recover the faulty VM (SOS or UOS) at the hypervisor layer, and the second fault recovery module is used to recover the faulty VM (UOS) at the SOS layer. Recovery may include but is not limited to power off or restart, and is not specifically limited. Among them, the hypervisor layer stores the correspondence between the SDEI events of one or more UOS and the second fault recovery entry of the SOS layer of the first processing module. Exemplarily, the correspondence can be that the hypervisor layer stores the second fault recovery entry of the SOS layer of the first processing module corresponding to the SDEI event that the SOS layer pre-registers with the hypervisor layer in the hypervisor layer.

[0061] The ATF layer is the underlying firmware provided by ARM. This firmware unifies ARM's underlying interface standards, such as calling the power state coordination interface (PSCI), trusted board boot requirements (TBBR), and the secure monitor call (SMC) interface for switching between the secure world state (SWS) and normal world state (NWS). ATF aims to unify ARM's underlying operations to enable code reuse and ease porting.

[0062] In order to provide a more trusted and secure operating environment, the trusted execution environment (TEE) operating system shown in Figure 3 is introduced to switch between the secure world state and the normal world state according to different usage scenarios and requirements. Among them, the loading of TEEOS is completed by BL32 in the ATF, and the switching between the secure world state and the normal world state is completed by BL31. After loading TEEOS, TEEOS needs to return an interface structure variable of the processing function to BL31. When the secure monitoring mode call instruction is triggered on the REE side, BL31 can know which interface in the TEE needs to send the secure monitoring mode call instruction request by querying the structure variable and complete the switching from the normal world state to the secure world state.

[0063] As shown in Figure 3, the ATF layer includes a fast interrupt processing module. Among them, the ATF layer stores the correspondence between the FIQ events of one or more virtual machines (VMs) and the SDEI events, as well as the correspondence between the SDEI events and the first fault recovery entry of the hypervisor layer of the first processing module. Exemplarily, the correspondence between the FIQ events of one or more virtual machines (VMs) and the SDEI events stored in the ATF layer is saved after the watchdog interrupt is configured as a FIQ interrupt, and the correspondence between the SDEI event and the first fault recovery entry of the hypervisor layer of the first processing module can be the first fault recovery entry of the hypervisor layer of the first processing module corresponding to the SDEI event pre-registered by the hypervisor layer to the ATF layer stored in the ATF layer.

[0064] Based on the system architecture shown in Figure 3, taking the fault identification module as a watchdog as an example, when a VM fails, it will not be able to "feed the dog" in time, thereby triggering the watchdog interrupt corresponding to the VM. After identifying the FIQ interrupt, the ATF layer can determine the SDEI event corresponding to the FIQ event of the VM based on the correspondence between the saved FIQ interrupt (i.e., the "FIQ event" described below) and the SDEI event, and determine the first fault recovery entry corresponding to the SDEI event, and then jump to the hypervisor layer through the first fault recovery entry, and restore the faulty VM through the first fault recovery module at the hypervisor layer (referred to as "first recovery"). Among them, the ATF layer can follow but is not limited to the SDEI mechanism when jumping to the hypervisor layer.

[0065] If the first recovery is successful, the first fault recovery module of the hypervisor layer notifies the ATF layer of the successful fault recovery. For example, the processing core of the first processing module can jump from the hypervisor layer to the ATF layer, such as following the SDEI mechanism to jump from the hypervisor layer to the ATF layer. If the first recovery fails, as shown in Figure 3, the first fault recovery module can jump to the SOS layer according to the second fault recovery entry of the SOS layer corresponding to the saved SDEI event, and recover the faulty VM at the SOS layer through the second fault recovery module (referred to as "second recovery"). If the second recovery is successful, the SOS layer notifies the ATF layer of the successful fault recovery through the hypervisor layer.

[0066] Based on the architecture shown in Figure 3, the electronic device can directly process watchdog FIQ events at the ATF layer. For example, it follows the SDEI mechanism and jumps to the hypervisor layer for the first automated fault response based on the first fault recovery entry corresponding to the SDEI event corresponding to the FIQ event. If the hypervisor layer fault response fails, it continues to follow the SDEI mechanism and jumps to the SOS layer for the second automated fault response based on the second fault recovery entry corresponding to the SDEI event. Based on this, not only can the conventional IRQ mechanism's problems of being easily blocked and maliciously attacked, resulting in the inability to promptly identify and handle virtual machine faults, as well as security issues, be resolved, ensuring that any VM failure will not affect the operation of other normal VMs, but it can also ensure the timeliness, speed, and reliability of automated fault response through the dual recovery mechanisms of the hypervisor layer and the SOS layer.

[0067] It should be noted that Figure 3 is only an example of a possible system architecture for an electronic device. The embodiments of the present application do not specifically limit some details, which may depend on the specific application scenario, device structure and function, etc. For example, please refer to Figure 4. Figure 4 takes the smart car field as an example to show a schematic diagram of a system architecture for deploying multiple virtual machines on a single chip provided by an embodiment of the present application. As shown in Figure 4, the instrument domain and the cockpit domain can be used as UOS, and the smart driving domain can be used as SOS and deployed with a second fault recovery module. Based on this, when a UOS fails (Figure 4 takes the failure of the cockpit domain VM as an example), a mechanism similar to that shown in Figure 3 can also be used to automatically respond to the fault.

[0068] In addition, Figures 3 and 4 only take the failure of a certain UOS (Figure 3 takes the failure of UOS1 as an example, and Figure 4 takes the failure of the cockpit domain as an example) as an example to introduce a fault automation response process provided by an embodiment of the present application. In actual applications, if any UOS (UOS0 as shown in Figure 3 and the instrument domain as shown in Figure 4) fails, a mechanism similar to that shown in Figure 3 or Figure 4 can be used to perform fault automation response.

[0069] The following will take the system architecture shown in Figure 3 as an example to specifically introduce the fault handling method of the device provided in the embodiment of the present application.

[0070] Please refer to Figure 5, which shows a flow chart of a method for troubleshooting a device provided in an embodiment of the present application. As shown in Figure 5, the method for troubleshooting a device provided in an embodiment of the present application can be implemented based on S501-S506, or based on S501-S505 and S507-S509:

[0071] S501: The SOS layer of the first processing module registers the SDEI event of the target object (UOS) and the second fault recovery entry of the SOS layer of the first processing module corresponding to the SDEI event with the hypervisor layer.

[0072] The second fault recovery entry of the SOS layer corresponding to the SDEI event is used by the hypervisor layer to jump to the SOS layer through the entry to perform fault recovery of the UOS, such as the second recovery.

[0073] As a possible implementation, the first processing module can initiate an event registration process, such as an SDEI event registration process, at the SOS layer. For example, the event registration process can be initiated through, but not limited to, an SMC instruction or an HVC instruction, to register the SDEI event of the target object (UOS) and the second fault recovery entry of the SOS layer of the first processing module corresponding to the SDEI event with the hypervisor layer. Based on this, the hypervisor layer saves second configuration information according to the registration instruction. The second configuration information includes the SDEI event of the target object (UOS), the correspondence between the SDEI event and the second fault recovery entry of the SOS layer of the first processing module.

[0074] In some embodiments, before executing S501, the SOS layer of the first processing module may further instruct the ATF layer through the hypervisor layer to configure the watchdog interrupt corresponding to the target object (UOS) as a FIQ type. After configuring the watchdog interrupt corresponding to the UOS as a FIQ type, the ATF layer returns the SDEI event corresponding to the FIQ event to the SOS layer of the first processing module through the hypervisor layer, and the ATF layer may save the correspondence between the FIQ event and the SDEI event. Based on this, when executing S501, the SOS layer of the first processing module may register the SDEI event and its corresponding second fault recovery entry of the SOS layer of the first processing module with the hypervisor layer based on the SDEI event returned by the ATF, and the hypervisor layer saves the correspondence between the SDEI event and the second fault recovery entry of the SOS layer of the first processing module.

[0075] S502: The hypervisor layer of the first processing module registers a first fault recovery entry of the hypervisor layer of the first processing module corresponding to the SDEI event of the target object (UOS) with the ATF layer.

[0076] The first fault recovery entry of the hypervisor layer corresponding to the SDEI event of the target object (UOS) is used by the ATF layer to jump to the hypervisor layer through the entry to perform fault recovery of the UOS, such as the first recovery.

[0077] As a possible implementation manner, the ATF layer may save the first configuration information according to the registration instruction of the hypervisor layer, where the first configuration information includes a correspondence between the SDEI event and the first fault recovery entry of the hypervisor layer of the first processing module.

[0078] As an example, the hypervisor layer of the first processing module may include a first fault recovery module, and the hypervisor layer of the first processing module may save the second configuration information in but not limited to the first fault recovery module; the ATF layer of the first processing module may include a fast interrupt processing module, and the ATF layer of the first processing module may save the first configuration information in but not limited to the fast interrupt processing module.

[0079] S503: The ATF layer of the first processing module receives and processes the first FIQ event from the fault identification module.

[0080] The fault identification module is used to track the running status of each virtual machine (VM) and report to the ATF layer of the first processing module through an FIQ event when the running status of a virtual machine (VM) is abnormal.

[0081] For example, the fault identification module may include, but is not limited to, a watchdog. For example, if the fault identification module is a watchdog, if a second processing module (UOS) fails, the watchdog may not be fed in time, thereby triggering a watchdog interrupt corresponding to the second processing module (UOS). For example, if the ATF layer of the first processing module includes a fast interrupt processing module, after receiving the FIQ interrupt, the fast interrupt processing module in the ATF layer of the first processing module will process the FIQ interrupt.

[0082] S504: The ATF layer of the first processing module determines a first SDEI event corresponding to the first FIQ event and a first fault recovery entry of the hypervisor layer corresponding to the first SDEI event.

[0083] As an example, the ATF layer of the first processing module may determine the first SDEI event corresponding to the first FIQ event according to the stored correspondence between the FIQ event and the SDEI event.

[0084] As an example, the ATF layer of the first processing module may determine the first fault recovery entry of the hypervisor layer corresponding to the first SDEI event according to the stored first configuration information.

[0085] S505: In response to the first FIQ event, the ATF layer of the first processing module jumps to the hypervisor layer to perform a first recovery on the second processing module.

[0086] As an example, the ATF layer of the first processing module may follow, but is not limited to, the SDEI mechanism to jump to the hypervisor layer to perform the first recovery on the second processing module.

[0087] As an example, the ATF layer of the first processing module can follow but is not limited to the SDEI mechanism, and jump to the hypervisor layer through the first fault recovery entry of the hypervisor layer corresponding to the first SDEI event to perform a first recovery on the second processing module. For example, when jumping to the hypervisor layer through the first fault recovery entry, the ATF layer can implement the jump to the hypervisor layer through the ERET instruction. Among them, the hypervisor layer is pre-configured with a correspondence between the SDEI event and the target object (UOS). For example, the correspondence may be configured in the hypervisor layer when the system is started, and there is no limitation; the hypervisor layer can determine that its corresponding target object is the second processing module based on the first SDEI event, and then perform a first recovery on the second processing module.

[0088] In some embodiments, the hypervisor layer of the first processing module performs the first recovery on the second processing module, including powering off the second processing module to ensure safety.

[0089] In some embodiments, the hypervisor layer of the first processing module performs a first recovery on the second processing module, including powering off the second processing module and then restoring the second processing module, to ensure that the second processing module can function normally while ensuring security. For example, the second processing module can be restored by loading a system image file of the second processing module and then powering on a processing core of the second processing module.

[0090] As a possible implementation, the hypervisor layer of the first processing module may perform a first recovery on the second processing module by following steps 1 to 3:

[0091] Step 1: The hypervisor layer of the first processing module powers off the processing core of the second processing module.

[0092] As a possible implementation, the ATF layer of the first processing module may jump (eg, following the SDEI mechanism) to the hypervisor layer of the first processing module, and all processing cores of the second processing module may be powered on at the hypervisor layer.

[0093] As an example, the first processing module may instruct all processing cores of the second processing module to power off by sending an inter-core interrupt command at the hypervisor layer. The inter-core interrupt command may include but is not limited to an IPI_CPU_CRASH_STOP inter-core interrupt command.

[0094] In the embodiment of the present application, the second processing module may include one processing core or multiple processing cores, without specific limitation.

[0095] Step 2: The hypervisor layer of the first processing module loads the system image file of the second processing module from the system disk or file system to the memory.

[0096] As an example, the system image file of the second processing module is stored in a system disk or a file system of a hypervisor layer when the electronic device installs or updates the second processing module.

[0097] Step 3: The hypervisor layer of the first processing module powers on the main processing core of the second processing module.

[0098] As an example, the hypervisor layer of the first processing module may call a power state coordination interface (PSCI) to instruct the main processing core of the second processing module to power on.

[0099] The second processing module may include one processing core or multiple processing cores, without specific limitation. When the second processing module includes multiple processing cores, the multiple processing cores may also include a master processing core and slave processing cores, without specific limitation.

[0100] For example, if the second processing module includes multiple processing cores, including a master processing core and slave processing cores (e.g., one or more slave processing cores), the hypervisor layer of the first processing module can instruct (e.g., by calling PSCI) the master processing core of the second processing module to power on. After powering on the master processing core of the second processing module, the master processing core of the second processing module will then power on all the slave processing cores of the second processing module. Consequently, after all the processing cores of the second processing module are powered on, the second processing module successfully recovers and can operate normally.

[0101] In this way, by first powering off all the processing cores of the second processing module, and then reloading the system image file of the second processing module from the system disk or file system (such as the file system of the hypervisor layer) to the memory, and then powering on the main processing core of the second processing module and pulling up all the slave processing cores of the second processing module through the main processing core, the purpose of restoring the second processing module can be achieved, so as to solve the problem of the second processing module not being able to work normally due to a failure.

[0102] As a possible scenario, the hypervisor layer of the first processing module successfully performs the first recovery of the second processing module. In this case, the first processing module successfully responds to the first SDEI event, and the first processing module may execute S506.

[0103] S506: The hypervisor layer of the first processing module jumps to the ATF layer, and restores the context of the SOS layer of the first processing module at the ATF layer.

[0104] The context of the SOS layer of the first processing module is saved before the first recovery. As an example, the context of the SOS layer of the first processing module is saved in the ATF layer of the first processing module after the ATF layer of the first processing module receives the first FIQ event.

[0105] It can be understood that when the first FIQ event is received, the processing core of the first processing module jumps from the ATF layer to the hypervisor layer according to the first configuration information to process the SDEI event corresponding to the FIQ event. After the hypervisor layer of the first processing module successfully recovers the second processing module, the processing core of the first processing module needs to jump back from the hypervisor layer to the ATF layer to restore the context of the SOS layer of the first processing module at the ATF layer.

[0106] As one possible scenario, the hypervisor layer of the first processing module fails in the first recovery of the second processing module. Exemplarily, the first recovery failure may include, but is not limited to, any of the following: failure to power off the second processing module, failure to load the system image file of the second processing module, or failure to power on the second processing module.

[0107] In some embodiments, if the first processing module fails to perform the first recovery of the second processing module through the hypervisor layer, as shown in FIG5 , the fault handling method of the device provided in the embodiment of the present application may further include S507-S508:

[0108] S507: The hypervisor layer of the first processing module jumps to the SOS layer, and performs a second recovery on the second processing module at the SOS layer.

[0109] As an example, the hypervisor layer of the first processing module may follow, but is not limited to, the SDEI mechanism to jump to the SOS layer to perform a second recovery on the second processing module.

[0110] As an example, the hypervisor layer of the first processing module can follow, but not be limited to, the SDEI mechanism and, based on the stored second configuration information, determine the second fault recovery entry of the SOS layer of the first processing module corresponding to the SDEI event. The hypervisor layer then uses this entry to jump to the SOS layer and perform a second recovery of the second processing module. For example, when jumping to the SOS layer through the second fault recovery entry, the hypervisor layer can implement the jump to the SOS layer using an ERET instruction.

[0111] S508: The SOS layer of the first processing module performs a second recovery on the second processing module.

[0112] In some embodiments, performing a second recovery on the second processing module includes powering off the second processing module to ensure safety.

[0113] In some embodiments, performing a second recovery on the second processing module includes powering off the second processing module and then resuming the operation of the second processing module, thereby ensuring that the second processing module can still function normally while ensuring security. For example, the operation of the second processing module can be restored by loading a system image file of the second processing module and then powering on the processing core of the second processing module.

[0114] As a possible implementation, the SOS layer of the first processing module can perform a second recovery on the second processing module through the following steps A to C:

[0115] Step A: The SOS layer of the first processing module powers off the processing core of the second processing module.

[0116] As an example, the SOS layer of the first processing module can jump to the hypervisor layer of the first processing module. The first processing module instructs all processing cores of the second processing module to power off by sending an inter-core interrupt command at the hypervisor layer. The inter-core interrupt command may include but is not limited to the IPI_CPU_CRASH_STOP inter-core interrupt command. For example, the SOS layer of the first processing module can jump to the hypervisor layer of the first processing module using, but not limited to, an HVC instruction or an SMC instruction.

[0117] As an example, the first processing module may also instruct all processing cores of the second processing module to power off by directly sending an inter-core interrupt command (such as an IPI_CPU_CRASH_STOP inter-core interrupt command) at the SOS layer.

[0118] Step B: The SOS layer of the first processing module loads the system image file of the second processing module from the system disk or file system to the memory.

[0119] As an example, the system image file of the second processing module is stored in the system disk or the file system of the SOS layer of the first processing module when the electronic device installs or updates the second processing module.

[0120] Step C: The SOS layer of the first processing module powers on the main processing core of the second processing module.

[0121] As an example, the SOS layer of the first processing module may instruct the main processing core of the second processing module to power on.

[0122] As an example, the SOS layer of the first processing module may instruct the hypervisor layer to call the VMM_PSCICpuOn interface to power on the main processing core of the second processing module through the PSCI interface.

[0123] The second processing module may include one processing core or multiple processing cores, without specific limitation. When the second processing module includes multiple processing cores, the multiple processing cores may also include a master processing core and slave processing cores, without specific limitation.

[0124] For example, if the second processing module includes multiple processing cores, including a master processing core and slave processing cores (e.g., one or more slave processing cores), the SOS layer of the first processing module can jump to the hypervisor layer to instruct (e.g., by calling the VMM_PSCICpuOn interface) the master processing core of the second processing module to power on. After the master processing core of the second processing module is powered on, the master processing core of the second processing module powers on all the slave processing cores of the second processing module. Consequently, after all the processing cores of the second processing module are powered on, the second processing module successfully recovers and can operate normally.

[0125] In this way, by first powering off all the processing cores of the second processing module, and then reloading the system image file of the second processing module from the system disk or file system (such as the file system of the SOS layer) to the memory, and then powering on the main processing core of the second processing module and pulling up all the slave processing cores of the second processing module through the main processing core, the purpose of restoring the second processing module can be achieved, so as to solve the problem of the second processing module not being able to work normally due to a failure.

[0126] As a possible scenario, the SOS layer of the first processing module successfully performs the second recovery of the second processing module. In this case, the first processing module successfully responds to the first SDEI event, and the first processing module may execute S509.

[0127] S509: The SOS layer of the first processing module jumps to the hypervisor layer, the hypervisor layer jumps to the ATF layer, and the context of the SOS layer of the first processing module is restored at the ATF layer.

[0128] The context of the SOS layer of the first processing module is saved before the first recovery is performed, such as the context of the ATF layer of the first processing module is saved in the ATF layer of the first processing module after the ATF layer of the first processing module receives the first FIQ event.

[0129] As an example, please refer to Figure 6. Figure 6 shows a schematic diagram of a process in which a first processing module performs a first recovery on a second processing module, provided in an embodiment of the present application, using an example in which the first processing module includes, from top to bottom, an SOS layer, a Hypervisor layer, an ATF layer, and the second processing module is a UOS layer. As shown in Figure 6, the fault handling method of the device provided in an embodiment of the present application can be implemented based on S601-S606:

[0130] S601: The SOS layer of the first processing module registers the SDEI event of the target object (UOS) and the second fault recovery entry of the SOS layer of the first processing module corresponding to the SDEI event with the hypervisor layer through the OS_SDEISmccEventRegister interface.

[0131] Among them, the second fault recovery entry of the SOS layer corresponding to the SDEI event of the target object (UOS) is used for the hypervisor layer to jump to the SOS layer through the entry to perform fault recovery of the UOS, such as the second recovery.

[0132] As an example, the first processing module can initiate an event registration process, such as the SDEI event registration (SDEI_EVENT_REGISTER) process, through the OS_SDEISmccEventRegister interface at the SOS layer. For example, the event registration process can be initiated through but not limited to STD SMC instructions, HVC instructions, etc. (Figure 6 takes STD SMC instructions as an example) to register the SDEI event of the target object (UOS) and the second fault recovery entry of the SOS layer of the first processing module corresponding to the SDEI event to the hypervisor layer.

[0133] As a possible implementation method, as shown in Figure 6, the hypervisor layer of the first processing module saves the second configuration information through the VMM_SDEISmccEventRegister interface according to the registration instruction of the SOS layer, such as saving the SDEI event of the target object (UOS) and the correspondence between the SDEI event and the second fault recovery entry of the SOS layer of the first processing module.

[0134] In some embodiments, before executing S601, the SOS layer of the first processing module may further instruct the ATF layer through the hypervisor layer to configure the watchdog interrupt corresponding to the target object (UOS) as a FIQ type. After configuring the watchdog interrupt corresponding to the UOS as a FIQ type, the ATF layer returns the SDEI event corresponding to the FIQ event to the SOS layer of the first processing module through the hypervisor layer, and the ATF layer may save the correspondence between the FIQ event of the UOS and the SDEI event. Based on this, when executing S601, the SOS layer of the first processing module may register the SDEI event and the second fault recovery entry of the SOS layer of the first processing module corresponding to the SDEI event with the hypervisor layer according to the SDEI event returned by the ATF, and the hypervisor layer saves the correspondence between the SDEI event and the second fault recovery entry of the SOS layer of the first processing module based on this.

[0135] S602: The hypervisor layer of the first processing module registers a first fault recovery entry of the hypervisor layer of the first processing module corresponding to the SDEI event with the ATF layer through the VMM_SDEISmccEventRegister interface.

[0136] As a possible implementation, the hypervisor layer can register the first fault recovery entry of the hypervisor layer of the first processing module corresponding to the SDEI event with the ATF layer of the first processing module through the STD SMC instruction. As shown in Figure 6, the ATF layer of the first processing module can sequentially call sdei_smc_handler and sdei_event_register to complete the registration and save the first configuration information, such as the correspondence between the SDEI event and the first fault recovery entry of the hypervisor layer of the first processing module.

[0137] S603: The ATF layer of the first processing module receives and processes the first FIQ event from the fault identification module (such as the watchdog) through the sdei_dispatch_event interface.

[0138] Among them, the fault identification module (such as a watchdog) is used to follow up the running status of each virtual machine (VM) and report to the ATF layer of the first processing module through an FIQ event when the running status of a virtual machine (VM) is abnormal.

[0139] For example, if the fault identification module is a watchdog, if a second processing module (UOS) fails, it will not be able to "feed the watchdog" in time, thereby triggering the watchdog FIQ interrupt corresponding to the second processing module (UOS). For example, if the ATF layer of the first processing module includes a fast interrupt processing module, after receiving the FIQ interrupt, the fast interrupt processing module in the ATF layer of the first processing module will process the FIQ interrupt.

[0140] As shown in FIG6 , when the UOS times out and fails to “feed the dog”, the FIQ interrupt of the UOS is triggered; correspondingly, the ATF layer of the first processing module processes the FIQ interrupt through the sdei_dispatch_event interface.

[0141] S604: In response to the first FIQ event, the sdei_dispatch_event interface of the ATF layer of the first processing module jumps to the hypervisor layer to perform a first recovery on the second processing module.

[0142] As an example, the sdei_dispatch_event interface of the ATF layer can determine the first SDEI event corresponding to the received first FIQ event, and determine the first fault recovery entry of the hypervisor layer corresponding to the first SDEI event based on the saved first configuration information. Then, the ATF layer of the first processing module can follow but not be limited to the SDEI mechanism and jump to the hypervisor layer through the first fault recovery entry to perform a first recovery on the second processing module. For example, when jumping to the hypervisor layer through the first fault recovery entry, the ATF layer can implement the jump to the hypervisor layer through but not limited to the ERET instruction shown in Figure 6. Among them, the hypervisor layer is pre-configured with a correspondence between the SDEI event and the target object (UOS). For example, the correspondence may be configured in the hypervisor layer when the system is started, which is not limited; the hypervisor layer can determine that its corresponding target object is the second processing module based on the first SDEI event, and then perform a first recovery on the second processing module.

[0143] When performing the first recovery on the second processing module, as an example, the hypervisor layer of the first processing module may perform the first recovery on the second processing module in sequence through the VMM_SDEIEntryPoint interface, the VMM_SDEIEventHandler interface, the VMM_RecoverVM and the VMM_PSCICpuOn interface.

[0144] As a possible implementation method, the hypervisor layer of the first processing module can power off all processing cores of the second processing module, load the system image file of the second processing module from the system disk or file system (such as the file system of the hypervisor layer) to the memory, and instruct the main processing core of the second processing module to power on.

[0145] As a possible implementation, taking as an example a first processing module including a master processing core (such as processing core 0) and slave processing cores (such as processing core 1, processing core 2, and processing core 3), and a second processing module including a master processing core (such as processing core 4) and slave processing cores (such as processing core 5, processing core 6, and processing core 7), the hypervisor layer of the first processing module can perform a first recovery on the second processing module by following steps 1 to 3:

[0146] Step 1: The hypervisor layer of the first processing module powers off the multiple processing cores of the second processing module through the VMM_RecoverVM interface.

[0147] As an example, as shown in Figure 7, the VMM_RecoverVM interface of the hypervisor layer of the first processing module can send an inter-core interrupt command through processing core 0 to instruct multiple processing cores (such as processing core 4, processing core 5, processing core 6, and processing core 7) of the second processing module to power off. The inter-core interrupt command may include but is not limited to the IPI_CPU_CRASH_STOP inter-core interrupt command shown in Figure 7.

[0148] Step 2: The hypervisor layer of the first processing module loads the system image file of the second processing module from the system disk or file system (such as the file system of the hypervisor layer) to the memory through the VMM_RecoverVM interface.

[0149] As an example, the system image file of the second processing module is stored in a system disk or a file system of a hypervisor layer when the electronic device installs or updates the second processing module.

[0150] Step 3: The hypervisor layer of the first processing module powers on the main processing core of the second processing module through the VMM_RecoverVM and VMM_PSCICpuOn interfaces in sequence.

[0151] As an example, the hypervisor layer of the first processing module powers on the main processing core of the second processing module, which may include: the hypervisor layer of the first processing module jumps to the ATF layer through the PSCI interface call, and instructs the main processing core of the second processing module to power on through the cpu_pm_module interface in the ATF layer.

[0152] As an example, when powering on the processing cores of the second processing module, the hypervisor layer of the first processing module can instruct the master processing core (e.g., processing core 4) of the second processing module to power on. After the master processing core (e.g., processing core 4) of the second processing module is powered on, the master processing core (e.g., processing core 4) of the second processing module powers on all slave processing cores (e.g., processing cores 5, 6, and 7) of the second processing module. Consequently, after all processing cores of the second processing module are powered on, the second processing module successfully recovers and can operate normally.

[0153] As a possible scenario, the hypervisor layer of the first processing module successfully performs the first recovery of the second processing module. In this case, the first processing module successfully responds to the first SDEI event, and the first processing module can execute S605 and S606.

[0154] S605: The hypervisor layer of the first processing module jumps to the ATF layer through the VMM_SDEIEntryPoint interface, and restores the context of the SOS layer of the first processing module at the ATF layer.

[0155] The context of the SOS layer of the first processing module is saved before the first recovery. As an example, the context of the SOS layer of the first processing module is saved in the ATF layer of the first processing module after the ATF layer of the first processing module receives the first FIQ event.

[0156] S606: The ATF layer of the first processing module restores the context of the SOS layer of the first processing module through the sdei_smc_handler interface.

[0157] As a possible implementation, the hypervisor layer of the first processing module sends an SDEI_EVENT_COMPLETE command to the ATF layer through the VMM_SDEIEntryPoint interface to notify the ATF layer of the success of the first recovery. After receiving the SDEI_EVENT_COMPLETE command, the ATF layer restores the context of the SOS layer of the first processing module.

[0158] As a possible implementation manner, after the ATF layer receives the SDEI_EVENT_COMPLETE command from the hypervisor layer, the ATF layer sequentially calls the sdei_smc_handler interface and the sdei_event_complete interface to restore the context of the SOS layer of the first processing module.

[0159] As one possible scenario, the hypervisor layer of the first processing module fails in the first recovery of the second processing module. Exemplarily, the first recovery failure may include, but is not limited to, any of the following: failure to power off the second processing module, failure to load the system image file of the second processing module, or failure to power on the second processing module.

[0160] In some embodiments, if the first processing module fails to perform the first recovery of the second processing module through the hypervisor layer, such as a failure to power off the second processing module, a failure to load the system image file of the second processing module, or a failure to power on the second processing module, as shown in FIG8 , the fault handling method of the device provided in the embodiment of the present application may further include S607-S610:

[0161] S607: The hypervisor layer of the first processing module jumps to the SOS layer, and performs a second recovery on the second processing module at the SOS layer.

[0162] As an example, the VMM_RecoverVM interface of the hypervisor layer of the first processing module can determine the second fault recovery entry of the SOS layer corresponding to the SDEI event based on the saved second configuration information, and then jump to the SOS layer through this entry to perform a second recovery of the second processing module. For example, the hypervisor layer can implement the jump to the SOS layer using the ERET instruction shown in Figure 8.

[0163] S608: The SOS layer of the first processing module performs a second recovery on the second processing module through the OS_SDEIEntryPoint interface, the OS_SDEIEventHandler interface, and the OS_RecoverVM interface in sequence.

[0164] As a possible implementation method, the SOS layer of the first processing module can first power off all processing cores of the second processing module through the OS_RecoverVM interface, and then load the system image file of the second processing module from the system disk or file system (such as the file system of the SOS layer) to the memory, and instruct the main processing core of the second processing module to power on.

[0165] As a possible implementation, taking the example of a first processing module including a master processing core (such as processing core 0) and slave processing cores (such as processing core 1, processing core 2, and processing core 3), and a second processing module including a master processing core (such as processing core 4) and slave processing cores (such as processing core 5, processing core 6, and processing core 7), the SOS layer of the first processing module can perform a second recovery on the second processing module through the following steps A to C:

[0166] Step A: The SOS layer of the first processing module powers off all processing cores of the second processing module through the OS_RecoverVM interface.

[0167] As an example, as shown in Figure 9, the main processing core of the first processing module can jump to the hypervisor layer of the first processing module through SMC instructions, HVC instructions, etc. at the SOS layer, and then send an inter-core interrupt command at the hypervisor layer to instruct all processing cores of the second processing module (such as processing core 4, processing core 5, processing core 6, processing core 7) to power off. The inter-core interrupt command may include but is not limited to the IPI_CPU_CRASH_STOP inter-core interrupt command shown in Figure 9.

[0168] As an example, the main processing core of the first processing module can also directly instruct all processing cores (such as processing core 4, processing core 5, processing core 6, processing core 7) of the second processing module to power off by sending an inter-core interrupt command (IPI_CPU_CRASH_STOP inter-core interrupt command) at the SOS layer.

[0169] Step B: The SOS layer of the first processing module loads the system image file of the second processing module from the system disk or file system to the memory by calling the OS_RecoverVM interface.

[0170] As an example, the system image file of the second processing module is stored in the system disk or the file system of the SOS layer of the first processing module when the electronic device installs or updates the second processing module.

[0171] Step C: The SOS layer of the first processing module powers on the main processing core of the second processing module by calling the OS_RecoverVM interface.

[0172] As an example, the OS_RecoverVM interface of the SOS layer may jump to the hypervisor layer by calling a PSCI command, and the hypervisor layer may power on the main processing core of the second processing module through the VMM_PSCICpuOn interface.

[0173] As an example, when powering on the main processing core of the second processing module, the hypervisor layer can call the VMM_PSCICpuOn interface to instruct the ATF layer to power on the main processing core of the second processing module (such as processing core 4) through cpu_pm_module. After powering on the main processing core of the second processing module (such as processing core 4), the main processing core of the second processing module (such as processing core 4) will power on all the slave processing cores of the second processing module (such as processing core 5, processing core 6, and processing core 7). Based on this, after all the processing cores of the second processing module are powered on, the second processing module recovers successfully and can then operate normally.

[0174] As a possible scenario, the SOS layer of the first processing module successfully performs the second recovery of the second processing module. In this case, the first processing module successfully responds to the first SDEI event, and the first processing module may execute S609.

[0175] S609: The SOS layer of the first processing module notifies the hypervisor layer of the success of the second recovery through an SDEI_EVENT_COMPLETE command.

[0176] As an example, if the second recovery is successful, the SOS layer of the first processing module sends the SDEI_EVENT_COMPLETE command through the OS_SDEIEntryPoint interface to notify the hypervisor layer that the second recovery of the first SDEI event is successful. Then, the hypervisor layer calls the VMM_SDEIEventComplete interface, VMM_SDEIEventHandler interface and VMM_SDEIEntryPoint interface in sequence according to the SDEI_EVENT_COMPLETE command from the SOS layer to send the SDEI_EVENT_COMPLETE command to the ATF layer to notify the ATF layer that the second recovery is successful.

[0177] S610: After receiving the SDEI_EVENT_COMPLETE command, the ATF layer of the first processing module restores the context of the SOS layer of the first processing module. The context of the SOS layer of the first processing module is saved before the first restoration. For example, the context of the SOS layer of the first processing module is saved in the ATF layer of the first processing module after the ATF layer of the first processing module receives the first FIQ event.

[0178] As a possible implementation manner, after receiving the SDEI_EVENT_COMPLETE command from the hypervisor layer, the ATF layer may sequentially call the sdei_smc_handler interface and the sdei_event_complete interface to restore the context of the SOS layer of the first processing module.

[0179] For a detailed description of S609 and S610, please refer to the above descriptions of S605 and S606 respectively, which will not be repeated here.

[0180] As one possible scenario, the SOS layer of the first processing module fails to perform a second recovery of the second processing module. Exemplarily, the second recovery failure may include, but is not limited to, any of the following: a failure to power off the second processing module, a failure to load the system image file of the second processing module, or a failure to power on the second processing module.

[0181] In some embodiments, if the first processing module fails to perform the second recovery of the second processing module through the SOS layer, the first processing module may remind the user, including but not limited to voice prompts, pop-up reminders, etc., without specific limitation.

[0182] It should be noted that, in addition to automatically responding to FIQ events of the second processing module, the first processing module can also automatically respond to FIQ events corresponding to the SOS layer of the first processing module, such as restoring the SOS layer of the first processing module. For example, as shown in FIG10 , the fault handling method of the device provided in the embodiment of the present application can be implemented based on S1001-S1005:

[0183] S1001: The SOS layer of the first processing module registers an SDEI event of the SOS with the hypervisor layer.

[0184] As a possible implementation, the first processing module can initiate an event registration process, such as an SDEI event registration process, at the SOS layer. For example, the event registration process can be initiated through an SMC instruction or an HVC instruction to register the SOS SDEI event with the hypervisor layer. Based on this, the hypervisor layer saves the SOS SDEI event according to the registration instruction.

[0185] In some embodiments, before executing S1001, the SOS layer of the first processing module may further instruct the ATF layer, through the hypervisor layer, to configure the watchdog interrupt corresponding to the SOS as a FIQ type. After configuring the watchdog interrupt corresponding to the SOS as a FIQ type, the ATF layer returns the SDEI event corresponding to the FIQ event to the SOS layer of the first processing module through the hypervisor layer, and the ATF layer may save the correspondence between the FIQ event and the SDEI event. Based on this, when executing S1001, the SOS layer of the first processing module may register the SDEI event of the SOS with the hypervisor layer based on the SDEI event returned by the ATF.

[0186] As an example, please refer to Figure 11. Figure 11 shows a schematic diagram of a process for restoring SOS by a first processing module provided by an embodiment of the present application, taking the first processing module including, from top to bottom, an SOS layer, a hypervisor layer, and an ATF layer as an example. As shown in Figure 11, S1001 may specifically include: the SOS layer of the first processing module may initiate an event registration process, such as an SDEI event registration (SDEI_EVENT_REGISTER) process, via the OS_SDEISmccEventRegister interface.

[0187] S1002: The hypervisor layer of the first processing module registers a first fault recovery entry of the hypervisor layer of the first processing module corresponding to the SDEI event of the SOS with the ATF layer.

[0188] The first fault recovery entry of the hypervisor layer corresponding to the SDEI event of the SOS is used by the ATF layer to jump to the hypervisor layer through the entry to perform SOS fault recovery, such as the first recovery.

[0189] As an example, the ATF layer of the first processing module may include a fast interrupt processing module. After registration is completed, the first configuration information is saved in the ATF layer of the first processing module. The first configuration information includes the correspondence between the SDEI event and the first fault recovery entry of the hypervisor layer of the first processing module.

[0190] As a possible implementation, as shown in FIG11 , the hypervisor layer of the first processing module can register the first fault recovery entry of the hypervisor layer of the first processing module corresponding to the SDEI event of the SOS with the ATF layer of the first processing module via the VMM_SDEISmccEventRegister interface based on the registration instruction of the SOS layer. As shown in FIG11 , the ATF layer of the first processing module can sequentially call sdei_smc_handler and sdei_event_register to complete the registration and save the first configuration information, such as the correspondence between the SDEI event of the SOS and the first fault recovery entry of the hypervisor layer of the first processing module.

[0191] S1003: The ATF layer of the first processing module receives a second FIQ event from the fault identification module.

[0192] The fault identification module is used to track the operating status of each virtual machine (VM) and report to the ATF layer of the first processing module through an FIQ event when the operating status of a virtual machine (such as SOS) is abnormal. Exemplarily, the fault identification module may include but is not limited to a watchdog.

[0193] As shown in FIG11 , when the SOS times out and is not “fed”, the FIQ interrupt corresponding to the SOS is triggered; correspondingly, the ATF layer of the first processing module can process the FIQ interrupt through the sdei_dispatch_event interface.

[0194] S1004: The ATF layer of the first processing module determines a second SDEI event corresponding to the second FIQ event and a first fault recovery entry of the hypervisor layer corresponding to the second SDEI event.

[0195] As an example, as shown in S1004 of FIG11 , the sdei_dispatch_event interface of the ATF layer of the first processing module can determine the second SDEI event corresponding to the received second FIQ event, and determine the first fault recovery entry of the hypervisor layer corresponding to the second SDEI event based on the saved first configuration information. Then, the ATF layer of the first processing module can follow, but not be limited to, the SDEI mechanism and jump to the hypervisor layer through the first fault recovery entry to perform a first recovery on the SOS layer of the first processing module. For example, when jumping to the hypervisor layer through the first fault recovery entry, the ATF layer can implement the jump to the hypervisor layer through, but not limited to, the ERET instruction shown in FIG11 . The hypervisor layer is pre-configured with a correspondence between SDEI events and target objects (SOS). For example, the correspondence may be configured in the hypervisor layer at system startup, which is not limited to this. The hypervisor layer can determine that the corresponding target object is the SOS layer of the first processing module based on the second SDEI event, and then perform a first recovery on the SOS layer of the first processing module.

[0196] S1005: The first fault recovery module of the hypervisor layer of the first processing module restores the SOS layer of the first processing module (ie, first recovery).

[0197] As an example, when restoring the SOS of the first processing module, the hypervisor layer can first power off the slave processing core of the first processing module, and then load the image file of the SOS of the first processing module from the system disk or file system (such as the file system of the hypervisor layer) into the memory, and then jump to the operating system entry (such as OS_Entry) of the newly loaded SOS image file to restart and initialize the SOS system, and pull up the slave processing core of the SOS of the first processing module.

[0198] As a possible implementation method, taking the example of the first processing module including a main processing core (such as processing core 0) and slave processing cores (such as processing core 1, processing core 2, and processing core 3), processing core 0 of the first processing module can power on processing core 1, processing core 2, and processing core 3 through the VMM_RecoverVM interface at the hypervisor layer, and then load the SOS image file from the system disk or file system (such as the file system at the hypervisor layer) into the memory, and then send the SDEI_EVENT_COMPLETE_AND_RESUME command to the ATF layer to notify the ATF layer to jump to the specified entry of the hypervisor layer. After that, processing core 0 of the first processing module jumps to the operating system entry (such as OS_Entry) of the newly loaded SOS image file, completes the restart and initialization of the SOS system, and pulls up the SOS slave processing core of the first processing module to complete the recovery of the SOS.

[0199] As an example, as shown in S1005 in Figure 11, the hypervisor layer of the first processing module sends the SDEI_EVENT_COMPLETE_AND_RESUME command to the ATF layer through the VMM_RecoverVM interface, the VMM_SDEIEventHandler interface and the VMM_SDEIEntryPoint interface in sequence to notify the ATF layer to jump to the specified entry of the hypervisor layer. For example, the SDEI_EVENT_COMPLETE_AND_RESUME command can use VMM_SDEISpecialEntry as The command is passed to the ATF layer as a parameter. After receiving the command, the ATF layer calls the sdei_smc_handler interface and the sdei_event_complete interface in sequence to jump to the VMM_SDEISpecialEntry interface of the hypervisor layer. The hypervisor layer jumps to the operating system entry (such as OS_Entry) of the newly loaded SOS image file through the VMM_ResetAndInltCpuCtx interface and the VMM_EnterVM interface in sequence to restart and initialize the SOS system, and pull up the SOS slave processing core of the first processing module.

[0200] It can be understood that the fault handling method of the device provided in the embodiment of the present application partitions and deploys the entire system according to the security and trustworthiness attributes and business scope of the business, and adopts a solution that configures the watchdog interrupt as FIQ type and combines it with the SDEI mechanism. In this solution, due to a virtual machine failure, the timeout and failure to "feed the dog" will trigger the corresponding watchdog FIQ interrupt. The ATF layer can determine the SDEI event corresponding to the FIQ event, and determine the first fault recovery entry of the hypervisor layer corresponding to the SDEI event based on the saved first configuration information. Then, through the first fault recovery entry, it jumps to the hypervisor layer for fault automation response, such as powering off all processing cores of the second processing module, loading the system image file of the second processing module, and re-powering on the main processing core of the second processing module, powering off the slave processing core of the SOS layer of the first processing module, loading the SOS image file, and re-jumping to the operating system entry of the SOS layer. Based on this, the real-time and reliability of the device's fault automation identification and processing can be improved, ensuring the reliable and safe operation of the device and the low-latency response of the watchdog interrupt. For example, compared with the conventional IRQ mechanism, the fault handling method of the device provided in the embodiment of the present application can avoid the problem of being unable to timely identify and handle virtual machine faults and security issues caused by IRQ or malicious attacks.

[0201] Furthermore, when the target object is the second processing module (UOS), the fault handling method of the device provided in the embodiment of the present application can jump to the SOS layer for automatic fault response through the second fault recovery entry of the SOS layer corresponding to the pre-registered SDEI event when the hypervisor layer fault response fails, such as powering off the second processing module (UOS), loading the system image file of the second processing module (UOS), and re-powering on the second processing module (UOS). Based on this, the reliability of the automatic fault response can be further guaranteed through the dual recovery mechanism of the hypervisor layer and the SOS layer.

[0202] It should be noted that the above embodiment only takes the SOS layer of the first processing module having the function of automatic fault response as an example. In some embodiments, if both the SOS layer of the first processing module and the second processing module (UOS) fail, the first processing module may also perform a first recovery of the second processing module based on the FIQ event for the second processing module only at the hypervisor layer.

[0203] In addition, the above embodiment only uses the example of the first processing module including the SOS layer. In some embodiments, if the first processing module does not include the SOS layer, if the second processing module (UOS) fails, the first processing module may also perform a first recovery of the second processing module based on the FIQ event for the second processing module only at the hypervisor layer. For example, in this case, the first configuration information stored in the ATF layer of the first processing module may be stored in the ATF layer according to the registration process initiated by the hypervisor layer of the first processing module.

[0204] It should be understood that the various schemes of the embodiments of the present application can be reasonably combined and used, and the explanations or descriptions of the various terms appearing in the embodiments can be referenced or explained with each other in the various embodiments, without limitation to this.

[0205] It should also be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0206] It is understandable that, in order to implement the functions of any of the above-mentioned embodiments, the electronic device includes hardware structures and / or software modules corresponding to the execution of each function. It should be easily appreciated by those skilled in the art that, in combination with the units and algorithm steps of the various examples 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. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0207] The embodiments of the present application can divide the electronic device into functional modules. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above-mentioned integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiments of the present application is schematic and is only a logical functional division. In actual implementation, other division methods may be used.

[0208] It should also be understood that the various modules in the electronic device can be implemented in software and / or hardware, without specific limitation. In other words, the device (such as a terminal device or proxy server) is presented in the form of functional modules. The "module" here can refer to an application-specific integrated circuit (ASIC), a circuit, a processor and memory that executes one or more software or firmware programs, an integrated logic circuit, and / or other devices that can provide the above-mentioned functions.

[0209] In an optional manner, when data transmission is implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is implemented in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a digital video disk (DVD)), or a semiconductor medium (e.g., a solid state disk (SSD)).

[0210] The steps of the method or algorithm described in conjunction with the embodiments of the present application can be implemented in hardware or by executing software instructions by a processor. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) memory, registers, hard disks, mobile hard disks, compact disc read-only memory (CD-ROM) or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and the storage medium can be located in an application specific integrated circuit (ASIC). In addition, the ASIC can be located in an electronic device. Of course, the processor and the storage medium can also exist as discrete components.

[0211] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

Claims

1. A method for handling a device failure, characterized in that: A first processing module is applied to an electronic device, wherein the electronic device further includes a second processing module, and the method includes: Identifying a first fast interrupt request FIQ event of the second processing module; In response to the first FIQ event, a first recovery is performed on the second processing module, where the first recovery is handled by a virtual machine supervisor layer of the first processing module.

2. The method according to claim 1, characterized in that The trusted firmware layer of the first processing module stores first configuration information, the first configuration information including a correspondence between a first software delegate exception interface SDEI event corresponding to the first FIQ event and a first fault recovery entry of a virtual machine supervisor layer of the first processing module, and performing a first recovery on the second processing module includes: Jump to the virtual machine supervisor layer through the first fault recovery entry according to the first configuration information, so as to perform the first recovery on the second processing module at the virtual machine supervisor layer.

3. The method according to claim 1 or 2, characterized in that The method further comprises: When the first recovery fails, a second recovery is performed on the second processing module, and the service operating system layer of the first processing module is responsible for the second recovery.

4. The method according to claim 3, characterized in that The virtual machine supervisor layer stores second configuration information, the second configuration information including a correspondence between the first SDEI event and a second fault recovery entry of the service operating system layer of the first processing module, and performing a second recovery on the second processing module includes: Jump to the service operating system layer through the second fault recovery entry according to the second configuration information, so as to perform the second recovery on the second processing module at the service operating system layer.

5. The method according to claim 3 or 4, characterized in that The performing a first recovery on the second processing module includes: Powering on the second processing module under the hypervisor layer; Loading the system image file of the second processing module from a system disk or a file system of the virtual machine supervisor layer to a memory at the virtual machine supervisor layer; The second processing module is powered on at the hypervisor layer.

6. The method according to claim 5, characterized in that The reasons for the first recovery failure include any of the following: Powering off the second processing module fails; Loading the system image file of the second processing module fails; Powering on the second processing module fails.

7. The method according to any one of claims 1 to 6, characterized in that When the first recovery is successful, the method further includes: Notifying the trusted firmware layer, through the virtual machine supervisor layer, that the first recovery is successful; The context of the service operating system layer is restored at the trusted firmware layer.

8. The method according to any one of claims 3 to 6, characterized in that The performing a second recovery on the second processing module includes: Power on the second processing module at the service operating system layer or the virtual machine supervisor layer, load the system image file of the second processing module from the system disk or the file system of the service operating system layer to the memory at the service operating system layer, and power on the second processing module at the service operating system layer.

9. The method according to any one of claims 1 to 6 or 8, characterized in that When the second recovery is successful, the method further includes: Notifying the virtual machine supervisor layer, through the service operating system layer, that the second recovery is successful; Notifying the trusted firmware layer, through the hypervisor layer, that the second recovery is successful; The context of the service operating system layer is restored at the trusted firmware layer.

10. The method according to any one of claims 5 to 9, characterized in that The powering off the second processing module includes: powering off a processing core of the second processing module; The powering on the second processing module includes: powering on a processing core of the second processing module.

11. The method according to claim 10, characterized in that The second processing module includes a master processing core and at least one slave processing core, and the step of powering off the processing core of the second processing module includes: powering off the master processing core and at least one slave processing core of the second processing module; The powering on the processing core of the second processing module includes: The main processing core of the second processing module is powered on, and after the main processing core of the second processing module is powered on, the at least one slave processing core of the second processing module is powered on through the main processing core of the second processing module.

12. The method according to claim 10 or 11, characterized in that The powering off the processing core of the second processing module includes: An IPI_CPU_CRASH_STOP inter-core interrupt command is sent to the processing core of the second processing module to instruct the processing core of the second processing module to power off.

13. The method according to any one of claims 1 to 12, characterized in that The first processing module includes, from top to bottom, a service operating system layer, a virtual machine supervisor layer, and a trusted firmware layer, and the second processing module is a user operating system layer.

14. The method according to any one of claims 2 to 13, characterized in that The method further comprises: identifying a second FIQ event of the first processing module, where a target object corresponding to the second FIQ event is a service operating system layer of the first processing module; In response to the second FIQ event, the service operating system layer of the first processing module is restored.

15. The method according to claim 14, characterized in that The first processing module includes a master processing core and a slave processing core, and the restoring the service operating system layer of the first processing module includes: powering off the slave processing core of the first processing module through the master processing core of the first processing module; Loading the image file of the service operating system of the first processing module from the system disk or the file system of the virtual machine supervisor layer to the memory through the virtual machine supervisor layer; Jumping the main processing core of the first processing module to the operating system entry of the service operating system layer after the newly loaded image file; The master processing core at the service operating system layer pulls up the slave processing core of the service operating system of the first processing module.

16. The method according to claim 14 or 15, characterized in that The trusted firmware layer of the first processing module stores the correspondence between FIQ events and SDEI events of one or more target objects; The identifying the first FIQ event of the second processing module includes: receiving the first FIQ event from a fault identification module, determining a first SDEI event corresponding to the first FIQ event based on a correspondence between the FIQ events of the one or more target objects and SDEI events, and determining a first fault recovery entry corresponding to the first SDEI event based on the first configuration information; The identifying of the second FIQ event of the first processing module includes: receiving the second FIQ event from the fault identification module, determining the second SDEI event corresponding to the second FIQ event based on the correspondence between the FIQ events and SDEI events of the one or more target objects, and determining the first fault recovery entry corresponding to the second SDEI event based on the first configuration information.

17. The method according to claim 16, characterized in that The fault identification module is a watchdog.

18. A processing module, characterized in that: The processing module includes: Memory for storing computer program instructions and data; A processor, configured to execute the computer program instructions to support the processing module in implementing the method according to any one of claims 1 to 17.

19. An electronic device, characterized in that: The electronic device includes: a first processing module and at least one second processing module, wherein the first processing module is configured to implement the method according to any one of claims 1 to 17.

20. A vehicle, characterized in that: The vehicle comprises an electronic device for implementing the method according to any one of claims 1-17.

21. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer program instructions, which implement the method according to any one of claims 1 to 17 when executed by a processing circuit.

22. A computer program product comprising instructions, characterized in that When the computer program product is run on a computer, the computer is caused to perform the method according to any one of claims 1 to 17.

Images