A method for dynamically monitoring a driver and hardware based on a Feiteng processor

Abstract

The application relates to a method for dynamically monitoring a driver and hardware based on a Feiteng processor, and belongs to the field of monitoring. The application can monitor the state and information of a target driver and hardware without affecting the high-speed running state of the target driver and hardware, in the case of errors generated by a device of an external high-speed bus interface such as a PCIe bus. The application is implemented on a new generation of domestic multi-core processor server platform based on an FT2500 processor. The application mainly utilizes the modular design of a Linux kernel, inserts an additional Linux kernel module in the Linux kernel, cooperates with human interaction to input a virtual address space of a target driver and hardware, and realizes the acquisition of the information of the target driver and hardware in the additional Linux kernel module inserted in the Linux kernel. Compared with the prior art, the application has higher applicability and efficiency.

Description

Technical Field

[0001] This invention belongs to the field of [field name], specifically relating to a method for dynamic monitoring driver and hardware based on Phytium processor. Background Technology

[0002] Currently, methods for debugging drivers or external hardware in the Linux kernel based on Phytium processors mainly include dynamic debugging methods based on the debugfs file system, bpftrace technology based on the Linux kernel kprobes mechanism, static debugging methods based on Linux kernel printk printing, Linux kernel online debugging technology based on kgdb, and Linux exception information dumping technology based on kdump, etc. Figure 1 As shown.

[0003] Dynamic debugging methods based on the debugfs filesystem require developing a debugfs kernel module to perform the necessary debugging functions or obtain the required information for the target driver and hardware. The developed debugfs kernel module creates a debugfs filesystem under the Linux system. Accessing the debugfs kernel module through the debugfs filesystem allows for debugging of the target driver or hardware, or the acquisition of information about the target driver or hardware.

[0004] bpftrace, a debugging technique based on the Linux kernel kprobes mechanism, is a lightweight kernel debugging technique designed by kernel developers to facilitate the tracking of kernel function execution states. Using kprobes, kernel developers can dynamically insert probe points into most specified functions in the kernel to collect the necessary debugging state information with minimal impact on the original kernel execution flow.

[0005] This static debugging method, based on the Linux kernel's printk function, modifies and adds the code logic that needs to be printed to the target driver's source code, thereby enabling the target driver to print the required debugging information during its operation.

[0006] The Linux kernel debugging environment kgdb is built using the Linux kernel debugger (kdb), which provides a method for inspecting Linux kernel memory data structures at runtime. Using kdb to debug target drivers or hardware allows for operations such as setting breakpoints, inspecting variable values, and single-stepping through program execution within the kernel, just like debugging ordinary applications.

[0007] When an error occurs in the Linux kernel, the Linux kernel provides a kdump mechanism, which dumps memory when the Linux kernel crashes. kdump exports an image file named vmcore of the memory currently used by the Linux kernel and saves it to disk. This image can then be used with Linux tools such as crash to analyze the cause of the Linux kernel error.

[0008] Dynamic debugging methods based on the debugfs filesystem require enabling the debugfs kernel configuration option for the Linux kernel source code being used. This option is not configured during normal use because it would affect the overall performance of the Linux operating system. Furthermore, it necessitates modifying the source code of the target driver to add debugfs functionality.

[0009] The bpftrace technology, based on the Linux kernel kprobes mechanism, is not integrated into earlier versions of the Linux kernel. Furthermore, it requires reconfiguration of the Linux kernel source code to enable the bpftrace-related kernel configuration options. Therefore, in some application scenarios, the Linux kernel does not have bpftrace configured.

[0010] Static debugging methods based on Linux kernel printk require modifying the target driver source code to add printk functionality. However, the target driver source code is usually unavailable. Therefore, this method cannot be implemented without the target driver source code.

[0011] Linux kernel online debugging technology based on kgdb requires reconfiguring and compiling the Linux kernel and enabling the kgdb function. Furthermore, this kgdb technology is not effective for errors caused by high-speed data transmission on high-speed external data buses, such as the PCIe bus.

