Equipment fault processing method, host, computer program product and storage medium

Abstract

The embodiment of the invention provides an equipment fault processing method, a host, a computer program product and a storage medium. The operating system of the target host can run an error report driving program after receiving an interrupt signal sent by any root interface and used for triggering an error report mechanism; based on an error report driving program, obtaining an address translation exception record from an event queue maintained by a memory management unit; if the address translation exception record points to any virtual device connected to the root interface, calling a kernel mode drive program corresponding to the virtual device through an error report drive program; and controlling the target virtual machine served by the virtual equipment to be paused based on the kernel mode driving program. Therefore, when a single virtual device has a fault, the fault domain can be accurately controlled on the virtual machine served by the faulted virtual device, so that only the virtual machine served by the faulted virtual device is suspended, and the influence on other virtual machines running on the target host can be effectively avoided.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a device fault handling method, a host, a computer program product, and a storage medium. Background Technology

[0002] Single Root I / O Virtualization (SR-IOV) is a hardware-accelerated virtualization technology that allows multiple virtual machines to access external devices on the host simultaneously, thereby improving virtual machine performance and reliability. SR-IOV presents a single external device as multiple virtual devices, providing each virtual machine with an independent physical channel. This avoids context switching between the host operating system and the virtualization layer, thus improving I / O performance and reducing I / O latency.

[0003] Currently, when a virtual device fails, the Advanced Error Reporting (AER) mechanism in the host operating system will be triggered. This mechanism will suspend all virtual machines served by the virtual devices on the root port where the failed virtual device is located. In other words, virtual machines served by non-faulty virtual devices will also be suspended indiscriminately, which seriously affects the performance of virtual machines on the host. Summary of the Invention

[0004] This application provides a device failure handling method, a host, a computer program, and a storage medium to reduce the impact of virtual device failures on the performance of virtual machines on the host.

[0005] This application provides a device fault handling method applicable to the operating system of the target host. The method includes:

[0006] Upon receiving an interrupt signal from any root interface in the target host to trigger the error reporting mechanism, the error reporting driver is executed.

[0007] Based on the error reporting driver, address translation exception records are retrieved from the event queue maintained by the memory management unit;

[0008] If the address translation error record points to any virtual device connected to the root interface, then the kernel-mode driver corresponding to the virtual device is called through the error reporting driver.

[0009] Based on the kernel-mode driver, the target virtual machine served by the virtual device is paused.

[0010] Furthermore, based on the error reporting driver, address translation exception records are retrieved from the event queue maintained by the memory management unit, including:

[0011] Based on the error reporting driver, the query interface provided by the memory management unit for querying the event queue is called;

[0012] Based on the query interface, the address translation exception record is obtained from the event queue maintained by the memory management unit.

[0013] Furthermore, the method also includes:

[0014] After the target host starts up, the event queue corresponding to the memory management unit is opened;

[0015] In the driver corresponding to the memory management unit, the query interface is configured so that the error reporting driver can call the query interface to obtain the address transfer exception record from the event queue.

[0016] Furthermore, address translation exception records are retrieved from the event queue maintained by the memory management unit, including:

[0017] Event records are read from the event queue using a consumption method;

[0018] Filter address translation exception records from the read event logs.

[0019] The memory management unit is the producer of event records in the event queue.

[0020] Furthermore, the method also includes:

[0021] If the obtained address translation error record does not point to any virtual device connected to the root interface, then the kernel-mode driver corresponding to each virtual device connected to the root interface is called through the error reporting driver.

[0022] Each kernel-mode driver invoked performs a virtual machine pause operation to pause the virtual machines served by each virtual device connected to the root interface.

[0023] Furthermore, the method also includes:

[0024] If no address translation exception record is obtained from the event queue, the kernel-mode driver corresponding to each virtual device connected to the root interface is called through the error reporting driver.

[0025] Each kernel-mode driver invoked performs a virtual machine pause operation to pause the virtual machines served by each virtual device connected to the root interface.

[0026] Furthermore, the address translation error record contains a device identifier, and the method further includes:

[0027] The error reporting driver invokes the first interface in the target host used for managing device information.

[0028] The first interface is used to determine whether the device type corresponding to the device identifier in the address translation error record is a virtual device and the determination result is fed back to the error reporting driver.

[0029] Furthermore, the address translation error record contains a device identifier, and the method further includes:

[0030] The error reporting driver invokes the second interface in the target host used to manage root interface information;

[0031] The second interface is used to determine whether the device pointed to by the device identifier in the address translation error record is connected to the root interface, and the determination result is fed back to the error reporting driver.

[0032] Furthermore, the method also includes:

[0033] If any virtual device connected to the root interface initiates a direct memory access request, the direct memory access request is forwarded to the memory management unit through the root interface;

[0034] The memory management unit performs address translation for the addresses carried in the direct memory access request;

[0035] If an address translation error occurs, the memory management unit adds an address translation error record to the event queue.

[0036] The root interface returns error information to the virtual device as a response to the direct memory access request. The error information is used to trigger the virtual device to initiate a fault handling request to the root interface.

[0037] Through the root interface, an interrupt signal is issued for the fault handling request to trigger the error reporting mechanism.

[0038] Furthermore, the memory management unit includes an input / output memory management unit or a system memory management unit.

[0039] This application also provides a host computer, including a memory, a processor, and a communication component;

[0040] The memory is used to store one or more computer instructions;

