Virtual CPU thread positioning method and device, equipment and storage medium

Abstract

The invention discloses a virtual CPU thread positioning method and device, equipment and a storage medium, and the virtual CPU thread positioning method comprises the steps: in a physical LAPIC transparent transmission mode, receiving a virtual CPU thread positioning request initiated through a debugging interface of a target virtual machine; executing the target operation on each virtual CPU of the target virtual machine; the target operation comprises the steps of determining a physical CPU of a host machine where the target virtual CPU is located; sending a non-maskable interrupt NMI to the determined physical CPU to force the target virtual CPU to exit from the virtual machine mode to the host machine mode; and in the NMI processing flow of the host machine, outputting a kernel stack, on the host machine side, of the thread of the target virtual CPU to a kernel log. By applying the technical scheme provided by the invention, the effective positioning of the virtual CPU thread in the physical LAPIC transparent transmission mode is realized.

Description

Technical Field

[0001] This application belongs to the field of computer application technology, and specifically relates to a virtual CPU thread location method, apparatus, device and storage medium. Background Technology

[0002] In traditional kernel-based virtual machine (KVM) virtualization solutions, the virtual CPU (vCPU) of a virtual machine appears as an independent thread on the host side. Meanwhile, the virtual machine's local advanced programmable interrupt controller (LAPIC) is typically implemented in software. In this scenario, system administrators can use various conventional debugging techniques on the host side to examine the virtual CPU thread's execution stack in kernel mode, i.e., the kernel stack. By analyzing the virtual CPU thread's kernel stack, they can pinpoint issues such as virtual CPU stuttering, anomalies, or performance bottlenecks.

[0003] Currently, in pursuit of higher performance and lower latency, physical LAPIC pass-through technology has emerged. This involves directly passing the entire physical LAPIC of the host machine's physical CPU to the virtual machine for use, while the host machine cannot access it. This allows the virtual machine to directly manage interrupts, avoiding the performance overhead of software emulation. To achieve this, the corresponding physical CPU is typically set to an offline state on the host side, and then its physical LAPIC is passed through to the virtual machine.

[0004] While this physical LAPIC pass-through mode brings performance advantages, it also introduces debugging challenges. Specifically, since the physical CPU is offline on the host side and invisible to the host, and its physical LAPIC has been passed through to the virtual machine, all external interrupts will be handled directly by the virtual machine. Therefore, when an external interrupt occurs, the virtual CPU will not exit from virtual machine mode to host mode. As a result, conventional debugging methods cannot obtain the kernel stack of the virtual CPU's threads on the host side, making it impossible to effectively locate the virtual CPU threads. Summary of the Invention

[0005] The purpose of this application is to provide a method, apparatus, device, and storage medium for locating virtual CPU threads, so as to effectively locate virtual CPU threads in physical LAPIC pass-through mode.

[0006] To solve the above-mentioned technical problems, this application provides the following technical solution: Firstly, a method for locating virtual CPU threads is provided, including: In the Physical Local Advanced Programmable Interrupt Controller (LAPIC) pass-through mode, it receives virtual central processing unit (CPU) thread location requests initiated through the debug interface of the target virtual machine. The target operation is performed on each virtual CPU of the target virtual machine; The target operation includes: Determine the physical CPU of the host machine where the target virtual CPU is located, wherein the target virtual CPU is any virtual CPU of the target virtual machine; Send a non-maskable interrupt (NMI) to the identified physical CPU to force the target virtual CPU to exit virtual machine mode and enter host mode; In the NMI processing flow of the host machine, the thread of the target virtual CPU is output from the kernel stack on the host machine side to the kernel log; The debugging interface of the target virtual machine is created during the creation of the target virtual machine.

[0007] Optionally, performing the target operation on each virtual CPU of the target virtual machine includes: The target operation is executed sequentially on each virtual CPU of the target virtual machine; or, The target operation is performed in parallel on each virtual CPU of the target virtual machine.