[0012] The kdump-based Linux exception handling technique requires reconfiguring the Linux kernel's kdump functionality. This functionality is not configured during normal Linux kernel use to ensure high operating system performance.

[0013] In summary, the commonly used techniques for debugging and monitoring target drivers and hardware all require reconfiguration based on the Linux kernel source code, modification of the Linux source code, or modification of the target driver source code. Furthermore, these common debugging and monitoring techniques are ineffective against errors triggered during high-speed data transmission on external high-speed buses such as the PCIe bus. Moreover, the Linux kernel itself has a highly complex and technically demanding architecture, and the commonly used methods for debugging and monitoring target drivers and hardware are themselves highly complex and difficult. Therefore, locating and resolving errors in target drivers or hardware is often significantly more challenging. Summary of the Invention

[0014] (a) Technical problems to be solved

[0015] The technical problem to be solved by this invention is how to provide a method for dynamically monitoring drivers and hardware based on Phytium processors, so as to solve the problem of difficulty in locating and solving errors in target drivers or hardware when using methods for debugging drivers or external hardware based on the Linux kernel of Phytium processors.

[0016] (II) Technical Solution

[0017] To address the aforementioned technical problems, this invention proposes a method for dynamic monitoring drivers and hardware based on Phytium processors. This method includes: developing and implementing a dynamic monitoring application at the user layer and implementing a Linux kernel dynamic monitoring module at the kernel layer.

[0018] The dynamic monitoring application includes three modules: a user interaction access module, a sensitive data printing module, and a statistical results printing module.

[0019] The user interaction access module implements the human-computer interaction interface between users and the dynamic monitoring application.

[0020] The sensitive data printing module automatically identifies sensitive data that needs to be monitored during debugging, distinguishing which data is sensitive and which data is not important.

[0021] The statistical results printing module performs statistical analysis, classification, and qualitative analysis on the results of target-driven and hardware monitoring.

[0022] This Linux kernel dynamic monitoring module is used to re-allocate and map virtual addresses based on the physical addresses used by the target driver and hardware. In addition, the Linux kernel dynamic monitoring module also implements timed kernel printing, ioctl encapsulation of active access interfaces, sensitive data monitoring, and time statistics.

[0023] (III) Beneficial Effects

[0024] This invention proposes a method for dynamically monitoring drivers and hardware based on the Phytium processor. Compared with existing techniques for debugging target drivers and hardware, the proposed method dynamically inserts and unloads a Linux kernel dynamic monitoring module into the Linux kernel to achieve dynamic monitoring of target drivers and hardware, without requiring reconfiguration, modification, or recompilation of the Linux kernel or target driver source code. This invention offers greater applicability and efficiency compared to existing techniques for errors occurring during high-speed data transmission on FT2500 server platforms using customized encryption and decryption boards with FPGA-based PCIe interfaces. Attached Figure Description

[0025] Figure 1 This is a schematic diagram illustrating the technical background of driver monitoring and hardware operation based on the Phytium processor.

[0026] Figure 2 This is a schematic diagram of the functional component structure of the present invention;

[0027] Figure 3 This is a schematic diagram illustrating the software operation of the dynamic monitoring driver and hardware of this invention.

[0028] Figure 4 A formatted schematic diagram of the command fixed structure set up in this invention;

[0029] Figure 5 A formatted schematic diagram of the fixed data structure set up for this invention. Detailed Implementation

[0030] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0031] This invention provides a software method for dynamically monitoring and debugging drivers and hardware. For errors generated by devices with external high-speed bus interfaces such as the PCIe bus during high-speed operation, it can monitor the status and information of the target driver and hardware without affecting their high-speed operation. This invention is implemented on a new generation of domestically produced multi-core processor server platform based on the FT2500 processor. It mainly utilizes the modular design of the Linux kernel, inserting additional Linux kernel modules into the Linux kernel. Combined with manual interaction and input of the virtual address space of the target driver and hardware, it enables the acquisition of information about the target driver and hardware from the additional Linux kernel modules inserted into the Linux kernel.

