A method, device, medium and product for single-step operation of virtual machines using Hypervisor

Abstract

The present invention provides a method, device, medium and product for single-step operation of a virtual machine using a Hypervisor, including: based on a xen Hypervisor virtual machine monitor, a GDB simulation program is run in dom0, and a GdbServer simulation program is run in a hypervisor layer; the GDB simulation program interacts with user commands and performs parameter parsing, and the parsing information is passed to the GdbServer simulation program, and the domu target program virtual machine is run; the GdbServer simulation program controls the domu target program virtual machine to achieve target program breakpoints and single-step operation. The present invention uses a pure software solution to achieve the single-step operation function of non-Linux application layer software debugging, making up for the lack of GDB coverage scenarios. It allows developers to quickly develop programs and debug problems, and solve problems in programs.

Description

Technical Field

[0001] The present invention belongs to the field of information technology, and in particular relates to a method, device, medium and product for single-step operation of a virtual machine using a Hypervisor. Background Art

[0002] GNU debugger (GDB) is often used in program development. It can help developers quickly locate problems and debug when errors occur in the program. During the debugging process, breakpoints and single-step running are very useful tools that can help developers control the execution flow of the program and observe the program status. Breakpoints allow developers to pause execution when the program reaches a specified location in order to observe the status and execution of the program. By setting breakpoints, developers can execute the program step by step and stop at a specific location to check the value of variables, the return result of functions, etc., so as to quickly locate errors in the program. Using single-step running debugging allows developers to observe the execution path of the program and understand how the control flow of the program is transferred, so as to better understand the structure and logic of the program. It can be said that breakpoints and single-step running are the basis of GDB program debugging, locating problems, tracking program execution flow, and interactive debugging.

[0003] At present, GDB is mainly used in Linux application layer programs, because Linux application layer provides rich tools for GDB. For the Linux kernel, KGDB (Kernel GNU Debugger) is used, which allows setting breakpoints and tracking program execution while the Linux kernel is running. However, KGDB is not suitable for all situations, such as concurrency problems or performance problems. Moreover, KGDB has a large performance overhead, and its deployment configuration is complex and not easy to apply. For RTOS systems with imperfect ecosystems, there is generally no support for GDB. For debugging requirements that cannot be achieved by such software, additional hardware is usually used to achieve them, such as the trace32 debugger. However, this hardware debugger is expensive and also has some limitations in use. Summary of the invention

[0004] The purpose of the present invention is to provide a method, device, medium and product for single-step operation of a virtual machine using a hypervisor, and to use a pure software solution to implement the single-step operation function of non-Linux application layer software debugging such as the Linux kernel and RTOS system, thereby making up for the lack of GDB coverage scenarios. This allows developers to quickly develop programs and debug problems, and solve problems in programs.

[0005] In order to achieve the above object, the technical solution of the present invention is as follows:

[0006] A method for single-stepping a virtual machine using a Hypervisor, comprising:

[0007] Based on the xen Hypervisor virtual machine monitor, a GDB simulation program is run in dom0, and a GdbServer simulation program is run in the hypervisor layer; the GDB simulation program interacts with user commands and performs parameter parsing, and the parsed information is passed to the GdbServer simulation program, and the domu target program virtual machine is run; the GdbServer simulation program controls the domu target program virtual machine to achieve target program breakpoints and single-step running.

[0008] Furthermore, the parsing information passed by the GDB simulation program to the GdbServer simulation program includes the correspondence between each function of the target program, the line number of the source file and the assembly instruction, and also includes the relative position of each instruction function of the target program in the memory.

[0009] Furthermore, the target program breakpoint implementation method includes:

[0010] S101, a breakpoint linked list is maintained in the GdbServer simulation program, and the linked list includes the breakpoint addresses and breakpoint conditions parsed by the GDB simulation program from the user command;

[0011] S102, GdbServer simulation program controls domu target program virtual machine to pause, and inserts breakpoint instruction according to the breakpoint address in the linked list;

[0012] S103, the GdbServer simulation program controls the operation of the domu target program virtual machine, and after running to the breakpoint instruction, jumps to the GdbServer simulator, compares the breakpoint conditions with those in the breakpoint linked list, and determines whether the breakpoint is hit.