[0008] Optionally, after performing the target operation on each virtual CPU of the target virtual machine, the method further includes: The threads of each virtual CPU that output to the kernel log are persistently stored on the kernel stack on the host side.

[0009] Optionally, determining the physical CPU of the host machine where the target virtual CPU resides includes: Based on the thread identifier corresponding to the target virtual CPU in the host machine, the physical CPU of the host machine where the target virtual CPU is located is determined by querying the internal data structure of the kernel-based virtual machine KVM or the kernel thread scheduling information.

[0010] Optionally, the debug interface of the target virtual machine is registered with read functionality, and receiving the virtual central processing unit (CPU) thread location request initiated through the debug interface of the target virtual machine includes: Receive a virtual CPU thread location request initiated through a read operation on the debug interface of the target virtual machine.

[0011] Secondly, a virtual CPU thread positioning device is provided, comprising: The request receiving module is used to receive virtual central processing unit (CPU) thread location requests initiated through the debug interface of the target virtual machine in the physical local advanced programmable interrupt controller (LAPIC) pass-through mode. An operation execution module is used to execute the target operation on each virtual CPU of the target virtual machine; The target operation includes: Determine the physical CPU of the host machine where the target virtual CPU is located, wherein the target virtual CPU is any virtual CPU of the target virtual machine; Send a non-maskable interrupt (NMI) to the identified physical CPU to force the target virtual CPU to exit virtual machine mode and enter host mode; In the NMI processing flow of the host machine, the thread of the target virtual CPU is output from the kernel stack on the host machine side to the kernel log; The debugging interface of the target virtual machine is created during the creation of the target virtual machine.

[0012] Optionally, the operation execution module is specifically used for: The target operation is executed sequentially on each virtual CPU of the target virtual machine; or, The target operation is performed in parallel on each virtual CPU of the target virtual machine.

[0013] Optionally, it also includes a storage module for: After the target operation is executed on each virtual CPU of the target virtual machine, the threads of each virtual CPU that are output to the kernel log are persistently stored on the kernel stack on the host side.

[0014] Thirdly, an electronic device is provided, comprising a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method as described in the first aspect.

[0015] Fourthly, a readable storage medium is provided, on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method as described in the first aspect.

[0016] Fifthly, a program product is provided, the program product including instructions stored in a readable storage medium and adapted to be read and executed by a processor to cause a device having the processor to perform the steps of the method as described in the first aspect.

[0017] In a sixth aspect, a chip is provided, the chip including a processor and a communication interface coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.

[0018] By applying the technical solution provided in the embodiments of this application, in the physical LAPIC pass-through mode, when a virtual CPU thread location request initiated through the debugging interface of the target virtual machine is received, a target operation is performed on each virtual CPU of the target virtual machine. The target operation includes determining the physical CPU of the host machine where the target virtual CPU is located, sending an NMI to the determined physical CPU, forcing the target virtual CPU to exit from virtual machine mode to host machine mode, and outputting the thread of the target virtual CPU on the kernel stack on the host machine side to the kernel log in the NMI processing flow of the host machine. This breaks through the technical barrier that conventional debugging methods fail in the physical LAPIC pass-through mode, realizes the effective location of virtual CPU threads in the physical LAPIC pass-through mode, provides a key basis for virtual machine problem diagnosis, and helps to improve the fault diagnosis efficiency and overall service stability of the virtualization platform.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating one implementation of the virtual CPU location method in this application. Figure 2 This is a flowchart illustrating another implementation of the virtual CPU location method in this application. Figure 3 This is a schematic diagram illustrating the virtual machine and debugging interface creation process in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of a virtual CPU positioning device according to an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, not limited in number; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0024] The virtual CPU thread location method provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0025] See Figure 1 The diagram shown is an implementation flowchart of the virtual CPU thread location method provided in this application embodiment. The method may include the following steps: S110: In the Physical Local Advanced Programmable Interrupt Controller (LAPIC) pass-through mode, receives virtual central processing unit (CPU) thread location requests initiated through the debug interface of the target virtual machine.