[0032] refer to Figure 2As shown, the overall architecture of this invention is divided into two layers: the user layer and the kernel layer.

[0033] The present invention provides a method for dynamic monitoring driver and hardware based on Phytium processor, comprising: developing and implementing a dynamic monitoring application at the user level and implementing a Linux kernel dynamic monitoring module at the kernel level.

[0034] This dynamic monitoring application consists of three modules: a user interaction access module, a sensitive data printing module, and a statistical results printing module.

[0035] The user interaction access module implements the human-computer interaction interface function between the user and the dynamic monitoring application implemented in this invention.

[0036] The sensitive data printing module implements an automatic identification function for sensitive data that needs to be monitored during debugging, identifying which data is sensitive and which data does not need to be concerned.

[0037] The statistical results printing module enables the statistical analysis, classification, and qualitative analysis of the results from target-driven and hardware monitoring.

[0038] This Linux kernel dynamic monitoring module primarily implements the function of re-allocating and mapping virtual addresses, such as register virtual addresses, command virtual addresses, and data virtual addresses, based on the physical addresses used by the target driver and hardware. In addition, the Linux kernel dynamic monitoring module also implements timed kernel printing functionality, ioctl encapsulation of active access interfaces, sensitive data monitoring functionality, and time statistics functionality.

[0039] refer to Figure 3 The software processing flow of the dynamic monitoring driver and hardware of the present invention is as follows.

[0040] The software processing flow of the user interaction access module includes two parts: the user input of the virtual address space and the acquisition of data from the Linux kernel dynamic monitoring module.

[0041] The steps for a user to enter a virtual address space include:

[0042] Step A1: Read the virtual addresses of the target driver and hardware from the dmesg log to obtain the starting address and size of the virtual address space.

[0043] Step A2: Input the starting address and size of the virtual address space obtained in step A1 through the user interaction access interface.

[0044] Step A3: The software of the user interaction access module inputs the starting address and size of the virtual address space into the Linux kernel dynamic monitoring module through the ioctl interface of the Linux kernel's VFS virtual file system.

[0045] The steps for the user interaction access module to obtain data from the Linux kernel dynamic monitoring module include:

[0046] Step B1: Data from the Linux kernel dynamic monitoring module can be read through the ioctl, open, close, write, and read interfaces provided by the Linux kernel VFS virtual file system. Proceed to step B2.

[0047] Step B2: Mark the data read from the Linux kernel dynamic monitoring module, identify the target drivers and hardware monitored by the Linux kernel dynamic monitoring module, and mark the data. Proceed to Step B3.

[0048] Step B3: Store the marked data in the local file system to realize the data recording function, and proceed to step B4.

[0049] Step B4: Report data to the front-end program or monitoring program of the user interaction access module.

[0050] The software processing flow of the sensitive data printing module includes:

[0051] Step C1: Obtain the data through the data recording completed in step B3; and read the data from the Linux kernel dynamic monitoring module through the ioctl, open, close, write, and read interfaces provided by the Linux kernel VFS virtual file system, and proceed to step C2.

[0052] Step C2: Traverse and query the data obtained in step C1 to check for any sensitive data related to the target driver and hardware. If found, proceed to step C3; otherwise, ignore the step.

[0053] Step C3: Traverse and query the data obtained in step C1 to check if there is any sensitive data required. If so, proceed to step C4; otherwise, ignore it.

[0054] Step C4: Print out the sensitive data.

[0055] The software processing flow of the statistical results printing module includes:

[0056] Step D1: Obtain the data obtained in step C1 and proceed to step D2.

[0057] Step D2: Traverse and count the data categories and module categories in the data, then proceed to D3.

[0058] Step D3: Generate data classification statistics logs and module classification statistics logs, then proceed to step D4.

[0059] Step D4: Read the data classification statistics log and module classification statistics log generated in step D3, and print them.

[0060] The software processing flow of the Linux kernel dynamic monitoring module includes:

[0061] Step E1: Obtain the starting address and size of the virtual address space through step A3, and obtain the target driver and hardware physical address through the Linux kernel function virt_to_phys, then proceed to step E2.

[0062] Step E2: Based on the target driver and the physical address of the hardware obtained in Step E1, re-allocate the virtual address space and map it to the target driver, then proceed to Step E3.

[0063] Step E3: Identify and define the register virtual address space, command virtual address space, and data virtual address space obtained in step E2.

[0064] Step E4: The user interaction access module software, sensitive data printing module software, and statistical result printing module software at the user layer implement the write and read functions for the Linux kernel dynamic monitoring module through the write and read interfaces of the Linux kernel's VFS virtual file system. The write function for the Linux kernel dynamic monitoring module proceeds to step E5, and the read function for the Linux kernel dynamic monitoring module proceeds to step E8.

[0065] Step E5: The Linux kernel dynamic monitoring module calls the dedicated function for setting commands and data in the Linux kernel module. The copy_form_user function is used to obtain the command or data to be set, and the obtained command or data is formatted with a fixed structure.

[0066] like Figure 4The diagram shows the fixed-structure command format set by the Linux kernel dynamic monitoring module through dedicated function calls within the Linux kernel module. The 32-bit region at offset address 0x00 is the target driver and hardware command ID, which is the manually assigned number after numbering all commands in this invention. The 32-bit region at offset address 0x04 is the target driver and hardware command extension area, containing the commands used by the target driver and hardware. The 32-bit regions at offset addresses 0x08 and 0x0C are also target driver and hardware command extension areas, specifically extension area 0 and extension area 1 of the fixed-structure command format of this invention.

[0067] like Figure 5 The Linux kernel dynamic monitoring module shown uses a fixed data format set by dedicated functions within the Linux kernel module. The 32-bit region at offset address 0x00 is the target driver and hardware data ID, which is a manually assigned number after assigning numbers to all communication data types in this invention. The 32-bit regions at offset addresses 0x04 and 0x08 are the lower and higher 32 bits of the virtual address starting address used by the target driver and hardware, storing the starting address of the virtual address used by the target driver and hardware data. The 32-bit region at offset address 0x0C represents the size of the space at the starting address of the virtual address used by the target driver and hardware. The commands and data set in step E5 are the commands and data used for communication between the target driver and hardware and its corresponding user-mode application.

[0068] Enter E6;

[0069] Step E6: The Linux kernel dynamic monitoring module reads the command virtual address and data virtual address that the Linux kernel dynamic monitoring module re-applied for in step E2, compares the read data with the monitoring commands and data set in step E5, and determines whether it is the data that needs to be monitored. If it is, proceed to step E7; otherwise, ignore it. In one embodiment, the Linux kernel dynamic monitoring module sets a kernel timer to realize the timed reading of register virtual addresses and proceeds to step E7.

[0070] Step E7: Print the data from step E6.

[0071] Step E8: Using the register virtual address, command virtual address, and data virtual address obtained in step E3 by the Linux kernel dynamic monitoring module, read the corresponding register information, command information, and data information.

[0072] This invention is primarily based on the modular design of the Linux kernel, enabling dynamic monitoring and debugging of target drivers and hardware without modifying the Linux kernel configuration and source code. Compared to existing techniques for debugging and monitoring target drivers and hardware, the key aspect of this invention lies in dynamically inserting and unloading a Linux kernel dynamic monitoring module. This module uses the virtual addresses used by the target drivers and hardware to calculate the corresponding physical addresses. Then, the Linux kernel dynamic monitoring module uses the physical addresses of the target drivers and hardware to re-allocate and map a virtual address space. Finally, the Linux kernel dynamic monitoring module accesses the registers, control commands, communication data, and other information of the target drivers and hardware through this newly allocated and mapped virtual address space.