[0013] Furthermore, the method for implementing the single-step running of the target program includes:

[0014] S201, using temporary breakpoints to simulate single-stepping, inserting a temporary breakpoint at the next instruction of the instruction to be executed, and then allowing the target program to continue running. After the current instruction is executed, the target program encounters a temporary breakpoint at the next instruction, and stops. When GdbServer determines that the breakpoint is hit, the breakpoint is deleted to complete the instruction-level single-stepping;

[0015] S202, based on the instruction-level single-step operation, according to the correspondence between the line number of the target program source file and the assembly instruction parsed by the GDB simulation program, the GdbServer simulation program sets a temporary breakpoint to the corresponding assembly instruction position to achieve source code-level single-step operation.

[0016] Another aspect of the present invention further provides a device for single-stepping a virtual machine using a Hypervisor, comprising:

[0017] GDB simulator: runs in dom0 of the xen hypervisor virtual machine monitor, interacts with user commands and parses parameters, passes the parsed information to the GdbServer simulator, and runs the domu target program virtual machine;

[0018] GdbServer simulator: runs in the hypervisor layer of the xen hypervisor virtual machine monitor, controls the domu target program virtual machine, and implements breakpoints and single-step running of the target program.

[0019] Furthermore, the GDB simulator includes a parsing module, and the parsing information of the parsing module includes the correspondence between each function of the target program, the line number of the source file and the assembly instruction, and also includes the relative position of each instruction function of the target program in the memory.

[0020] Further, the GdbServer simulator includes a target program breakpoint module, and the target program breakpoint module includes:

[0021] Linked list unit: maintains a breakpoint linked list, which contains the breakpoint addresses and breakpoint conditions parsed by the GDB simulation program from the user command;

[0022] Instruction insertion unit: controls the domu target program virtual machine to pause and inserts the breakpoint instruction according to the breakpoint address in the linked list;

[0023] The operation judgment unit controls the operation of the domu target program virtual machine, jumps to the GdbServer simulator after running to the breakpoint instruction, compares the breakpoint conditions with those in the breakpoint linked list, and judges whether the breakpoint is hit.

[0024] Furthermore, the GdbServer simulator also includes a target program single-step running module, and the target program single-step running module includes:

[0025] Instruction-level single-step operation unit: Use temporary breakpoints to simulate single-stepping. Insert a temporary breakpoint at the next instruction to be executed, and then let the target program continue to run. After the current instruction is executed, the target program will stop when it encounters a temporary breakpoint at the next instruction. When GdbServer determines that the breakpoint is hit, it deletes the breakpoint and completes instruction-level single-stepping.

[0026] Source code level single-step operation unit: Based on instruction level single-step operation, according to the correspondence between the line number of the target program source file and the assembly instruction parsed by the GDB simulation program, the GdbServer simulation program will set temporary breakpoints to the corresponding assembly instruction positions to achieve source code level single-step operation.

[0027] The present invention also provides a computer-readable storage medium, wherein the storage medium stores a computer program, and the computer program is used to execute the above-mentioned method of single-step running a virtual machine using a Hypervisor.

[0028] The present invention also provides a computer program product, including a computer program, wherein when the computer program is executed by a processor, the method for single-stepping a virtual machine using a Hypervisor is implemented.

[0029] Compared with the prior art, the present invention has the following beneficial effects:

[0030] The present invention solves the problem that the software cannot debug non-Linux application layer programs in a single step, and has a relatively wide range of application scenarios, including not only the Linux kernel but also RTOS, baremetal and other programs. Expensive hardware equipment and complex software ecology are not required, which reduces the cost and difficulty of single-step debugging. For developers, it saves a lot of energy and locates problems more quickly. In particular, it provides an effective debugging method for solving some difficult problems. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 It is a schematic diagram of the principle of an embodiment of the present invention. DETAILED DESCRIPTION

[0032] It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments may be combined with each other.