[0026] The debug interface of the target virtual machine is created during the creation of the target virtual machine.

[0027] In this embodiment, the target virtual machine can be any KVM virtual machine created on the host machine. During the KVM virtual machine creation process, a virtual machine-based debugging interface can be created, with different debugging interfaces corresponding to different virtual machines.

[0028] For example, a debug interface can be created in the following path: / proc / kvm / <per guest> / debug; Here, / proc represents the root directory of the virtual process file system (procfs), which is dynamically generated by the kernel in memory and is used to provide an interface for accessing kernel and process information; / proc / kvm represents the entries created after the KVM kernel module is loaded, used to display KVM-related status information; / proc / kvm / <per guest> This means creating a subdirectory named after the identifier of each KVM virtual machine.<per guest> A unique identifier for a virtual machine, such as guest-1 or guest-2; / proc / kvm / <per guest> / debug represents the debug interface file created in the corresponding virtual machine directory.

[0029] In the physical LAPIC pass-through mode, the physical LAPIC of one or more physical central processing units (CPUs) of the host machine is passed through to the target virtual machine. Each virtual CPU of the target virtual machine corresponds to a physical LAPIC, and different virtual CPUs correspond to different physical LAPICs. The corresponding physical CPUs are offline on the host side.

[0030] When users or other monitoring systems have a need to locate virtual CPU threads, a virtual CPU thread location request can be initiated through the debug interface of the target virtual machine.

[0031] After receiving a virtual CPU thread location request initiated through the debug interface of the target virtual machine, you can continue to perform subsequent steps.

[0032] S120: Execute the target operation on each virtual CPU of the target virtual machine: The target operations include: Determine the physical CPU of the host machine where the target virtual CPU is located. The target virtual CPU can be any virtual CPU of the target virtual machine. Send a non-maskable interrupt (NMI) to the identified physical CPU to force the target virtual CPU to exit virtual machine mode and enter host mode; In the NMI processing flow on the host machine, the thread of the target virtual CPU is output from the kernel stack on the host machine side to the kernel log.

[0033] In this embodiment, under physical LAPIC pass-through mode, after receiving a virtual CPU thread location request initiated through the debug interface of the target virtual machine, the target operation can be performed on each virtual CPU of the target virtual machine. Optionally, all virtual CPUs of the target virtual machine can be obtained through KVM internal data structures.

[0034] For any virtual CPU of the target virtual machine, i.e. the target virtual CPU, you can first determine the physical CPU of the host machine where the target virtual CPU is located, and then send an NMI to the determined physical CPU.

[0035] Since the physical LAPIC has been passed to the target virtual machine, regular interrupts cannot trigger the virtual machine to exit. However, NMI is a non-maskable interrupt and cannot be masked. If an NMI occurs, the execution of the current program must be stopped and the process must jump to the NMI handling flow. Therefore, after determining the physical CPU where the target virtual CPU is located and sending an NMI to that physical CPU, the offline physical CPU can be triggered to respond, forcing the target virtual CPU to exit from virtual machine mode to host mode.

[0036] After sending an NMI to the physical CPU, forcing the target virtual CPU to exit virtual machine mode and return to host mode, the host machine processes the NMI. During the host machine's NMI processing, the kernel stack of the target virtual CPU's thread on the host side can be obtained and output to the kernel log.

[0037] Optionally, the NMI can be processed through the corresponding interrupt handling function provided by the kernel, and the thread of the target virtual CPU can be output to the kernel log on the host side kernel stack.

[0038] The kernel log can be understood as a kernel circular buffer, and the kernel stack can be understood as the kernel-mode execution stack. The kernel stack can include key debugging information such as function call chains and thread states.

[0039] Optionally, if the physical CPU of the host machine where the target virtual CPU is located cannot be determined during the process of determining the physical CPU of the host machine where the target virtual CPU is located, an error message can be recorded and the relevant operations on the target virtual CPU can be stopped.

[0040] Optionally, if sending the NMI to the identified physical CPU fails, the error message can be logged and the relevant operations on the target virtual CPU can be stopped.