[0041] The processor is coupled to the memory and the communication component and is used to execute one or more computer instructions to perform the aforementioned device fault handling method.

[0042] This application also provides a computer-readable storage medium for storing computer instructions, which, when executed by one or more processors, cause the one or more processors to perform the aforementioned device fault handling method.

[0043] This application also provides a computer program product, including a computer program / instruction, wherein when the computer program is executed by a processor, it causes the processor to implement the aforementioned device fault handling method.

[0044] This application proposes a device failure handling scheme by modifying the error reporting driver in the target host operating system. Based on this modification, the target host operating system can run the error reporting driver after receiving an interrupt signal from any root interface to trigger the error reporting mechanism. Using the error reporting driver, it can retrieve address translation exception records from the event queue maintained by the memory management unit. If the address translation exception record points to any virtual device connected to the root interface, the error reporting driver calls the corresponding kernel-mode driver for the virtual device. Based on the kernel-mode driver, it controls the suspension of the target virtual machine served by the virtual device. Accordingly, in this application embodiment, the error reporting driver can accurately locate the failed virtual device on the root interface using the address translation exception records maintained by the memory management unit in the event queue. This allows for precise control of the fault domain on the virtual machines served by the failed virtual device when a single virtual device fails, thus suspending only the virtual machines served by the failed virtual device. This effectively avoids impacting other virtual machines running on the target host. Attached Figure Description

[0045] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0046] Figure 1 A schematic flowchart of a device fault handling method provided for an exemplary embodiment of this application;

[0047] Figure 2 A logical schematic diagram of a device fault handling method provided for an exemplary embodiment of this application;

[0048] Figure 3 A schematic diagram of a device pass-through scheme on a target host provided as an exemplary embodiment of this application;

[0049] Figure 4 A schematic diagram of a device fault handling process in an exemplary scenario provided for an exemplary embodiment of this application;

[0050] Figure 5 This is a schematic diagram of the structure of a host provided for another exemplary embodiment of this application. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0052] Before proceeding with a detailed description of the technical solutions provided in the various embodiments of this application, the following is a brief explanation of several technical concepts involved in this application.

[0053] Device pass-through is a technique that allows external devices on the host machine to be directly presented to virtual machines on the host, enabling virtual machines to directly access these external devices. External devices can be any physical device connected to the host system bus, including but not limited to network interface cards (NICs) and storage devices. External devices can also be referred to as physical bus devices (i.e., PCIe devices).

[0054] Virtual Function I / O (VFIO) is a device passthrough technology that allows virtual machines to directly access external devices, thereby improving I / O performance. VFIO provides a user-space interface and kernel-space drivers, enabling users to control and manage external devices through kernel-space drivers. This bypasses the performance bottlenecks of the virtualization layer, achieving lower latency and higher throughput. Depending on the type of device being passed through, VFIO supports two passthrough schemes: PCI passthrough and Single Root I / O Virtualization (SR-IOV). The PCI passthrough scheme presents external devices on the host machine to only one virtual machine, providing dedicated access to that machine.

[0055] SR-IOV is a hardware-based virtualization solution that can virtualize an external device into multiple virtual devices. Each virtual device can be directly passed to a virtual machine, greatly improving hardware resource utilization and virtual machine I / O performance. The virtual devices virtualized for external devices can also be called virtual bus devices (i.e., virtual PCIe devices).

[0056] The basic principle of SR-IOV technology is to utilize the special hardware functions of external devices to present them as multiple virtual devices. Each virtual device can then be directly assigned to a virtual machine on the host machine. The key to SR-IOV technology lies in the Physical Function (PF) and the Virtual Function (VF). The PF is the logical entity of the external device, responsible for managing all VFs, while the VF is the virtual device. The PF possesses all physical device resources, can divide these resources into multiple VFs, and communicates with the virtual machine through the VF's device identifier and address.

[0057] As described in the background section, when external devices on the host are directly connected to virtual machines via technologies such as SR-IOV, if a virtual device fails, the Advanced Error Reporting (AER) mechanism in the host operating system will be triggered. This mechanism will suspend all virtual machines served by virtual devices on the root port where the failed virtual device is located. In other words, virtual machines served by non-faulty virtual devices will also be suspended indiscriminately, which seriously affects the performance of virtual machines on the host.

[0058] Therefore, this application proposes a device failure handling scheme to reduce the impact of virtual device failures on the performance of virtual machines on the host.

[0059] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0060] Figure 1 This is a flowchart illustrating a device fault handling method provided as an exemplary embodiment of this application. Figure 2 This is a logical schematic diagram of a device fault handling method provided for an exemplary embodiment of this application. The method can be executed by the operating system of the target host. (Reference) Figure 1 The method may include:

[0061] Step 100: After receiving an interrupt signal from any root interface in the target host to trigger the error reporting mechanism, run the error reporting driver.

[0062] Step 101: Based on the error reporting driver, retrieve address translation exception records from the event queue maintained by the memory management unit;

[0063] Step 102: If the address translation error record points to any virtual device connected to the root interface, then the kernel-mode driver corresponding to the virtual device is called through the error reporting driver.

[0064] Step 103: Based on the kernel-mode driver, control the virtual machine serving the target virtual machine to pause.