[0033] The overall design concept of the present invention is to use virtualization to put the debugging system into a virtual machine for operation, such as the kernel of a Linux virtual machine, the kernel and application of an RTOS virtual machine, etc. Hypervisor (virtual machine monitor) is a software layer that manages a virtualization environment, which is responsible for creating and managing multiple virtual machines (virtual machines) on physical hardware, and providing isolation and resource allocation between these virtual machines. A virtual machine is a virtualization instance running on a Hypervisor. Each virtual machine is considered to be an independent virtual computer with its own operating system, application program and resources. Hypervisor is responsible for managing the creation, startup, stop and destruction of virtual machines, and providing them with a virtualization interface to access physical hardware. At the same time, it virtualizes and allocates physical hardware resources (such as CPU, memory, storage and network) to virtual machines, and ensures isolation between virtual machines through hardware virtualization technology and software isolation mechanism. Since Hypervisor has all control rights over virtual machines, the present invention uses this feature to use Hypervisor to control the operation of virtual machine programs and generate breakpoints by modifying the target program. After the breakpoint is executed, the program will jump into Hypervisor, where variables, CPU status and stack can be viewed. Use temporary breakpoints to implement single-step running of the program at the instruction level and source code level.

[0034] The present invention will be described in detail below with reference to specific embodiments and accompanying drawings:

[0035] This embodiment is based on the ARM64 architecture, the Hypervisor software is xen, and the debugging target program is the Linux kernel.

[0036] The xen Hypervisor software consists of three parts:

[0037] (1) The hypervisor layer above the hardware layer: It is responsible for directly driving the basic hardware such as CPU and Memory, providing CPU, memory, and interrupt management for all other virtual machines, and also providing HyperCall calls;

[0038] (2) dom0: a privileged virtual machine that has access to the entire virtualization environment and is responsible for creating user-level virtual machines and allocating I / O device resources to them;

[0039] (3) domu: a user-level virtual machine, which is a virtual machine actually provided to users for use and is also a virtual machine for running the target program in the present invention.

[0040] The principle and method of using Hypervisor to run virtual machines in single step in this embodiment are as follows: Figure 1 As shown, specifically including:

[0041] 1. Run the GDB simulator in dom0 and the GdbServer simulator in the hypervisor layer;

[0042] A GDB simulation program, namely the GDB simulator, is run in dom0; the GDB simulator is responsible for user interaction and parameter parsing, and at the same time loads the executable file (ELF) of the target program (Linux kernel) here. The ELF file contains the program header table (ProgramHeaderTable), section header table (SectionHeaderTable), and section (Section). The section (Section) contains information such as executable code, data, symbol table, and string table. Common sections include .text section (code segment), .data section (data segment), .bss section (uninitialized data segment), .rodata section (read-only data segment), etc. The GDB simulator can obtain the correspondence between each function, source file line number, and assembly instruction of the target program based on ELF, and can also calculate the relative position of each instruction function of the target program in memory. When the user enters a breakpoint command, the GDB simulator will finally calculate the relative position of the breakpoint in memory based on the ELF information, and pass the final information to the GdbServer simulator in the hypervisor layer.

[0043] The GDB simulator is a program that interacts with the user, and can be an interface implemented by a QT program. The GDB simulator actually used in this embodiment is written in a shell script, which includes a user interaction program. The user can enter instructions through the program, and the shell parses the instructions and performs corresponding actions. Take loading elf as an example. The user enters "load / home / kernel / vmlinux", and the shell reads the instruction and parses the action load (load file), and then finds the path of the file to be loaded through the parameters. The loading refers to the Linux system opening the corresponding file through the open system call and obtaining the corresponding handle fd, the purpose of which is to map the file to the address space of the GDB simulator process through mmap mapping. In this way, the process can access every data of the file.

[0044] 2. Use the GDB emulator to run a domu virtual machine:

[0045] There are two ways to run the target program virtual machine to be debugged. One is to attach to an already running virtual machine, and the other is to run and debug a new virtual machine.

[0046] (1) For the first type, when a domu has started running, the user enters the start debugging command through the user interaction program of the GDB simulator, which is parsed by the GDB simulator and passed to the GdbServer simulator. The GdbServer simulator itself runs at the hypervisor layer, is responsible for receiving the parameter information of the GDB simulator, and actually controls the operation of the domu at the hypervisor layer.