[0041] The target virtual CPU is any virtual CPU of the target virtual machine. After the target operation is executed on each virtual CPU of the target virtual machine, the threads of each virtual CPU of the target virtual machine are output to the kernel log on the kernel stack on the host side, which enables the virtual CPU threads to be effectively located in the physical LAPIC pass-through mode.

[0042] Applying the method provided in the embodiments of this application, in the physical LAPIC pass-through mode, upon receiving a virtual CPU thread location request initiated through the debugging interface of the target virtual machine, a target operation is performed on each virtual CPU of the target virtual machine. This target operation includes determining the physical CPU of the host machine where the target virtual CPU is located, sending an NMI to the determined physical CPU, forcing the target virtual CPU to exit from virtual machine mode to host machine mode, and outputting the thread of the target virtual CPU on the kernel stack on the host machine side to the kernel log in the NMI processing flow of the host machine. This breaks through the technical barrier that conventional debugging methods fail in the physical LAPIC pass-through mode, realizes the effective location of virtual CPU threads in the physical LAPIC pass-through mode, provides a key basis for virtual machine problem diagnosis, and helps to improve the fault diagnosis efficiency and overall service stability of the virtualization platform.

[0043] In some embodiments of this application, after performing the target operation on each virtual CPU of the target virtual machine, the method may further include the following steps: The threads of each virtual CPU that output to the kernel log are persistently stored on the kernel stack on the host machine side.

[0044] In this embodiment, under the physical LAPIC pass-through mode, upon receiving a virtual CPU thread location request initiated through the debug interface of the target virtual machine, after executing the target operation on each virtual CPU of the target virtual machine, the kernel stacks of each virtual CPU's threads on the host side are all output to the kernel log. Therefore, the kernel stacks of each virtual CPU's threads output to the kernel log on the host side can be persistently stored. Optionally, the kernel stacks of each virtual CPU's threads on the host side can be persistently stored through a system log daemon.

[0045] The threads of each virtual CPU are persistently stored on the kernel stack on the host machine side, which facilitates subsequent offline analysis and problem tracing.

[0046] In some embodiments of this application, performing the target operation on each virtual CPU of the target virtual machine may include the following steps: The target operation is executed sequentially on each virtual CPU of the target virtual machine.

[0047] In this embodiment, under the physical LAPIC pass-through mode, upon receiving a virtual CPU thread location request initiated through the target virtual machine's debug interface, the target operation can be executed sequentially on each virtual CPU of the target virtual machine. This can be understood as: first, the target operation is executed on the first virtual CPU of the target virtual machine; after the target operation is completed, the target operation is executed on the second virtual CPU of the target virtual machine; after the target operation is completed, the target operation is executed on the third virtual CPU of the target virtual machine, and so on, until the target operation on the Nth virtual CPU of the target virtual machine is completed. N is the number of virtual CPUs in the target virtual machine. The order of the virtual CPUs can be random.

[0048] like Figure 2 As shown, one possible implementation process is as follows: In physical LAPIC pass-through mode, receive virtual CPU thread location requests; Determine the physical CPU of the host machine where an unprocessed virtual CPU of the target virtual machine resides; Send NMI to the identified physical CPU; In the NMI processing flow on the host machine, the thread of the virtual CPU is output from the kernel stack on the host machine side to the kernel log; First, determine if all virtual CPUs of the target virtual machine have completed processing. If not, proceed to the second step: determine the physical CPU of the host machine where the unprocessed virtual CPU of the target virtual machine resides. Then, continue executing the steps of sending an NMI to the determined physical CPU and, within the host machine's NMI processing flow, outputting the thread of that virtual CPU to the kernel log on the host machine's kernel stack. This process determines if all virtual CPUs of the target virtual machine have completed processing. If all virtual CPUs of the target virtual machine have completed processing, persistently store the kernel stack of each virtual CPU's thread on the host machine's kernel stack.