[0065] In this embodiment, the target host can be any physical host, and external devices can be directly connected to the virtual machine using the aforementioned SR-IOV and other technologies. Figure 3 This is a schematic diagram of a device pass-through scheme on a target host, provided as an exemplary embodiment of this application. (Reference) Figure 3 The external devices on the target host have SR-IOV functionality, and each external device presents itself as multiple Virtual Functions (VFs). Furthermore, the target host has already allocated these multiple VFs to various virtual machines based on the VFIO framework. (Reference) Figure 3 Based on the VFIO framework, each VF corresponds to a kernel-mode driver in the target host. Figure 3 (shown as VFIO1-VFIOn) Figure 3 The virtual machine (VF) and its assigned kernel-mode driver (VFIO) share the same number to reflect the association between the VF and the kernel-mode driver. Based on the kernel-mode driver, the virtual machine can bypass the backend implementation and host protocol stack forwarding process in traditional virtualization solutions, enabling the virtual machine to interact directly with external devices, thereby improving I / O performance.

[0066] During their research, the inventors discovered that virtual devices frequently malfunction due to accessing abnormal addresses. As described in the background section, a virtual device malfunction causes all virtual machines served by all virtual devices connected to its root interface to be suspended. This existing mechanism, where a single point of failure triggers a widespread suspension of virtual machines, was intended to more comprehensively detect and handle device failures; however, it has also become a vulnerability for malicious attacks. Further research revealed that attackers are already constructing abnormal addresses within a single virtual machine to control virtual devices and access them abnormally, thereby enabling them to attack more virtual machines on the host machine, posing a significant security risk to the virtual machines on the host.

[0067] To address this, the device failure handling scheme in this embodiment proposes a technical concept: when a single virtual device fails, the failure domain is precisely controlled within the virtual machine served by the failed virtual device, preventing the failure domain from spreading to other unrelated virtual machines. This not only ensures accurate handling of device failures but also effectively blocks the aforementioned attack methods.

[0068] In order to realize the above-mentioned technical concept proposed in this embodiment, the error reporting driver has been functionally modified in this embodiment.

[0069] As described in the background section, when a virtual device malfunctions, the Advanced Error Reporting (AER) mechanism in the host operating system is triggered. The AER mechanism is implemented by the error reporting driver in the host operating system. In this embodiment, by modifying the error reporting driver, the processing flow in the AER mechanism can be optimized. This allows for accurate location of the faulty virtual device during AER implementation, and precise control to pause only the virtual machines served by the faulty virtual device, avoiding impact on other unrelated virtual machines.

[0070] refer to Figure 2 The virtual devices created on the target host for external devices are associated with the root port. The root port is a fundamental component of the bus architecture, located between the root complex (RC) and the bus devices. It provides the physical connection point between the RC and the bus devices, and is responsible for connecting and managing these bus devices. In the bus architecture, the RC is the root node of the entire bus device tree. The host CPU connects to the host bus through the RC, enabling the CPU to connect to various bus devices. The main function of the RC is to connect the CPU and memory subsystem into the bus hierarchy, performing address translation between different spaces—that is, translating the address in the CPU domain to the address in the bus device domain. Through the root port, the RC can identify and manage various devices connected to the system bus, including endpoints and switches. Switches can then connect to endpoints and switches, thus forming the bus hierarchy.

[0071] In this embodiment, a virtual device is a special type of endpoint that can be connected directly to the root interface of the host or via a switch bridge.

[0072] Furthermore, some more complex hosts may have multiple root interfaces, each capable of independently managing a group of bus devices, thereby improving the overall system performance and reliability. Thus, from the perspective of root interfaces and virtual devices, a target host may contain one or more root interfaces, and each root interface can connect (directly or via bridging) one or more virtual devices. Virtual devices corresponding to the same external device on the target host are typically connected to the same root interface.

[0073] As mentioned earlier, in the event of a virtual device failure, the AER mechanism in the host operating system will be triggered. (Reference) Figure 2 In this triggering phase, after a virtual device malfunctions, its connected root interface will send an interrupt signal to the target host's operating system to trigger the AER mechanism. An exemplary triggering procedure for this phase could be:

[0074] When any virtual device connected to the root interface initiates a direct memory access request, the direct memory access request is forwarded to the memory management unit through the root interface; the memory management unit performs address translation on the address carried in the direct memory access request; if an address translation exception occurs, the memory management unit adds an address translation exception record to the event queue; an error message is returned to the virtual device through the root interface as a response to the direct memory access request, and the error message is used to trigger the virtual device to initiate a fault handling request to the root interface; and an interrupt signal is issued through the root interface to trigger the error reporting mechanism for the fault handling request.

[0075] As can be understood from the above exemplary triggering process, if the virtual device fails due to a direct memory access request that cannot be completed or for other reasons, it will receive an error message returned by the root interface. Based on the existing error message handling mechanism in the virtual device, the virtual device will initiate a fault handling request to the root interface, which will cause the root interface to issue the aforementioned interrupt signal.

[0076] It should be understood that this is only an exemplary triggering process, and it is also a relatively common triggering process in the current AER mechanism. However, this embodiment does not limit it. This embodiment supports other triggering processes in existing or future AER mechanisms, as long as it ensures that the root interface can send an interrupt signal to trigger the error reporting mechanism when the virtual device fails.

[0077] Based on this, refer to Figure 1 In step 100, the target host's operating system can run the error reporting driver after receiving an interrupt signal from any root interface in the target host to trigger the error reporting mechanism. The interrupt signal used to trigger the error reporting mechanism can be referred to as the AER interrupt.