[0073] Another key point is that this invention has high effectiveness and applicability in troubleshooting and monitoring devices using external high-speed bus communication. For errors occurring during high-speed transmission in devices using external high-speed bus communication, this invention can monitor the register status, control commands, and communication data of the device in real time without affecting its normal operation. Compared to prior art solutions that require configuring, modifying, or compiling the Linux kernel or affecting the high-speed communication efficiency of the external high-speed bus, the solution proposed in this invention has greater applicability and improves efficiency in locating and resolving anomalies encountered in Linux kernel modules, external device drivers, and external devices.

[0074] Compared with existing techniques for debugging target drivers and hardware, the proposed method of this invention dynamically monitors target drivers and hardware by dynamically inserting and unloading a Linux kernel dynamic monitoring module into the Linux kernel, without requiring reconfiguration, modification, or recompilation of the Linux kernel or target driver source code. This invention offers greater applicability and efficiency compared to existing techniques for errors occurring during high-speed data transmission on FT2500 server platforms using customized encryption and decryption boards with FPGA-based PCIe interfaces. Verification results are shown in Table 1 below.

[0075] Table 1 Comparison of the present invention and the background technology verification.

[0076]

[0077] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for dynamically monitoring drivers and hardware based on Phytium processors, characterized in that, This method includes: developing and implementing a dynamic monitoring application at the user level, and implementing a Linux kernel dynamic monitoring module at the kernel level; The dynamic monitoring application includes three modules: a user interaction access module, a sensitive data printing module, and a statistical results printing module. The user interaction access module implements the human-computer interaction interface between users and the dynamic monitoring application. The sensitive data printing module automatically identifies sensitive data that needs to be monitored during debugging, distinguishing which data is sensitive and which data is not important. The statistical results printing module performs statistical analysis, classification, and qualitative analysis on the results of target-driven and hardware monitoring. This Linux kernel dynamic monitoring module is used to re-allocate and map virtual addresses based on the physical addresses used by the target driver and hardware. In addition, the Linux kernel dynamic monitoring module also implements timed kernel printing, ioctl encapsulation of active access interfaces, sensitive data monitoring, and time statistics. in, The software processing flow of the user interaction access module includes two parts: the user input of the virtual address space and the acquisition of data from the Linux kernel dynamic monitoring module. The steps for a user to enter a virtual address space include: Step A1: Read the virtual addresses of the target driver and hardware based on the dmesg log, and obtain the starting address and size of the virtual address space; Step A2: Input the starting address and size of the virtual address space obtained in step A1 through the user interaction access interface; Step A3: The software of the user interaction access module inputs the starting address and size of the virtual address space into the Linux kernel dynamic monitoring module through the ioctl interface of the Linux kernel's VFS virtual file system. The software processing flow of the Linux kernel dynamic monitoring module includes: Step E1: Obtain the starting address and size of the virtual address space through step A3, and obtain the target driver and hardware physical address through the Linux kernel function virt_to_phys, then proceed to step E2; Step E2: Based on the target driver and the physical address of the hardware obtained in Step E1, re-allocate the virtual address space and map it to the target driver, then proceed to Step E3; Step E3: Identify and define the register virtual address space, command virtual address space, and data virtual address space obtained in step E2; Step E4: The user interaction access module software, sensitive data printing module software, and statistical result printing module software at the user layer implement the write and read functions for the Linux kernel dynamic monitoring module through the write and read interfaces of the Linux kernel's VFS virtual file system. The write function for the Linux kernel dynamic monitoring module proceeds to step E5, and the read function for the Linux kernel dynamic monitoring module proceeds to step E8. Step E5: The Linux kernel dynamic monitoring module calls the dedicated function for setting commands and data in the Linux kernel module, obtains the command or data to be set through the copy_form_user function, and formats the obtained command or data into a fixed structure. In the fixed-structure command format set by the Linux kernel dynamic monitoring module through the dedicated function of the command setting command in the Linux kernel module, the 32-bit area at offset address 0x00 is the target driver and hardware command number ID, which is a number assigned after all commands are numbered; the 32-bit area at offset address 0x04 is the target driver and hardware command area, which contains the commands used by the target driver and hardware; the 32-bit areas at offset addresses 0x08 and 0x0C are the target driver and hardware command extension area, which are extension area 0 and extension area 1 of the command format; The Linux kernel dynamic monitoring module uses a fixed data format set by dedicated functions in the Linux kernel module. The 32-bit region at offset 0x00 is the target driver and hardware data ID, which is assigned after numbering all communication data types. The 32-bit regions at offsets 0x04 and 0x08 are the lower and higher 32 bits of the virtual address space used by the target driver and hardware, storing the starting address of the virtual address used by the target driver and hardware data. The 32-bit region at offset 0x0C indicates the size of the space at the starting address of the virtual address used by the target driver and hardware. The commands and data set in step E5 are the commands and data used for communication between the target driver and hardware and its corresponding user-mode application. Proceed to step E6. Step E6: The Linux kernel dynamic monitoring module reads the command virtual address and data virtual address that the Linux kernel dynamic monitoring module re-allocated in step E2, compares the read data with the monitoring commands and data set in step E5, and determines whether it is the data that needs to be monitored. If it is, proceed to step E7; otherwise, ignore it. Step E7: Print the data from step E6; Step E8: Using the register virtual address, command virtual address, and data virtual address obtained in step E3 by the Linux kernel dynamic monitoring module, read the corresponding register information, command information, and data information.