[0049] Persistent storage of the kernel stacks of each virtual CPU's threads on the host side can also be understood as storing the kernel stacks of each virtual CPU's threads on the host side from the kernel logs into a persistent file through a security interface.

[0050] Executing the target operation sequentially on each virtual CPU of the target virtual machine can effectively avoid information confusion that may be caused by multiple NMIs being triggered simultaneously.

[0051] In some embodiments of this application, performing the target operation on each virtual CPU of the target virtual machine may include the following steps: The target operation is performed in parallel on each virtual CPU of the target virtual machine.

[0052] In the embodiments of this application, in the physical LAPIC pass-through mode, when a virtual CPU thread location request initiated through the debug interface of the target virtual machine is received, the target operation can be performed on each virtual CPU of the target virtual machine in parallel.

[0053] Specifically, you can first determine the physical CPU of the host machine where each virtual CPU of the target virtual machine is located, and then send NMI to each determined physical CPU at the same time to force each virtual CPU to exit from virtual machine mode to host machine mode. In each NMI processing flow on the host machine, the thread of the corresponding virtual CPU is output from the kernel stack on the host machine side to the kernel log.

[0054] Executing the target operation on each virtual CPU of the target virtual machine in parallel can improve processing speed and reduce overall waiting time.

[0055] It should be noted that in the embodiments of this application, some operations in the target operation can be executed in parallel, and some operations can be executed sequentially. For example, in the physical LAPIC pass-through mode, when a virtual CPU thread location request initiated through the debug interface of the target virtual machine is received, the physical CPUs of the host machine where all virtual CPUs of the target virtual machine are located are first determined (this operation is executed in parallel), and then NMI is sent to each determined physical CPU in sequence. That is, NMI is first sent to the first determined physical CPU, forcing the virtual CPU corresponding to the first physical CPU to exit from virtual machine mode to host machine mode. In the NMI processing flow of the host machine, the thread of the virtual CPU is output to the kernel log on the kernel stack on the host machine side, and then sent to... The second identified physical CPU sends an NMI, forcing the virtual CPU corresponding to this second physical CPU to exit from virtual machine mode to host mode. In the host's NMI processing flow, the thread of this virtual CPU is output to the kernel log on the host's kernel stack. Then, an NMI is sent to the third identified physical CPU, and so on, until an NMI is sent to the Mth identified physical CPU, forcing the virtual CPU corresponding to the Mth physical CPU to exit from virtual machine mode to host mode. In the host's NMI processing flow, the thread of this virtual CPU is output to the kernel log on the host's kernel stack. M is the total number of identified physical CPUs.

[0056] In some embodiments of this application, determining the physical CPU of the host machine where the target virtual CPU resides may include the following steps: Based on the thread identifier corresponding to the target virtual CPU in the host machine, the physical CPU of the host machine where the target virtual CPU resides is determined by querying the internal data structure of the kernel-based virtual machine KVM or the kernel thread scheduling information.

[0057] In this embodiment, during the execution of the target operation on the target virtual CPU of the target virtual machine, it is necessary to determine the physical CPU of the host machine where the target virtual CPU resides. This can be achieved by first determining the thread identifier corresponding to the target virtual CPU on the host machine. In a virtualization environment, each virtual CPU is represented as a thread on the host machine side. The thread identifier corresponding to the target virtual CPU can be understood as a unique identifier for the thread of the target virtual CPU within the host operating system; it can be a thread ID or a process ID.

[0058] Based on the thread identifier corresponding to the target virtual CPU in the host machine, the KVM internal data structure can be queried. By querying the KVM internal data structure, the identifier of the physical CPU corresponding to the thread identifier of the target virtual CPU in the host machine can be obtained, and thus the physical CPU of the host machine where the target virtual CPU resides can be determined.

[0059] Alternatively, based on the thread identifier corresponding to the target virtual CPU in the host machine, kernel thread scheduling information can be queried. By querying the kernel thread scheduling information, the identifier of the physical CPU corresponding to the thread identifier of the target virtual CPU in the host machine can be obtained, and thus the physical CPU of the host machine where the target virtual CPU resides can be determined.