[0078] To support this interrupt mechanism, in practical applications: after the target host boots up, the operating system can assign interrupt vectors to each root interface in the target host. The root interface can then identify subsequent AER interrupts based on the assigned interrupt vectors. To service AER interrupts on the root interfaces, the error reporting driver can register interrupt service handlers in the operating system. Based on this, when a root interface receives a fault handling request from its downstream device (such as the virtual device in this embodiment), the root interface will issue an AER interrupt to the operating system (or CPU). Through the interrupt service handlers registered by the error reporting driver, the AER interrupt can eventually reach the operating system kernel (hereinafter referred to as the kernel) of the target host and trigger the execution of the error reporting driver in the kernel.

[0079] In this embodiment, the interrupt handling path in the aforementioned interrupt service routine is not limited. In one optional implementation, the interrupt service routine can directly hand over the AER interrupt to the kernel of the target host for processing, and the kernel can run the error reporting driver based on the AER interrupt. In another optional implementation, the interrupt service routine can hand over the AER interrupt to designated firmware (e.g., BIOS), which can write the root interface identifier and error description information such as the error type to the Generic Hardware Error Source (GHES) table based on the AER interrupt. After the kernel of the target host reads the error description information from the GHES table, it will run the error reporting driver. It should be understood that both of the above implementation methods are optional, and the technical details are merely exemplary. This embodiment is not limited to these, and no further examples will be given here.

[0080] At this point, the error reporting driver in the target host kernel begins to run.

[0081] During their research, the inventors discovered that current error reporting drivers lack the ability to accurately locate faulty virtual devices. Therefore, to avoid missing faults, they adopted the previously mentioned mechanism of handling large-scale virtual machine shutdowns caused by single-point faults. This embodiment modifies the functionality of the error reporting driver, enabling it to accurately locate faulty virtual devices.

[0082] In response, based on the functional modifications to the error reporting driver in this embodiment, and referring to... Figure 1 and Figure 2 In step 101, address translation exception records can be obtained from the event queue maintained by the memory management unit based on the error reporting driver.

[0083] In this embodiment, the process of passing external devices from the target host to the virtual machine relies on the memory management unit on the target host. The name of the memory management unit may differ across operating systems. In this embodiment, the memory management unit may include, but is not limited to, an Input-Output Memory Management Unit (IOMMU) or a System Memory Management Unit (SMMU). In practical applications, a suitable memory management unit can be selected as needed based on the type of operating system used by the target host.

[0084] In device passthrough technology, the memory management unit (MMU) is responsible for address translation. In this embodiment, the MMU can translate the virtual machine physical address (Guest Physical Address, GPA) in a memory access request initiated by a virtual device into the host physical address (HPA) of the system memory, ensuring that the virtual device can access the correct system memory region. This helps prevent virtual devices from accessing memory regions out of bounds or accessing unauthorized memory regions. Furthermore, address translation and access control provide protection for system memory, preventing virtual devices from reading or writing to memory regions that do not belong to them, thereby enhancing the security and stability of system memory.

[0085] During address translation, the memory management unit (MMU) can record events related to the MMU through an event queue. The event records in the event queue may contain information such as device identifier, error type, and access address. Error types may include, but are not limited to, address translation errors and configuration errors.

[0086] It is understood that in this embodiment, the error reporting driver borrows the event queue maintained by the memory management unit in order to locate the virtual device that has failed due to an address translation error by recording the address translation error in the event queue.

[0087] Continue to refer to Figure 1 and Figure 2 In step 102, it is proposed that if the address translation error record points to any virtual device connected to the root interface, the kernel-mode driver corresponding to the virtual device is called through the error reporting driver.

[0088] In step 102, the obtained address translation error record is further evaluated. In this embodiment, it is required that the address translation error record points to a virtual device, and that the virtual device is connected to the root interface that issued the interrupt signal in the aforementioned step 100.

[0089] As mentioned earlier, in addition to virtual devices, other types of devices, such as physical devices, may be connected to the root interface. Therefore, in step 102, the error reporting driver can determine whether the device pointed to by the address translation error record is a virtual device. Referring to the previous text, the address translation error record usually contains a device identifier. Based on this, an optional implementation proposes that: the error reporting driver can call the first interface in the target host used for managing device information; through the first interface, it can determine whether the device type corresponding to the device identifier in the address translation error record is a virtual device and feed back the determination result to the error reporting driver. The first interface can be any existing interface in the target host with device type determination capabilities. Such interfaces are common interfaces in bus protocols; no example of interface name is given here, and this embodiment does not limit which specific interface to use. Any interface in the target host with device type determination capabilities can be used as the first interface in this optional implementation. Furthermore, this implementation is only optional, and this embodiment is not limited to it. For example, a functional module for device type determination can be added to the error reporting driver. This functional module can record the types of each device connected to each root interface in the target host to support device type determination. No further examples or explanations will be provided here regarding the implementation methods.

[0090] Thus, in this embodiment, the error reporting driver will not use address translation exceptions occurring on other types of devices besides virtual devices as the basis for handling device failures on the root interface in step 100.

[0091] As mentioned earlier, the target host may have multiple root interfaces, and the memory management unit is usually shared by multiple root interfaces. Therefore, the event records recorded in the event queue maintained by the memory management unit may involve devices connected to multiple root interfaces. Therefore, in step 102, it is necessary to determine whether the device pointed to by the obtained address translation error record is connected to the root interface that issued the interrupt signal in step 100. If not, it indicates that a device connected to another root interface may have experienced an address translation error event. In this embodiment, such address translation error records will not be used as the basis for handling device failures on the root interface in step 100.