2. The method for dynamic monitoring drivers and hardware based on Phytium processors as described in claim 1, characterized in that, Virtual addresses include register virtual addresses, command virtual addresses, and data virtual addresses.

3. The method for dynamic monitoring drivers and hardware based on Phytium processors as described in claim 1, characterized in that, The steps to obtain data from the Linux kernel dynamic monitoring module include: Step B1: Read the data from the Linux kernel dynamic monitoring module through the ioctl, open, close, write, and read interfaces provided by the Linux kernel VFS virtual file system, and proceed to step B2; Step B2: Mark the data read from the Linux kernel dynamic monitoring module, identify the target drivers and hardware monitored by the Linux kernel dynamic monitoring module, and mark the data. Proceed to Step B3. Step B3: Store the marked data in the local file system to realize the data recording function, and proceed to step B4; Step B4: Report the data to the front-end program or monitoring program of the user interaction access module.

4. The method for dynamic monitoring drivers and hardware based on Phytium processors as described in claim 3, characterized in that, The software processing flow of the sensitive data printing module includes: Step C1: Obtain the data through the data recording completed in step B3; and read the data from the Linux kernel dynamic monitoring module through the ioctl, open, close, write, and read interfaces provided by the Linux kernel VFS virtual file system, and proceed to step C2; Step C2: Traverse and query the data obtained in step C1 to check if there is any sensitive data related to the target driver and hardware. If so, proceed to step C3; otherwise, ignore it. Step C3: Traverse and query the data obtained in step C1 to check if there is any sensitive data required. If so, proceed to step C4; otherwise, ignore it. Step C4: Print out the sensitive data.

5. The method for dynamic monitoring drivers and hardware based on Phytium processors as described in claim 4, characterized in that, The software processing flow of the statistical results printing module includes: Step D1: Obtain the data obtained in step C1 and proceed to step D2; Step D2: Traverse and count the data categories and module categories in the data, then proceed to D3; Step D3: Generate data classification statistics logs and module classification statistics logs, then proceed to step D4; Step D4: Read the data classification statistics log and module classification statistics log generated in step D3, and print them.

6. The method for dynamic monitoring drivers and hardware based on Phytium processors as described in any one of claims 3-5, characterized in that, In step E6, the Linux kernel dynamic monitoring module sets the kernel timer to read the virtual address of the register at regular intervals, and then proceeds to step E7.

7. The method for dynamic monitoring drivers and hardware based on Phytium processors as described in claim 1, characterized in that, This method is used to debug errors that occur when a custom encryption and decryption board with a PCIe interface based on an FPGA is plugged into the FT2500 server platform during high-speed data transmission.

Images