[0060] Based on the thread identifier corresponding to the target virtual CPU and the KVM internal data structure or kernel thread scheduling information, the physical CPU of the host machine where the target virtual CPU is located can be quickly and accurately determined.

[0061] In some embodiments of this application, the debug interface of the target virtual machine is registered with read functionality to receive virtual CPU thread location requests initiated through the debug interface of the target virtual machine, which may include the following steps: Receive virtual CPU thread location requests initiated through read operations on the debug interface of the target virtual machine.

[0062] In this embodiment of the application, a debug interface for the target virtual machine can be created during the creation of the target virtual machine, and a read function can be registered. In this way, when the user has a need to locate the virtual CPU thread of the target virtual machine, he / she can perform a read operation on the debug interface of the target virtual machine.

[0063] like Figure 3 As shown, the process of creating the virtual machine and debugging interface is as follows: Create a process file system, such as procfs; Create a debug interface; Register the debug interface read function; Virtual machine creation complete.

[0064] Upon receiving a read operation on the debug interface of the target virtual machine, it is considered that a virtual CPU thread location request has been received, which can trigger virtual CPU thread location.

[0065] The debug interface registration has a read function, which provides users with an interactive means to trigger the location process through a simple read operation, without the need for additional tools or complex commands.

[0066] In the physical LAPIC pass-through mode, when conventional debugging methods are unavailable, the technical solution provided in this application allows access to the virtual machine's debugging interface and the active sending of an NMI to the physical CPU where the virtual CPU resides. During the NMI interrupt handling process, the host machine outputs the kernel stack of the virtual CPU's thread to the host machine's kernel log. The kernel stack can help locate related problems.

[0067] It should be noted that the virtual CPU thread location method provided in this application embodiment can be executed by a virtual CPU thread location device, or by a control module in the virtual CPU thread location device for executing the virtual CPU thread location method. This application embodiment uses the execution of the virtual CPU thread location method by a virtual CPU thread location device as an example to illustrate the virtual CPU thread location method provided in this application embodiment.

[0068] See Figure 4 The diagram shown is a structural schematic of a virtual CPU thread positioning device provided in an embodiment of this application, comprising the following modules: The request receiving module 410 is used to receive a virtual CPU thread location request initiated through the debug interface of the target virtual machine in the Physical Local Advanced Programmable Interrupt Controller (LAPIC) pass-through mode. The operation execution module 420 is used to execute the target operation on each virtual CPU of the target virtual machine; The target operations include: Determine the physical CPU of the host machine where the target virtual CPU is located. The target virtual CPU can be any virtual CPU of the target virtual machine. Send a non-maskable interrupt (NMI) to the identified physical CPU to force the target virtual CPU to exit virtual machine mode and return to host mode; In the NMI processing flow on the host machine, the thread of the target virtual CPU is output from the kernel stack on the host machine side to the kernel log; The debug interface of the target virtual machine is created during the creation of the target virtual machine.

[0069] The apparatus provided in this application, in physical LAPIC pass-through mode, upon receiving a virtual CPU thread location request initiated through the debugging interface of the target virtual machine, performs a target operation on each virtual CPU of the target virtual machine. This target operation includes determining the physical CPU of the host machine where the target virtual CPU resides, sending an NMI to the determined physical CPU, forcing the target virtual CPU to exit from virtual machine mode to host machine mode, and outputting the target virtual CPU thread from the host machine's NMI processing flow to the kernel log on the host machine side's kernel stack. This breaks through the technical barrier that conventional debugging methods fail in physical LAPIC pass-through mode, achieving effective location of virtual CPU threads in physical LAPIC pass-through mode. This provides a crucial basis for virtual machine problem diagnosis and helps improve the fault diagnosis efficiency and overall service stability of the virtualization platform.

[0070] In some embodiments of this application, the operation execution module 420 is specifically used for: Execute the target operation sequentially on each virtual CPU of the target virtual machine; or, The target operation is performed in parallel on each virtual CPU of the target virtual machine.