[0092] In one optional implementation, a second interface in the target host used for managing root interface information can be called via an error reporting driver. Through this second interface, it is determined whether the device pointed to by the device identifier in the address translation error record is connected to the root interface, and the determination result is fed back to the error reporting driver. The second interface can be any existing interface in the target host capable of querying the connection relationship between the root interface and the device. Such interfaces are common in bus protocols; no example of the interface name is given here, and this embodiment does not limit the specific interface used. Any interface in the target host with this capability can be used as the second interface in this optional implementation. Furthermore, this implementation is only optional, and this embodiment is not limited to it. For example, a functional module for recording the connection relationship between the root interface and the device can be added to the error reporting driver. This functional module can record the connection relationship between each root interface and the device in the target host to support querying the connection relationship. No further examples or explanations of other implementation methods are provided here.

[0093] Thus, in step 102, by further evaluating the address translation exception record obtained in step 101, if the interrupt signal in step 100 is caused by a faulty virtual device on the root interface, then in step 102, the error reporting driver can accurately locate the virtual device causing the interrupt signal. This echoes the preceding statement, indicating that the error reporting driver in this embodiment has the function of accurately locating faulty virtual devices.

[0094] Based on this, in step 102, the error reporting driver can only call the kernel-mode driver corresponding to the located faulty virtual device, instead of traversing and calling the kernel-mode drivers of all virtual devices on the root interface as in the traditional processing mechanism.

[0095] Continue to refer to Figure 1 and Figure 2 In step 103, based on the kernel-mode driver called in step 102, the target virtual machine served by the faulty virtual device located in step 102 can be paused.

[0096] The kernel-mode driver includes a fault handling module, which is typically used for error checking and handling. When invoked, this module pauses the corresponding virtual machine. Therefore, in step 103, the error reporting driver invokes the kernel-mode driver, which essentially invokes the fault handling module within the kernel-mode driver. This triggers the fault handling module to pause the target virtual machine served by the faulty virtual device identified in step 102.

[0097] Thus, in this embodiment, based on the modified error reporting driver, only the target virtual machine served by the faulty virtual device that caused the interrupt signal in step 100 can be suspended, without causing other virtual machines to be suspended. That is, the fault domain of a single point of failure is controlled within a single virtual machine, and it will no longer cause a large number of virtual machines to be suspended.

[0098] In summary, this embodiment proposes a device failure handling scheme. The error reporting driver in the target host operating system has been functionally modified. Based on this, the target host operating system can run the error reporting driver after receiving an interrupt signal from any root interface to trigger the error reporting mechanism. Based on the error reporting driver, address translation exception records can be retrieved from the event queue maintained by the memory management unit. If the address translation exception record points to any virtual device connected to the root interface, the kernel-mode driver corresponding to the virtual device is called through the error reporting driver. Based on the kernel-mode driver, the target virtual machine served by the virtual device is paused. Accordingly, in this embodiment, the error reporting driver can accurately locate the failed virtual device on the root interface using the address translation exception records maintained by the memory management unit in the event queue. Therefore, when a single virtual device fails, the fault domain is precisely controlled to the virtual machine served by the failed virtual device, thus only pausing the virtual machine served by the failed virtual device. This effectively avoids affecting other virtual machines running on the target host. Moreover, even if an attacker constructs an abnormal address in a virtual machine and controls a virtual device to access that abnormal address, it will no longer be possible to attack multiple virtual machines. This effectively protects the security of virtual machines on the host and avoids security risks.

[0099] In the above or below embodiments, the memory management unit may be functionally modified to support the error reporting driver in borrowing the event queue maintained by the memory management unit.

[0100] In this embodiment, it is proposed that a query interface can be added to the driver corresponding to the memory management unit. This query interface is called by the error reporting driver and can be used to read event records from the event queue.

[0101] Based on this, one possible implementation for retrieving address translation exception records from the event queue maintained by the memory management unit, based on an error reporting driver, is as follows:

[0102] Based on the error reporting driver, the query interface provided by the memory management unit for querying the event queue is called; based on the query interface, address translation exception records are retrieved from the event queue maintained by the memory management unit.

[0103] In other words, the error reporting driver can read event records in the event queue by calling the query interface provided in the memory management unit in this embodiment. This establishes the access link between the error reporting driver and the event queue, effectively improving the efficiency of the error reporting driver in obtaining address translation exception records from the event queue.

[0104] To this end, this embodiment also proposes that the event queue corresponding to the memory management unit be started after the target host starts up; and a query interface be configured in the driver corresponding to the memory management unit for the error reporting driver to call. In this way, the memory management unit begins maintaining the event queue after the target host starts up, thus ensuring the comprehensiveness of event records in the event queue. Furthermore, by adding the query interface to the driver corresponding to the memory management unit after the target host starts up, it is ensured that the error reporting driver can call the query interface without obstacles after running, thereby ensuring timely support for the error reporting driver to locate faulty virtual devices.

[0105] In addition, in this embodiment, the memory management unit and the error reporting driver can use the event queue in a producer-consumer pattern, with the memory management unit being the producer of the event queue and the error reporting driver being the consumer of the event queue.

[0106] Furthermore, as mentioned earlier, the event records in the event queue not only include address translation exception classes, but also other types of event records. In this embodiment, the following is proposed:

[0107] Based on the error reporting driver, event records can be read from the event queue using a consumption method; and address translation exception records can be filtered out from the read event records.

[0108] An exemplary consumption process may be as follows: the error reporting driver initiates a consumption command to the aforementioned query interface provided by the memory management unit; in response to the consumption command, the query interface reads an event record from the event queue and returns the event record to the error reporting driver as a response to the consumption command; furthermore, the query interface also deletes the event record from the event queue to complete the consumption of that event record. The error reporting driver may continue to initiate consumption commands to consume other event records in the event queue until all event records in the event queue have been consumed, at which point the query interface may notify the error reporting driver to terminate the consumption.

[0109] Of course, this consumption process is only exemplary and is not limited to this in this embodiment. It is sufficient to ensure that the same event record in the event queue is not processed repeatedly by multiple root interfaces. No further examples will be given here.

[0110] Understandably, in this embodiment, considering that virtual device failures are usually caused by address translation anomalies, and that malicious attacks are also carried out by creating address translation anomaly events, the error reporting driver in this embodiment can primarily focus on address translation anomaly records to accurately locate the virtual device that failed due to an address translation anomaly. Other types of event records read from the event queue can be ignored and not processed by the error reporting driver.

[0111] During their research, the inventors discovered that because the error reporting driver reads event records from the event queue in a consumption manner, and the event queue may involve multiple root interfaces simultaneously, out-of-bounds consumption may occur. For example, after the current root interface issues an interrupt signal, it consumes address translation exception records related to other root interfaces from the event queue. This means that when other root interfaces issue interrupt signals, the relevant address translation exception records have already been lost, which may affect the handling of device faults on other root interfaces.

[0112] To address this, a safeguard mechanism is proposed in this embodiment. This safeguard mechanism includes the following:

[0113] If no address translation exception record is obtained from the event queue in step 10 above, the kernel-mode driver corresponding to each virtual device connected to the root interface that issued the aforementioned interrupt signal is called through the error reporting driver.

[0114] Each kernel-mode driver invoked performs a virtual machine pause operation to pause the virtual machines served by each virtual device connected to the root interface.

[0115] Thus, based on this guarantee mechanism, even if an address translation exception record related to a certain root interface is consumed out of bounds during device processing on other root interfaces, it will not lead to the problem of missed device fault handling on the current root interface. The error reporting driver can realize the timely suspension of relevant virtual machines by traversing and calling the kernel-mode drivers corresponding to each virtual device connected to the current root interface. This allows the kernel-mode drivers to further detect faulty virtual devices and avoid the problem of missed device fault handling.

[0116] During their research, the inventors further discovered that, besides the potential for unauthorized consumption leading to equipment malfunctions and subsequent issues, other factors could also cause equipment malfunctions to go unaddressed. Therefore, the safeguard mechanism provided in this embodiment further proposes:

[0117] If the obtained address translation error record does not point to any virtual device connected to the root interface, the kernel-mode driver corresponding to each virtual device connected to the root interface is called through the error reporting driver.

[0118] Each kernel-mode driver invoked performs a virtual machine pause operation to pause the virtual machines served by each virtual device connected to the root interface.

[0119] If the obtained address translation error record does not point to any virtual device connected to the root interface, it means that the device fault that caused the interrupt signal in step 100 cannot be determined based on the event queue maintained by the memory management unit, and further investigation is required. In this case, the error reporting driver can traverse and call the kernel-mode drivers corresponding to each virtual device connected to the current root interface to realize the timely suspension of the relevant virtual machines. This allows the kernel-mode drivers to further detect the faulty virtual devices and avoid the problem of missing device fault handling.

[0120] In summary, in this embodiment, the error reporting driver can utilize the event queue maintained by the memory management device to locate the faulty virtual device on the root interface that issued the interrupt signal. If the interrupt signal is caused by a fault in any virtual device on the root interface, the corresponding address translation exception record can usually be read from the event queue, thus accurately locating the faulty virtual device. However, if no address translation exception record is obtained from the event queue, or if the obtained address translation exception record does not point to any virtual device associated with the root interface, it indicates that the device fault causing the interrupt signal cannot be determined based on the event queue. In this case, this embodiment can use a safeguard mechanism to promptly suspend the virtual machines served by each virtual device associated with the root interface, thereby further investigating device faults and avoiding the problem of overlooking device fault handling.

[0121] Figure 4 This is a schematic diagram illustrating a device fault handling process in an exemplary scenario provided for an exemplary embodiment of this application. In this exemplary scenario, the target host has already used SR-IOV and VFIO technologies to directly connect external devices to virtual machines on the target host. Multiple VFIOs have been created on the target host. Figure 4 The VFs are labeled VF1-VFn, and each VF is associated with a kernel-mode driver. Figure 4 (shown as VFIO1-VFIOn).

[0122] Based on this, refer to Figure 4 The device fault handling process in this exemplary scenario can generally include:

[0123] 1. After the target host boots up, it loads the SMMU driver, starts the event queue to record events such as address translation exceptions, and adds a query interface (or interface function) to the SMMU driver to read event records in the event queue. This query interface is then exposed to the outside world to support AER driver calls.

