Ebpf-based soft lock detection analysis method, system, medium and product

Abstract

The application discloses an ebpf-based soft lock detection and analysis method, system, medium and product, the method comprises the following steps: when a virtual machine is in a soft lock state, based on ebpf code monitoring on a host system, vCPU exit guest mode information in an execution state of the virtual machine vCPU is detected, if no vCPU exit guest mode information is found in a plurality of continuous soft lock detection periods, it is determined that the cause is the host system; if the number of times of finding vCPU exit guest mode in a plurality of continuous soft lock detection periods exceeds a preset threshold and the exit reason matches a preset rule, it is determined that the cause is the internal cause of the virtual machine. The application aims to accurately determine the cause of the soft lock problem of the virtual machine without changing the kernel of the virtual machine, and determine whether the soft lock problem of the virtual machine is caused by the resource scheduling of the host system or the internal cause of the virtual machine itself.

Description

Technical Field

[0001] This invention relates to the field of virtualization technology, specifically to a soft lock detection and analysis method, system, medium, and product based on EBPF. Background Technology

[0002] A soft lockup is a deadlock / livelock diagnostic mechanism triggered by the Linux kernel when it detects that a CPU has not responded to a scheduler interrupt for an extended period (approximately 20-60 seconds by default). This means the CPU is "stuck" in a kernel-mode code path and cannot return to the scheduler, preventing all tasks on that core (including ksoftirqd, kworker, and ordinary processes) from being scheduled. In cloud environments, virtual machines based on KVM virtualization technology are widely used. To achieve high utilization, users often over-provision CPUs and memory, which can lead to the virtual machines' vCPUs (virtual CPUs) not being scheduled in a timely manner, resulting in a soft lockup detected within the virtual machine. Alternatively, the soft lockup may be caused by an internal problem within the virtual machine itself. Due to the virtual machine environment, scheduling delays can be caused by either host system resource constraints or bugs within the virtual machine itself. However, currently, there is no particularly effective way to determine whether the scheduling delay is due to host system resource constraints or a bug within the virtual machine itself causing the soft lockup. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide a soft lock detection and analysis method, system, medium, and product based on EBPF, which addresses the above-mentioned problems in the prior art. This invention aims to accurately determine the cause of soft lock problems in virtual machines without changing the virtual machine kernel, and to determine whether the virtual machine scheduling delay is caused by host system resource shortage or by a bug in the virtual machine itself.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0005] A soft lock detection and analysis method based on EBPF includes the following steps:

[0006] S101 uses ebpf code deployed on the host system to monitor the execution status of the virtual machine's vCPU;

[0007] S102, when a virtual machine soft lock occurs, soft lock detection and analysis are performed based on the vCPU exiting guest mode information in the execution state of the virtual machine vCPU. If no vCPU exiting guest mode information is found within multiple consecutive soft lock detection cycles, the virtual machine soft lock is determined to be caused by host system resource scheduling. If the exit count statistics of vCPU exiting guest mode exceed a preset threshold within multiple consecutive soft lock detection cycles, the exit reason of vCPU exiting guest mode is checked. If the exit reason is an external interrupt exit exceeding a specified multiple of the preemption timer exit, the virtual machine soft lock is determined to be caused by internal virtual machine reasons.

[0008] Optionally, in step S101, when using the ebpf code deployed on the host system to monitor the execution status of the virtual machine vCPU, the soft lock detection cycle in the virtual machine is an integer multiple of the polling cycle of the ebpf code monitoring the execution status of the virtual machine vCPU.

[0009] Optionally, in step S101, when using the ebpf code deployed on the host system to monitor the execution status of the virtual machine vCPU, the ebpf code is used to intercept the kvm_entry function and kvm_exit function of the kvm virtual machine on the host system to capture the execution status of the virtual machine vCPU calling the kvm_entry function to enter guest mode and calling the kvm_exit function to exit guest mode.