[0071] In some embodiments of this application, a storage module is also included for: After the target operation is executed on each virtual CPU of the target virtual machine, the threads of each virtual CPU that are output to the kernel log are persistently stored on the kernel stack on the host side.

[0072] In some embodiments of this application, the operation execution module 420 is specifically used for: Based on the thread identifier corresponding to the target virtual CPU in the host machine, the physical CPU of the host machine where the target virtual CPU resides is determined by querying the internal data structure of the kernel-based virtual machine KVM or the kernel thread scheduling information.

[0073] In some embodiments of this application, the debug interface of the target virtual machine is registered with a read function, and the request receiving module 410 is specifically used for: Receive virtual CPU thread location requests initiated through read operations on the debug interface of the target virtual machine.

[0074] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the relevant method embodiments, and will not be repeated here to avoid repetition.

[0075] Corresponding to the above method embodiments, this application also provides an electronic device, including: Memory, used to store computer programs; A processor is used to implement the steps of the virtual CPU positioning method described above when executing a computer program.

[0076] like Figure 5 The diagram shows the structural composition of an electronic device, which may include a processor 10, a memory 11, a communication interface 12, and a communication bus 13. The processor 10, memory 11, and communication interface 12 all communicate with each other through the communication bus 13.

[0077] In this embodiment, the processor 10 may be a central processing unit (CPU), an application-specific integrated circuit, a digital signal processor, a field-programmable gate array, or other programmable logic devices.

[0078] The processor 10 can call programs stored in the memory 11. Specifically, the processor 10 can execute the operations in the method embodiment.

[0079] The memory 11 is used to store one or more programs. The programs may include program code, which includes computer operation instructions. In this embodiment, the memory 11 stores at least a program for implementing the following functions: In the Physical Local Advanced Programmable Interrupt Controller (LAPIC) pass-through mode, it receives virtual CPU thread location requests initiated through the debug interface of the target virtual machine. The target operation is performed on each virtual CPU of the target virtual machine. The target operations include: Determine the physical CPU of the host machine where the target virtual CPU is located. The target virtual CPU can be any virtual CPU of the target virtual machine. Send a non-maskable interrupt (NMI) to the identified physical CPU to force the target virtual CPU to exit virtual machine mode and return to host mode; In the NMI processing flow on the host machine, the thread of the target virtual CPU is output from the kernel stack on the host machine side to the kernel log; The debug interface of the target virtual machine is created during the creation of the target virtual machine.

[0080] The electronic device provided in this application embodiment, in physical LAPIC pass-through mode, upon receiving a virtual CPU thread location request initiated through the debugging interface of the target virtual machine, performs a target operation on each virtual CPU of the target virtual machine. This target operation includes determining the physical CPU of the host machine where the target virtual CPU is located, sending an NMI to the determined physical CPU, forcing the target virtual CPU to exit from virtual machine mode to host machine mode, and outputting the thread of the target virtual CPU on the kernel stack on the host machine side to the kernel log in the NMI processing flow of the host machine. This breaks through the technical barrier that conventional debugging methods fail in physical LAPIC pass-through mode, realizes effective location of virtual CPU threads in physical LAPIC pass-through mode, provides key basis for virtual machine problem diagnosis, and helps to improve the fault diagnosis efficiency and overall service stability of the virtualization platform.

[0081] In one possible implementation, the memory 11 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; and the data storage area may store data created during use.

[0082] In addition, memory 11 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device or other volatile solid-state storage device.

[0083] Communication interface 12 can be an interface for the communication module, used to connect with other devices or systems.

[0084] Of course, it should be noted that, Figure 5 The structure shown does not constitute a limitation on the electronic device in the embodiments of this application. In practical applications, the electronic device may include more than Figure 5 More or fewer components as shown, or combinations of certain components.