[0124] 2. When a virtual device VF1 makes an abnormal direct memory access (DMA) request (e.g., the access address exceeds the range of the virtual machine's physical memory address), the SMMU hardware will add an address translation exception record to the event queue. This record may contain the device identifier (e.g., Bus / Device / Function, BDF), the error type (e.g., address translation exception class), and the access address, etc.

[0125] 3. The CPU of the target host can respond to the DMA request and return an error message to VF1. Different types of operating systems may return different error messages. For example, the error message may be a status code indicating an unsupported request (UR) or a status code indicating a completion abort (CA), etc. No further examples are given here.

[0126] 4. VF1 routes the error information to the root interface of the target host, the root interface triggers an AER interrupt, and the AER driver in the target host kernel begins to process the AER interrupt.

[0127] 5. The AER driver can call the query interface provided by SMMU to read address translation exception records from the event queue and obtain the device BDF information.

[0128] 6. The AER driver determines whether the BDF is a downstream device of the current root interface and whether it is a VF device. If so, it can directly call the kernel-mode driver VFIO1 corresponding to the VF1 to perform error checking and error handling.

[0129] Otherwise, the AER driver can traverse all virtual devices connected to the root interface and call the kernel-mode driver corresponding to each virtual device one by one to perform error checking and error handling.

[0130] 7. In the case of device passthrough, the error_detected module in the kernel-mode driver of VF1 can notify the Quick EMUlator (QEMU) component in the target host in the form of eventfd to perform virtual machine pause operation to control VM1 to pause (VM1 is essentially a QEMU process created by the QEMU component).

[0131] As can be seen, the device failure handling solution provided in this embodiment will only suspend the virtual machines served by the VF when a single VF fails, and will not affect other virtual machines. It can accurately control the fault domain of a single point of failure, thereby ensuring timely handling of device failures and preventing attackers from attacking more virtual machines on the target host by creating a single point of failure.

[0132] It should be noted that some processes described in the above embodiments and accompanying drawings include multiple operations appearing in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear in this document, or they may be executed in parallel. The operation numbers, such as 801, 802, etc., are merely used to distinguish different operations and do not represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should also be noted that the descriptions such as "first" and "second" in this document are used to distinguish different interfaces, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0133] Figure 5 This is a schematic diagram of the structure of a host provided for another exemplary embodiment of this application. For example... Figure 5 As shown, the host includes: memory 50, processor 51, and communication component 52.

[0134] Processor 51, coupled to memory 50 and communication component 52, is used to execute computer programs in memory 500 for:

[0135] Upon receiving an interrupt signal from any root interface in the host that triggers the error reporting mechanism, the error reporting driver is executed.

[0136] Based on the error reporting driver, address translation exception records are retrieved from the event queue maintained by the memory management unit;

[0137] If the address translation error record points to any virtual device connected to the root interface, then the kernel-mode driver corresponding to the virtual device is called through the error reporting driver.

[0138] Based on the kernel-mode driver, the target virtual machine served by the virtual device is paused.

[0139] In an optional embodiment, when the processor 51 retrieves an address translation exception record from the event queue maintained by the memory management unit based on the error reporting driver, it may specifically be used to:

[0140] Based on the error reporting driver, the query interface provided by the memory management unit for querying the event queue is called;

[0141] Based on the query interface, the address translation exception record is obtained from the event queue maintained by the memory management unit.

[0142] In an alternative embodiment, processor 51 may also be used for:

[0143] After the host starts up, the event queue corresponding to the memory management unit is opened;

[0144] In the driver corresponding to the memory management unit, the query interface is configured so that the error reporting driver can call the query interface to obtain the address transfer exception record from the event queue.

[0145] In an optional embodiment, when the processor 51 retrieves an address translation exception record from the event queue maintained by the memory management unit, it may specifically be used to:

[0146] Event records are read from the event queue using a consumption method;

[0147] Filter address translation exception records from the read event logs.

[0148] The memory management unit is the producer of event records in the event queue.

[0149] In an alternative embodiment, processor 51 may also be used for:

[0150] If the obtained address translation error record does not point to any virtual device connected to the root interface, then the kernel-mode driver corresponding to each virtual device connected to the root interface is called through the error reporting driver.

[0151] Each kernel-mode driver invoked performs a virtual machine pause operation to pause the virtual machines served by each virtual device connected to the root interface.

[0152] In an alternative embodiment, processor 51 may also be used for:

[0153] If no address translation exception record is obtained from the event queue, the kernel-mode driver corresponding to each virtual device connected to the root interface is called through the error reporting driver.

[0154] Each kernel-mode driver invoked performs a virtual machine pause operation to pause the virtual machines served by each virtual device connected to the root interface.

[0155] In an optional embodiment, the address translation error record includes a device identifier, and the processor 51 can also be used for:

[0156] The error reporting driver invokes the first interface in the host used for managing device information;

[0157] The first interface is used to determine whether the device type corresponding to the device identifier in the address translation error record is a virtual device and the determination result is fed back to the error reporting driver.

[0158] In an optional embodiment, the address translation error record includes a device identifier, and the processor 51 can also be used for:

[0159] The error reporting driver calls the second interface in the host used to manage root interface information;

[0160] The second interface is used to determine whether the device pointed to by the device identifier in the address translation error record is connected to the root interface, and the determination result is fed back to the error reporting driver.

[0161] In an alternative embodiment, processor 51 may also be used for:

[0162] If any virtual device connected to the root interface initiates a direct memory access request, the direct memory access request is forwarded to the memory management unit through the root interface;

[0163] The memory management unit performs address translation for the addresses carried in the direct memory access request;