[0047] The GdbServer simulator first finds the system controller of the virtual machine based on the domu ID. Perform a synchronous pause operation in the system controller. Traverse each VCPU in domu and change the running state of the VCPU to RUNSTATE_offline. Then add the scheduling unit associated with the VCPU to the scheduler's sleep queue, so that the virtual machine will be in a paused state. If the scheduling unit cannot sleep (the VCPU is in a locked state), perform a scheduling switch and then wait for the VCPU to be unlocked.

[0048] When the virtual machine needs to run, the above operation is reversed. The GdbServer simulator traverses each VCPU in the virtual machine, then performs a wake-up operation, changes the running state of the VCPU to RUNSTATE_runnable, and adds the associated scheduling unit to the scheduler's runnable queue. If the scheduling unit cannot be modified, the scheduling switch is executed, and then waits for the VCPU to be unlocked.

[0049] The above-mentioned virtual machine pause and wake-up operations realize the debugging pause and start running functions.

[0050] (2) For the second type, if you want to run a new virtual machine, the pause and wake-up operations are similar. After completing the creation of domu, set the virtual machine's VCPU and scheduling unit to the corresponding state.

[0051] 3. Implementation of target program breakpoints:

[0052] The GdbServer simulator maintains a breakpoint list, which contains the breakpoint address and breakpoint conditions that the GDB simulator parses the user command and passes. When the target program virtual machine is paused, the GdbServer simulator will find the actual location of the breakpoint execution according to the breakpoint address (relative address) in the list plus the starting position of the target program in the memory. Insert the breakpoint instruction to the breakpoint position specified by the user. This breakpoint instruction is usually an hvc synchronous exception instruction, which is used to pause the execution of the program. When the target program virtual machine runs to the breakpoint, it will jump to the GdbServer simulator of the Hypervisor and compare it with the breakpoint conditions in the breakpoint list. If the conditions are met, it is considered that the target program is stopped due to a random signal this time. If not, it is considered that the target program did not hit the breakpoint this time, and the GdbServer simulator will return to the virtual machine to allow it to continue running.

[0053] In addition to ordinary breakpoints, the GdbServer simulator also implements temporary breakpoints. A temporary breakpoint is a breakpoint that is triggered only once during program execution and is usually used to debug a specific code path or event. For a temporary breakpoint, when the breakpoint condition is compared and it is determined to be hit, the GdbServer simulator will delete the breakpoint.

[0054] 4. Implementation of single-step target program:

[0055] Single-step debugging can be divided into instruction-level single-step debugging and source-level single-step debugging.

[0056] The so-called instruction-level single-step debugging means that the GdbServer simulator controls the target program virtual machine to run only one instruction and then stop. The GdbServer simulator uses the temporary breakpoint described in step 3 to simulate the single-step method. That is, a temporary breakpoint is temporarily inserted at the next instruction of the instruction to be executed, and then the target program virtual machine continues to run. After executing the current instruction, it encounters a temporary breakpoint at the next instruction, so the target program virtual machine stops, notifies the GdbServer simulator to hit the breakpoint, and then deletes the breakpoint, thereby completing the instruction-level single-step process.

[0057] The source code level single-step running debugging allows single-step debugging at the source code level to check the execution status of each line of code. The source code level single-step running debugging is based on the above-mentioned instruction level single-step running debugging. Because the source code generates assembly instructions after compilation, generally one line of source code will correspond to multiple lines of assembly instructions. The detailed correspondence is as described above, which is obtained by parsing the ELF file of the target program through the GDB simulator and passed to the GdbServer simulator. The GdbServer simulator sets the temporary breakpoint to the corresponding assembly instruction position, and finally realizes the single-step running debugging of the source code.

[0058] The above-mentioned embodiments are only preferred implementations of the present invention, and are only used to help understand the method and core ideas of the present application. The protection scope of the present invention is not limited to the above-mentioned embodiments. All technical solutions under the idea of ​​the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of the present invention.

Claims