[0010] Optionally, in step S101, when using the EBPF code deployed on the host system to monitor the execution status of the virtual machine vCPU, the method includes using a virtual machine monitoring daemon running on the host system to record the execution status of the virtual machine vCPU when the EBPF code calls the kvm_entry function to enter guest mode and calls the kvm_exit function to exit guest mode. The virtual machine monitoring daemon running on the host system includes an entry tracing function and an exit tracing function. The entry tracing function is used to record the information of the virtual machine vCPU calling the kvm_entry function to enter guest mode and record it in the runtime information table. The exit tracing function is used to record the execution status of the virtual machine vCPU calling the kvm_exit function to exit guest mode and update the runtime information table. The method also counts the number of times the virtual machine vCPU exits based on the exit reason.

[0011] Optionally, the execution steps of the entry tracing function include: when the vCPU calls the kvm_entry function to enter guest mode, the entry tracing function records the runtime information of the vCPU entering guest mode, including the process ID (PID) corresponding to the vCPU, the ID of the vCPU, and the entry time, and records the runtime information of the vCPU in the runtime information table with the process ID (PID) corresponding to the vCPU as the index.

[0012] Optionally, the execution steps of the exit tracing function include: when the vCPU calls the kvm_exit function to exit guest mode, the exit tracing function first queries the runtime information table based on the process ID (PID) corresponding to the vCPU, and updates the runtime information for exiting guest mode in the runtime information table that matches the runtime information, including exit time, exit reason, and exit count statistics; then, it queries the exit statistics table based on the process ID (PID) corresponding to the vCPU, the vCPU ID, and the exit reason as indexes. If no matching record is found in the exit statistics table, a new record is added to the exit statistics table with the index and the count value is initialized to 1. If a matching record is found in the exit statistics table, the count value of the matching record is incremented by 1; and when the polling cycle of the virtual machine vCPU's execution status expires, the contents of the runtime information table and the exit statistics table are output.

[0013] Optionally, updating the runtime information for exiting guest mode in the runtime information table includes: querying the runtime information table based on the process ID (PID) corresponding to the vCPU; if a matching runtime information is found, updating the runtime information for exiting guest mode in the matching runtime information table, including exit time, exit reason, and exit count statistics; if no matching runtime information is found, firstly, the process ID (PID) corresponding to the vCPU, the vCPU ID, and the entry time are used, and the runtime information of the vCPU is recorded in the runtime information table using the process ID (PID) corresponding to the vCPU as an index, and then updating the runtime information for exiting guest mode in the recorded runtime information, including exit time, exit reason, and exit count statistics.

[0014] Furthermore, the present invention also provides a soft lock detection and analysis system based on EBPF, comprising a microprocessor and a memory interconnected thereto, wherein the microprocessor is programmed or configured to execute the EBPF-based soft lock detection and analysis method.

[0015] Furthermore, the present invention also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute the EBPF-based soft lock detection and analysis method by a processor.

[0016] In addition, the present invention also provides a computer program product, including a computer program or instructions, which are programmed or configured to execute the EBPF-based soft lock detection and analysis method by a processor.

[0017] Compared with existing technologies, this invention mainly achieves the following beneficial effects: The soft lock detection and analysis method based on EBPF monitors the switching of virtual machine vCPU running states and the host state on the host side using EBPF. This allows for the acquisition of vCPU running status without modifying the virtual machine kernel, thus accurately determining the cause of soft lock problems in the virtual machine and identifying whether the soft lock is caused by an internal virtual machine issue or a host problem. This invention constructs a system that can monitor the execution state of virtual machine vCPUs without modifying the host and guest kernels, and can effectively determine the cause of soft locks triggered within the virtual machine based on the vCPU state. Similar to ordinary user-space programs on the host, the status of the host and virtual machine vCPUs can be recorded in real time after deployment on the host. The recorded data can effectively determine the cause of soft locks occurring within the virtual machine. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the basic process of the method in an embodiment of the present invention.

[0019] Figure 2 This is a schematic diagram illustrating the implementation principle of the method in an embodiment of the present invention. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solution of the present invention, the technical solution of the present invention will be further described in detail below with reference to the accompanying drawings in the embodiments of the present invention.