[0164] If an address translation error occurs, the memory management unit adds an address translation error record to the event queue.

[0165] The root interface returns error information to the virtual device as a response to the direct memory access request. The error information is used to trigger the virtual device to initiate a fault handling request to the root interface.

[0166] Through the root interface, an interrupt signal is issued for the fault handling request to trigger the error reporting mechanism.

[0167] In an alternative embodiment, the memory management unit includes an input / output memory management unit or a system memory management unit.

[0168] Furthermore, such as Figure 5 As shown, the host also includes other components such as a power supply unit 24. Figure 5 The diagram only shows some components and does not mean that the computing device includes only these components. Figure 5 The components shown.

[0169] It is worth noting that the technical details of the above-mentioned host embodiments can be referred to the relevant descriptions in the foregoing method embodiments. To save space, they will not be repeated here, but this should not cause any loss to the scope of protection of this application.

[0170] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed, can implement the steps in the above method embodiments.

[0171] Accordingly, this application also provides a computer program product, which, when executed, can implement the steps in the above method embodiments.

[0172] The above Figure 5 The memory in a computer is used to store computer programs and can be configured to store various other data to support operation on a computing platform. Examples of this data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, pictures, videos, etc. The memory can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disks, or optical disks.

[0173] The above Figure 5 The communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component further includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA) technology, Ultra-Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0174] The above Figure 5 The power supply component provides power to the various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which it resides.

[0175] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0176] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0177] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0178] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0179] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

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

[0181] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for handling equipment malfunctions, characterized in that, The method, applicable to the operating system of the target host, includes: Upon receiving an interrupt signal from any root interface in the target host to trigger the error reporting mechanism, the error reporting driver is executed. Based on the error reporting driver, address translation exception records are retrieved from the event queue maintained by the memory management unit; If the address translation error record points to any virtual device connected to the root interface, then the kernel-mode driver corresponding to the virtual device is called through the error reporting driver. Based on the kernel-mode driver, the target virtual machine served by the virtual device is paused.

2. The method according to claim 1, characterized in that, Based on the error reporting driver, address translation exception records are retrieved from the event queue maintained by the memory management unit, including: Based on the error reporting driver, the query interface provided by the memory management unit for querying the event queue is called; Based on the query interface, the address translation exception record is obtained from the event queue maintained by the memory management unit.

3. The method according to claim 2, characterized in that, Also includes: After the target host starts up, the event queue corresponding to the memory management unit is opened; In the driver corresponding to the memory management unit, the query interface is configured so that the error reporting driver can call the query interface to obtain the address transfer exception record from the event queue.

4. The method according to claim 1, characterized in that, Retrieve address translation exception records from the event queue maintained by the memory management unit, including: Event records are read from the event queue using a consumption method; Filter address translation exception records from the read event logs; The memory management unit is the producer of event records in the event queue.

5. The method according to claim 1, characterized in that, Also includes: If the obtained address translation error record does not point to any virtual device connected to the root interface, then the kernel-mode driver corresponding to each virtual device connected to the root interface is called through the error reporting driver. Each kernel-mode driver invoked performs a virtual machine pause operation to pause the virtual machines served by each virtual device connected to the root interface.

6. The method according to claim 1, characterized in that, Also includes: If no address translation exception record is obtained from the event queue, the kernel-mode driver corresponding to each virtual device connected to the root interface is called through the error reporting driver. Each kernel-mode driver invoked performs a virtual machine pause operation to pause the virtual machines served by each virtual device connected to the root interface.

7. The method according to claim 1, characterized in that, The address translation error record contains a device identifier, and the method further includes: The error reporting driver invokes the first interface in the target host used for managing device information. The first interface is used to determine whether the device type corresponding to the device identifier in the address translation error record is a virtual device and the determination result is fed back to the error reporting driver.

8. The method according to claim 1, characterized in that, The address translation error record contains a device identifier, and the method further includes: The error reporting driver invokes the second interface in the target host used to manage root interface information; The second interface is used to determine whether the device pointed to by the device identifier in the address translation error record is connected to the root interface, and the determination result is fed back to the error reporting driver.

9. The method according to claim 1, characterized in that, Also includes: If any virtual device connected to the root interface initiates a direct memory access request, the direct memory access request is forwarded to the memory management unit through the root interface; The memory management unit performs address translation for the addresses carried in the direct memory access request; If an address translation error occurs, the memory management unit adds an address translation error record to the event queue. The root interface returns error information to the virtual device as a response to the direct memory access request. The error information is used to trigger the virtual device to initiate a fault handling request to the root interface. Through the root interface, an interrupt signal is issued for the fault handling request to trigger the error reporting mechanism.

10. The method according to any one of claims 1-9, characterized in that, The memory management unit includes an input / output memory management unit or a system memory management unit.

11. A host computer, characterized in that, Includes memory, processor, and communication components; The memory is used to store one or more computer instructions; The processor is coupled to the memory and the communication component and is used to execute one or more computer instructions for performing the device fault handling method according to any one of claims 1-10.

12. A computer-readable storage medium for storing computer instructions, characterized in that, When the computer instructions are executed by one or more processors, the one or more processors perform the device fault handling method according to any one of claims 1-10.

13. A computer program product, characterized in that, Includes a computer program / instruction, wherein when the computer program / instruction is executed by a processor, it causes the processor to implement the device fault handling method according to any one of claims 1-10.

Images