1. A method for single-stepping a virtual machine using a Hypervisor, characterized in that: include: Based on the xen Hypervisor virtual machine monitor, a GDB simulation program is run in dom0, and a GdbServer simulation program is run in the hypervisor layer; the GDB simulation program interacts with user commands and performs parameter parsing, and the parsed information is passed to the GdbServer simulation program, and the domu target program virtual machine is run; the GdbServer simulation program controls the domu target program virtual machine to achieve breakpoints and single-step running of the target program; The target program breakpoint implementation method includes: S101, a breakpoint linked list is maintained in the GdbServer simulation program, and the linked list includes the breakpoint addresses and breakpoint conditions parsed by the GDB simulation program from the user command; S102, GdbServer simulation program controls domu target program virtual machine to pause, and inserts breakpoint instruction according to the breakpoint address in the linked list; S103, the GdbServer simulation program controls the operation of the domu target program virtual machine, and after running to the breakpoint instruction, jumps to the GdbServer simulator, compares the breakpoint conditions with those in the breakpoint linked list, and determines whether the breakpoint is hit; The implementation method of the target program single-step running includes: S201, using temporary breakpoints to simulate single-stepping, inserting a temporary breakpoint at the next instruction of the instruction to be executed, and then allowing the target program to continue running. After the current instruction is executed, the target program encounters a temporary breakpoint at the next instruction, and stops. When GdbServer determines that the breakpoint is hit, the breakpoint is deleted to complete the instruction-level single-stepping; S202, based on the instruction-level single-step operation, according to the correspondence between the line number of the target program source file and the assembly instruction parsed by the GDB simulation program, the GdbServer simulation program sets a temporary breakpoint to the corresponding assembly instruction position to achieve source code-level single-step operation.

2. The method for single-stepping a virtual machine using a Hypervisor according to claim 1, characterized in that: The parsing information transmitted by the GDB simulation program to the GdbServer simulation program includes the correspondence between each function of the target program, the line number of the source file and the assembly instruction, and also includes the relative position of each instruction function of the target program in the memory.

3. A device for single-stepping a virtual machine using a Hypervisor, characterized in that: include: GDB simulator: runs in dom0 of the xen hypervisor virtual machine monitor, interacts with user commands and parses parameters, passes the parsed information to the GdbServer simulator, and runs the domu target program virtual machine; GdbServer simulator: runs in the hypervisor layer of the xen hypervisor virtual machine monitor, controls the domu target program virtual machine, and implements breakpoints and single-step running of the target program; The GdbServer simulator includes a target program breakpoint module, and the target program breakpoint module includes: Linked list unit: maintains a breakpoint linked list, which contains the breakpoint addresses and breakpoint conditions parsed by the GDB simulation program from the user command; Instruction insertion unit: controls the domu target program virtual machine to pause and inserts the breakpoint instruction according to the breakpoint address in the linked list; An operation judgment unit controls the operation of the domu target program virtual machine, jumps to the GdbServer simulator after the breakpoint instruction is run, and compares the breakpoint conditions with those in the breakpoint linked list to determine whether the breakpoint is hit; The GdbServer simulator also includes a target program single-step running module, and the target program single-step running module includes: Instruction-level single-step operation unit: Use temporary breakpoints to simulate single-stepping. Insert a temporary breakpoint at the next instruction to be executed, and then let the target program continue to run. After the current instruction is executed, the target program will stop when it encounters a temporary breakpoint at the next instruction. When GdbServer determines that the breakpoint is hit, it deletes the breakpoint and completes instruction-level single-stepping. Source code level single-step operation unit: Based on instruction level single-step operation, according to the correspondence between the line number of the target program source file and the assembly instruction parsed by the GDB simulation program, the GdbServer simulation program will set temporary breakpoints to the corresponding assembly instruction positions to achieve source code level single-step operation.

4. The device for single-stepping a virtual machine using a Hypervisor according to claim 3, characterized in that: The GDB simulator includes a parsing module, and the parsing information of the parsing module includes the correspondence between each function of the target program, the line number of the source file and the assembly instruction, and also includes the relative position of each instruction function of the target program in the memory.

5. A computer-readable storage medium storing a computer program, characterized in that: The computer program is used to execute the method for single-stepping a virtual machine using a Hypervisor as described in any one of claims 1 to 2.

6. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method for single-stepping a virtual machine using a Hypervisor as described in any one of claims 1 to 2 is implemented.

Images