[0021] like Figure 1 As shown, the soft lock detection and analysis method based on EBPF in this embodiment includes the following steps:

[0022] S101 uses ebpf code deployed on the host system to monitor the execution status of the virtual machine's vCPU;

[0023] S102, when a virtual machine soft lock occurs, soft lock detection and analysis are performed based on the vCPU exiting guest mode information in the execution state of the virtual machine vCPU. If no vCPU exiting guest mode information is found within multiple consecutive soft lock detection cycles, the virtual machine soft lock is determined to be caused by host system resource scheduling. If the exit count statistics of vCPU exiting guest mode exceed a preset threshold within multiple consecutive soft lock detection cycles, the exit reason of vCPU exiting guest mode is checked. If the exit reason is an external interrupt exit exceeding a specified multiple of the preemption timer exit, the virtual machine soft lock is determined to be caused by internal virtual machine reasons.

[0024] This embodiment uses EBPF to monitor the execution status of a virtual machine's (vCPU) and records the state changes during switching between guest and host modes. Based on this information, it analyzes whether there is resource stress within the virtual machine and, in the event of a soft lock, what causes it. To ensure the usability of the EBPF code deployed on the host system for monitoring the vCPU's execution status, in step S101, the soft lock detection cycle in the virtual machine is an integer multiple of the polling cycle of the EBPF code monitoring the vCPU's execution status. In this embodiment, the soft lock detection cycle is 20 seconds, and the polling cycle of the EBPF code monitoring the vCPU's execution status can be 1 / 4 of the soft lock detection cycle, i.e., 5 seconds.

[0025] like Figure 2 As shown, in step S101 of this embodiment, when the EBPF code deployed on the host system monitors the execution status of the virtual machine's vCPU, the EBPF code is used to intercept the `kvm_entry` and `kvm_exit` functions of the KVM virtual machine on the host system to capture the execution status of the virtual machine's vCPU calling the `kvm_entry` function to enter guest mode and calling the `kvm_exit` function to exit guest mode. After the virtual machine starts on the host, the virtual machine's vCPU thread calls the `kvm_entry` function when entering guest mode from host mode, and calls the `kvm_exit` function when exiting guest mode and entering host mode.

[0026] like Figure 2As shown, in step S101 of this embodiment, when using the EBPF code deployed on the host system to monitor the execution status of the virtual machine vCPU, it includes using the virtual machine monitoring daemon process vm_exit_monitor running on the host system to record the execution status of the virtual machine vCPU captured by the EBPF code when it calls the kvm_entry function to enter guest mode and when it calls the kvm_exit function to exit guest mode. The virtual machine monitoring daemon process vm_exit_monitor running on the host system includes the entry tracing function trace_kvm_entry and the exit tracing function. The `trace_kvm_exit` function records information about a virtual machine's vCPU entering guest mode by calling the `kvm_entry` function and stores this information in the runtime information table `vmx_vcpu_run_time`. The `trace_kvm_exit` function records the execution status of a virtual machine's vCPU exiting guest mode by calling the `kvm_exit` function and updates the runtime information table `vmx_vcpu_run_time`. It also counts the number of times a virtual machine's vCPU exits based on the reason for the vCPU's exit.

[0027] After the virtual machine starts on the host, the virtual machine's vCPU thread calls the kvm_entry function to enter guest mode, triggering the entry tracing function trace_kvm_entry of the virtual machine monitoring daemon vm_exit_monitor. In this embodiment, the execution steps of the entry tracing function trace_kvm_entry include: when the vCPU calls the kvm_entry function to enter guest mode, the entry tracing function trace_kvm_entry records the runtime information of the vCPU entering guest mode, including the process ID (PID) corresponding to the vCPU, the vCPU ID, and the entry time, and records the runtime information of the vCPU in the runtime information table vmx_vcpu_run_time using the process ID (PID) as an index. As an optional implementation, in this embodiment, when entering the trace function trace_kvm_entry to record the runtime information of the vCPU entering guest mode, the runtime information of the vCPU entering guest mode is encapsulated into a struct vcpu_runtime structure object (including the process ID PID corresponding to the vCPU, the ID of the vCPU, and the entry time), and the vcpu_runtime structure object is recorded in the runtime information table vmx_vcpu_run_time with the process ID PID corresponding to the vCPU as the index.