[0085] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0086] The processor is the processor in the above-described electronic device embodiment. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0087] Furthermore, it should be noted that this application also provides a program product or program, which may include instructions that can be stored in a readable storage medium. The processor of the device reads the instructions from the readable storage medium and executes the instructions, causing the device to perform the descriptions in the corresponding method embodiments above; therefore, these will not be repeated here. Additionally, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the program product or program embodiments involved in this application, please refer to the descriptions in the method embodiments of this application.

[0088] This application also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0089] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0090] It should be noted that, in this document, 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 limitations, 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 that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0091] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0092] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many different implementations and modifications to this application without departing from the spirit and scope of the claims. All such implementations, improvements and modifications are within the scope of protection of this application.

Claims

1. A method for locating virtual CPU threads, characterized in that, include: In the Physical Local Advanced Programmable Interrupt Controller (LAPIC) pass-through mode, it receives virtual central processing unit (CPU) thread location requests initiated through the debug interface of the target virtual machine. The target operation is performed on each virtual CPU of the target virtual machine; The target operation includes: Determine the physical CPU of the host machine where the target virtual CPU is located, wherein the target virtual CPU is any virtual CPU of the target virtual machine; Send a non-maskable interrupt (NMI) to the identified physical CPU to force the target virtual CPU to exit virtual machine mode and enter host mode; In the NMI processing flow of the host machine, the thread of the target virtual CPU is output from the kernel stack on the host machine side to the kernel log; The debugging interface of the target virtual machine is created during the creation of the target virtual machine.

2. The method according to claim 1, characterized in that, The step of performing the target operation on each virtual CPU of the target virtual machine includes: The target operation is executed sequentially on each virtual CPU of the target virtual machine; or, The target operation is performed in parallel on each virtual CPU of the target virtual machine.

3. The method according to claim 1, characterized in that, After performing the target operation on each virtual CPU of the target virtual machine, the method further includes: The threads of each virtual CPU that output to the kernel log are persistently stored on the kernel stack on the host side.

4. The method according to claim 1, characterized in that, The process of determining the physical CPU of the host machine where the target virtual CPU resides includes: Based on the thread identifier corresponding to the target virtual CPU in the host machine, the physical CPU of the host machine where the target virtual CPU is located is determined by querying the internal data structure of the kernel-based virtual machine KVM or the kernel thread scheduling information.

5. The method according to claim 1, characterized in that, The target virtual machine's debug interface is registered with read functionality. Receiving a virtual central processing unit (CPU) thread location request initiated through the target virtual machine's debug interface includes: Receive a virtual CPU thread location request initiated through a read operation on the debug interface of the target virtual machine.

6. A virtual CPU thread location device, characterized in that, include: The request receiving module is used to receive virtual CPU thread location requests initiated through the debug interface of the target virtual machine in the Physical Local Advanced Programmable Interrupt Controller (LAPIC) pass-through mode. An operation execution module is used to execute the target operation on each virtual CPU of the target virtual machine; The target operation includes: Determine the physical CPU of the host machine where the target virtual CPU is located, wherein the target virtual CPU is any virtual CPU of the target virtual machine; Send a non-maskable interrupt (NMI) to the identified physical CPU to force the target virtual CPU to exit virtual machine mode and enter host mode; In the NMI processing flow of the host machine, the thread of the target virtual CPU is output from the kernel stack on the host machine side to the kernel log; The debugging interface of the target virtual machine is created during the creation of the target virtual machine.

7. The apparatus according to claim 6, characterized in that, The operation execution module is specifically used for: The target operation is executed sequentially on each virtual CPU of the target virtual machine; or, The target operation is performed in parallel on each virtual CPU of the target virtual machine.

8. The apparatus according to claim 6, characterized in that, It also includes a storage module for: After the target operation is performed on each virtual CPU of the target virtual machine, the threads of each virtual CPU whose kernel logs are persistently stored on the kernel stack on the host side.

9. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein when the program or instructions are executed by the processor, they implement the steps of the virtual CPU thread location method as described in any one of claims 1 to 5.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the virtual CPU thread location method as described in any one of claims 1 to 5.

Images