[0028] When a virtual machine's vCPU thread exits guest mode, it calls the `kvm_exit` function. This triggers the exit tracing function `trace_kvm_exit` of the virtual machine monitoring daemon `vm_exit_monitor`. In this embodiment, the execution steps of the exit tracing function `trace_kvm_exit` include: when the vCPU calls `kvm_exit` to exit guest mode, the exit tracing function first queries the runtime information table `vmx_vcpu_run_time` based on the process ID (PID) corresponding to the vCPU. It then updates the exit runtime information, including exit time, exit reason, and exit count statistics, in the matching runtime information in `vmx_vcpu_run_time`. Finally, it queries the exit statistics table `vmx_vcpu_exit_r` using the process ID (PID), the vCPU ID, and the exit reason as indexes (keys). `reason_count`; If no matching record is found in the exit statistics table `vmx_vcpu_exit_reason_count`, a new record is added to the exit statistics table `vmx_vcpu_exit_reason_count` with this index and the count value is initialized to 1. If a matching record is found in the exit statistics table `vmx_vcpu_exit_reason_count`, the count value of the matching record is incremented by 1. Furthermore, when the polling cycle for the execution status of the virtual machine vCPU expires, the contents of the runtime information table `vmx_vcpu_run_time` and the exit statistics table `vmx_vcpu_exit_reason_count` are output.

[0029] As an optional implementation, the runtime information table `vmx_vcpu_run_time` in this embodiment is a hash table used to record runtime information of a virtual machine's vCPU entering and exiting guest mode. This includes the process ID (PID) of a single vCPU entering and exiting guest mode, the vCPU's ID, entry time, exit time, exit reason, and exit count statistics. The exit statistics table `vmx_vcpu_exit_reason_count` is also a hash table used to count the cumulative number of exits for different vCPU reasons. Its index (key) is defined as follows:

[0030] struct _key {

[0031] u32 exit_reason;

[0032] u32 vcpu_id;

[0033] u32 pid;

[0034] }

[0035] In this table, `exit_reason`, `vcpu_id`, and `pid` represent the exit reason, the vCPU's ID, and the corresponding process ID (PID), respectively. Each time a vCPU enters guest mode, the process ID (PID), the vCPU's guest stack top pointer address (the vCPU's ID), and the entry time are recorded. This data is stored in the runtime information table `vmx_vcpu_run_time` as a key-value pair, using the vCPU's process ID (PID) as the index. When a vCPU exits guest mode, the `vmx_vcpu_run_time` table is queried using the `pid`, and the exit time, exit reason, and exit guest stack top information are updated. Simultaneously, the exit statistics table `vmx_vcpu_exit_reason_count` is updated with the cumulative count corresponding to the exit reason. At the end of each polling cycle, the data in the two hash tables are output, and the hash tables are reset. Based on the output information, if the number of external interrupts and preemption timer interrupts for the vCPU increases significantly and exceeds the system's default soft lock detection period, it can be determined that the soft lock is caused by an internal virtual machine issue. This is because if there is an internal deadlock within the virtual machine, external interrupt requests will not receive a response from the internal vCPU, causing timer interrupts and external interrupts on the host to be continuously re-injected into the virtual machine. If the data shows that a vCPU thread has not output any corresponding information within the system's default soft lock detection period, it can be determined that the internal soft lock is caused by the host load preventing the vCPU from being scheduled.

[0036] In this embodiment, updating the runtime information for exiting guest mode in the runtime information table includes: querying the runtime information table vmx_vcpu_run_time based on the process ID (PID) corresponding to the vCPU; if a matching runtime information is found, updating the runtime information for exiting guest mode in the matching runtime information in the runtime information table vmx_vcpu_run_time, including exit time, exit reason, and exit count statistics; if no matching runtime information is found, firstly, the process ID (PID) corresponding to the vCPU, the ID of the vCPU, and the entry time are recorded in the runtime information table vmx_vcpu_run_time, with the process ID (PID) corresponding to the vCPU as the index; then, updating the runtime information for exiting guest mode in the recorded runtime information, including exit time, exit reason, and exit count statistics.

[0037] In step S102 of this embodiment, when a virtual machine soft lock occurs, soft lock detection and analysis are performed based on the vCPU exiting guest mode information in the execution status of the virtual machine vCPU. If no vCPU exiting guest mode information is found within multiple consecutive soft lock detection cycles, it is determined that the virtual machine soft lock is caused by host system resource scheduling; that is, the vCPU is not executed within this cycle due to host-side resource scheduling, resulting in a soft lock within the virtual machine. For example, if no vCPU exit information is detected within 4 cycles of 20 seconds, it indicates that the vCPU is not scheduled due to host resource scheduling, triggering the watchdog inside the virtual machine to detect the soft lock. Combined with the host's running log at that time, it can be further determined whether it is caused by system computing resources or I / O resources. If the exit count statistics of vCPU exiting guest mode exceed a preset threshold (the exit count has increased significantly) within multiple consecutive soft lock detection cycles, the exit reason of vCPU exiting guest mode is checked. If the exit reason is an external interrupt exit exceeding a specified multiple (e.g., twice) of the preemption timer exit, it is determined that the virtual machine soft lock is caused by an internal virtual machine reason. For example, if a large number of exits are detected for a particular vCPU within four 20-second cycles, primarily concentrated on external interrupt exits and preemptive timer exits, with external interrupt exits being approximately twice as numerous as preemptive timer exits, it can be determined that a software lock is caused by an internal virtual machine issue. Combining this with the stack trace information from when the problem occurs within the virtual machine can further help determine the cause of the guest kernel problem.

[0038] In summary, to address the common problem of virtual machine soft lock detection in virtualization, this embodiment uses EBPF to build a system for monitoring virtual machine state transitions, thereby effectively identifying the causes of soft lock problems within virtual machines. This embodiment's method can be applied to virtualization scenarios such as cloud computing, providing effective monitoring and analysis for cloud virtual machines, cloud applications, and other systems utilizing virtualization technology.

[0039] Furthermore, this embodiment also provides a soft lock detection and analysis system based on EBPF, including a microprocessor and a memory interconnected, wherein the microprocessor is programmed or configured to execute the soft lock detection and analysis method based on EBPF.

[0040] Furthermore, this embodiment also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute the EBPF-based soft lock detection and analysis method via a processor.

[0041] In addition, this embodiment also provides a computer program product, including a computer program or instructions, which are programmed or configured to execute the EBPF-based soft lock detection and analysis method by a processor.

[0042] Those skilled in the art will understand that the technical solutions provided by this invention may take the form of a method, system, or computer program product. Therefore, this invention may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this invention may take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. 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, produce an implementation of the flowchart... Figure 1 One or more processes and / or boxes Figure 1 The 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 operate 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 functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus 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.

[0043] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A soft lock detection and analysis method based on EBPF, characterized in that, Includes the following steps: S101 uses ebpf code deployed on the host system to monitor the execution status of the virtual machine's vCPU; S102, When a virtual machine soft lock occurs, the soft lock detection and analysis is performed based on the vCPU exiting guest mode information in the execution state of the virtual machine vCPU. If no vCPU exiting guest mode information is found within multiple consecutive soft lock detection cycles, the virtual machine soft lock is determined to be caused by host system resource scheduling. If the number of times the vCPU exits guest mode exceeds a preset threshold within multiple consecutive soft lock detection cycles, the exit reason for the vCPU exiting guest mode is checked. If the exit reason for exiting due to external interrupt exceeds the specified multiple of the exit reason for preemption timer, the virtual machine soft lock is determined to be caused by an internal virtual machine reason.

2. The soft lock detection and analysis method based on EBPF according to claim 1, characterized in that, In step S101, when monitoring the execution status of the virtual machine vCPU using the ebpf code deployed on the host system, the soft lock detection cycle in the virtual machine is an integer multiple of the polling cycle of the ebpf code monitoring the execution status of the virtual machine vCPU.

3. The soft lock detection and analysis method based on EBPF according to claim 1, characterized in that, In step S101, when monitoring the execution status of the virtual machine vCPU using the ebpf code deployed on the host system, the ebpf code is used to intercept the kvm_entry function and kvm_exit function of the kvm virtual machine on the host system to capture the execution status of the virtual machine vCPU calling the kvm_entry function to enter guest mode and calling the kvm_exit function to exit guest mode.

4. The soft lock detection and analysis method based on EBPF according to claim 1, characterized in that, In step S101, when monitoring the execution status of the virtual machine vCPU using the ebpf code deployed on the host system, the process includes using a virtual machine monitoring daemon running on the host system to record the execution status of the virtual machine vCPU when the ebpf code captures the kvm_entry function to enter guest mode and the kvm_exit function to exit guest mode. The virtual machine monitoring daemon running on the host system includes an entry tracing function and an exit tracing function. The entry tracing function is used to record the information of the virtual machine vCPU calling the kvm_entry function to enter guest mode and record it in the runtime information table. The exit tracing function is used to record the execution status of the virtual machine vCPU calling the kvm_exit function to exit guest mode and update the runtime information table. It also counts the number of times the virtual machine vCPU exits based on the exit reason.

5. The soft lock detection and analysis method based on EBPF according to claim 4, characterized in that, The execution steps of the entry tracing function include: when the vCPU calls the kvm_entry function to enter guest mode, the entry tracing function records the runtime information of the vCPU entering guest mode, including the process ID (PID) corresponding to the vCPU, the ID of the vCPU, and the entry time, and records the runtime information of the vCPU in the runtime information table with the process ID (PID) corresponding to the vCPU as the index.

6. The soft lock detection and analysis method based on EBPF according to claim 5, characterized in that, The execution steps of the exit tracing function include: when the vCPU calls the kvm_exit function to exit guest mode, the exit tracing function first queries the runtime information table based on the process ID (PID) corresponding to the vCPU, and updates the runtime information for exiting guest mode in the runtime information table that matches the runtime information, including exit time, exit reason, and exit count statistics; then, it queries the exit statistics table based on the process ID (PID) corresponding to the vCPU, the vCPU ID, and the exit reason as indexes. If no matching record is found in the exit statistics table, a new record is added to the exit statistics table with the index and the count value is initialized to 1. If a matching record is found in the exit statistics table, the count value of the matching record is incremented by 1; and when the polling cycle of the virtual machine vCPU's execution status expires, the contents of the runtime information table and the exit statistics table are output.

7. The soft lock detection and analysis method based on EBPF according to claim 6, characterized in that, The step of updating the runtime information for exiting guest mode in the runtime information table includes: querying the runtime information table based on the process ID (PID) corresponding to the vCPU; if a matching runtime information is found, updating the runtime information for exiting guest mode in the matching runtime information table, including exit time, exit reason, and exit count statistics; if no matching runtime information is found, firstly, the process ID (PID) corresponding to the vCPU, the vCPU ID, and the entry time are used, and the runtime information of the vCPU is recorded in the runtime information table with the process ID (PID) corresponding to the vCPU as the index, and then updating the runtime information for exiting guest mode in the recorded runtime information, including exit time, exit reason, and exit count statistics.

8. A soft lock detection and analysis system based on EBPF, comprising a microprocessor and a memory interconnected, characterized in that, The microprocessor is programmed or configured to execute the EBPF-based soft lock detection and analysis method according to any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the EBPF-based soft lock detection and analysis method according to any one of claims 1 to 7 via a processor.

10. A computer program product, comprising a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the EBPF-based soft lock detection and analysis method according to any one of claims 1 to 7 via a processor.

Images