A testing method, device, equipment, system, medium and product

Abstract

The present invention relates to the field of storage technologies, and in particular, to a testing method, device, equipment, system, medium, and product. The method includes: in the real working environment of a disk array controller chip, obtaining a test management command that characterizes an input / output management command for error injection; parsing the command to obtain an error injection test type and corresponding relevant parameters, and changing the error handling mode according to the error injection test type, so that when an exception is encountered during the test, only reporting is performed without processing, avoiding interference of exception handling with the test process, and ensuring that the test can proceed smoothly according to a preset error injection scenario; constructing a simulated input / output according to the error injection test type and relevant parameters and injecting it into a target hardware unit for execution behavior testing, realizing precise testing of a specific hardware unit under a specific error scenario in an environment where input / output testing is performed based on a read / write input / output test program, making the test more comprehensive and having a higher testing accuracy.

Description

Technical Field

[0001] The present invention relates to the field of storage technologies, and particularly to a test method, device, equipment, system, medium and product. Background Art

[0002] With the evolution of storage technologies, disk array controller chips play an increasingly important role in host storage systems, and their stability and reliability are particularly important. During the research and development process of disk array controller chips, especially in the early stage, how to comprehensively test and verify the hardware of disk array controller chips is a key task for the stability and reliability of the disk array controller chips.

[0003] To ensure the stability and reliability of disk array controller chips, common practices are divided into two steps: First, hardware module-level verification of disk array controller chips. This method is common in the early stage of chip research and development. At this time, there are still problems with each hardware module, and it is difficult to cooperate to perform complete host-issued I / O (Input / Output) processing. At this time, a common test method is to construct a test environment where the hardware unit is unstable or does not exist, inject test data into the unit under test by construction, then trigger the operation of the unit under test, and finally achieve the test purpose by observing whether the behavior of the unit under test meets the expectations. Second, functional-level verification of disk array controller chips. At this time, the hardware modules that make up the disk array controller chip are basically stable, and the entire disk array controller chip already has the ability to carry complete host input and output. At this time, common test methods are as follows: 1) Based on the host it is mounted on, use some tools such as FIO (Flexible I / O Tester) to randomly issue read and write I / O requests to test the reliability of the RAID (Redundant Array of Independent Disks) chip. 2) Further, test and verify the stability of the disk array controller chip by the method of the host issuing read and write I / O requests for a long time. The above test and verification methods respectively verify from the hardware module level and the functional level of the entire chip. The hardware module-level verification focuses on the functional test and exception verification of a single hardware module. For example, the verification of the basic business function of a single hardware module and the verification of its function to handle exceptions, etc. In the verification environment at this time, in addition to this hardware module, other hardware modules and software modules it depends on need to be stubbed or simulated. And the functional-level verification of the entire chip focuses on the verification of the function presented by all hardware modules and the software modules that cooperate with them as a whole of the disk array controller chip. The verification environment at this time is closer to the actual application scenario of the disk array controller chip.

[0004] The above test verification methods belong to common test verification methods, each having its own focus of test verification. That is, either the single hardware module is verified from the perspective of the single hardware module, or the user usage function is verified from the perspective of the overall function of the entire disk array controller chip. However, at the same time, there are also deficiencies in the test verification systems and methods respectively. Both are tested in a simulation environment, with low test efficiency, and only conventional I / O is tested, resulting in insufficient accuracy of performance testing. Summary of the Invention

[0005] An object of embodiments of the present invention is to provide a test method, device, equipment, system, medium, and product, which can solve the above problems.

[0006] In a first aspect, an embodiment of the present invention provides a test method, which is executed by an electronic device having a disk array controller chip. The test method includes: during the process of performing input / output tests based on a read / write input / output test program, obtaining a test management command sent by a host, where the test management command represents an input / output management command for error injection; parsing the test management command to obtain an error injection test type and corresponding relevant parameters, and changing the error handling mode according to the error injection test type. The changed error handling mode is used to indicate that only reporting is performed when an exception is encountered during the test without performing exception handling; constructing a simulated input / output according to the error injection test type and the relevant parameters; injecting the simulated input / output into a target hardware unit to perform an execution behavior test on the target hardware unit, where the target hardware unit is the hardware unit corresponding to the hardware identifier in the relevant parameters.

[0007] In a possible implementation manner, constructing a simulated input / output according to the error injection test type and the relevant parameters includes: if the error injection test type is the first type or the second type, constructing a simulated input / output corresponding to a first task chain according to the task description, task type, and data in the relevant parameters; the first type represents a hardware unit exception type, and the second type represents a hardware unit high-load type; if the error injection test type is the third type, determining a target input / output by using a firmware input / output engine module; and constructing a simulated input / output corresponding to a second task chain according to the target input / output; the third type represents a specific input / output type, and the target input / output is an input / output in the firmware input / output engine module that is greater than the target input / output size in the relevant parameters and has the same input / output type as that in the relevant parameters.

[0008] In a possible implementation, if the error injection test type is the first type or the second type, construct the simulated input and output corresponding to the first task chain according to the task description, task type, and data in the relevant parameters, including: if the error injection test type is the first type, construct the simulated input and output corresponding to the first task chain according to the task description, task type, and data in the relevant parameters; if the error injection test type is the second type, construct the simulated input and output corresponding to the first task chain according to the task description, task type, number of tasks, and data in the relevant parameters.

[0009] In a possible implementation, the first task chain includes task descriptions corresponding to at least one hardware unit.

[0010] In a possible implementation, after determining the target input and output using the firmware input / output engine module, it further includes: pausing the execution operation of the target input and output in the firmware input / output engine module; correspondingly, after injecting the simulated input and output into the target hardware unit to perform an execution behavior test on the target hardware unit, it further includes: after completing the behavior test, resuming the execution operation of the target input and output in the firmware input / output engine module.

[0011] In a possible implementation, construct the simulated input and output corresponding to the second task chain according to the target input and output, including: if the number of the target input and output is multiple, select the input and output corresponding to the target hardware unit from the target input and output, and construct the simulated input and output corresponding to the second task chain.

[0012] In a possible implementation, after parsing the test management command to obtain the error injection test type and the corresponding relevant parameters, it further includes: moving the relevant parameters to the internal space of the chip; correspondingly, constructing the simulated input and output according to the error injection test type and the relevant parameters, including: reading the relevant parameters from the internal space of the chip, and constructing the simulated input and output according to the error injection test type and the relevant parameters.

[0013] In a possible implementation, after moving the relevant parameters to the internal space of the chip, it further includes: if the relevant parameters include a task description and data, check the integrity of the task description and the data; correspondingly, changing the error handling mode according to the error injection test type, including: if both the task description and the data pass the integrity check, change the error handling mode according to the error injection test type.

[0014] In a possible implementation, the test management command is generated by the host encoding the error injection test type and the relevant parameters into the corresponding fields of the extended command format of the Non-Volatile Memory Host Controller Interface Specification protocol; correspondingly, parsing the test management command to obtain the error injection test type and the corresponding relevant parameters includes: parsing the test management command according to the error injection definition table to obtain the error injection test type and the relevant parameters.

[0015] In a possible implementation, the error injection definition table includes an opcode field for representing the error injection test type and fields corresponding to the relevant parameters; among them, the fields corresponding to the relevant parameters include: task description, task type, number of tasks, data, input / output type, input / output size, hardware identifier, expected execution result.

[0016] In a possible implementation, after injecting the simulated input / output into the target hardware unit to perform an execution behavior test on the target hardware unit, it further includes: obtaining the execution result of the target hardware unit; comparing the execution result with the expected execution result in the relevant parameters.

[0017] In a possible implementation, it further includes: obtaining the host input / output for testing issued by the read / write input / output test program of the host; determining the execution unit according to the host input / output; if the execution unit is the firmware input / output engine module, sending the host input / output to the firmware input / output engine module, so that the firmware input / output engine module can split the host input / output and send the split host input / output to the corresponding hardware unit for execution behavior testing; if the execution unit is a hardware unit, sending the host input / output to the corresponding hardware unit for execution behavior testing.

[0018] In a possible implementation, sending the host input / output to the corresponding hardware unit for execution behavior testing includes: splitting the storage operation of the host input / output according to the execution steps; determining the hardware unit corresponding to each task in the task chain obtained by splitting the storage operation; sequentially sending each task in the task chain to the corresponding hardware unit based on the host input / output for execution behavior testing.

[0019] In a possible implementation, it further includes: using the firmware input / output engine module to split the host input / output transferred by the hardware unit and sending the split host input / output to the corresponding hardware unit for execution behavior testing.

[0020] In a second aspect, a test device is provided, including: a task distribution module, configured to obtain a test management command sent by a host during the process of performing input / output tests based on a read / write input / output test program, where the test management command represents an input / output management command for error injection; an injection management module, configured to parse the test management command to obtain an error injection test type and corresponding related parameters, and change an error handling mode according to the error injection test type, and the changed error handling mode is used to indicate that only reporting is performed and no exception handling is performed when an exception is encountered during the test; an input / output simulation function module, configured to construct simulated input / output according to the error injection test type and the related parameters; and inject the simulated input / output into a target hardware unit to perform an execution behavior test on the target hardware unit, where the target hardware unit is the hardware unit corresponding to the hardware identifier in the related parameters.

[0021] In a third aspect, an electronic device is provided, including: a memory, configured to store a computer program; and a processor, configured to execute the computer program to implement operations corresponding to the test method shown in any possible implementation manner of the first aspect.

[0022] In a fourth aspect, a test system is provided, including: the electronic device described in the third aspect; and a host, configured to send a test management command to the electronic device and obtain a test result.

[0023] In a possible implementation manner, the host is further configured to: obtain a test result set of each hardware unit, where the test result set includes result subsets corresponding to multiple error injection test types respectively; draw a change curve for each error injection test type according to the test time of each test result in the result subset; determine a performance score for each error injection test type according to the corresponding change curve; and determine the performance of each hardware unit according to the performance scores corresponding to multiple error injection test types respectively.

[0024] In a fifth aspect, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, it implements operations corresponding to the test method shown in any possible implementation manner of the first aspect.

[0025] In a sixth aspect, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, it implements operations corresponding to the test method shown in any possible implementation manner of the first aspect.

[0026] In summary, the test method provided by the present invention includes at least one of the following beneficial technical effects: in the real working environment of the disk array controller chip, obtaining a test management command that represents an input / output management command for error injection; parsing the command to obtain the error injection test type and corresponding relevant parameters, and changing the error handling mode according to the error injection test type, so that when an exception is encountered during the test, only reporting is performed without processing, avoiding the interference of exception handling on the test process, and ensuring that the test can proceed smoothly according to the preset error injection scenario; constructing a simulated input / output according to the error injection test type and relevant parameters and injecting it into the target hardware unit for execution behavior testing, realizing accurate testing of a specific hardware unit under a specific error scenario in an environment where input / output testing is performed based on a read / write input / output test program, making the test more comprehensive and having higher test accuracy.

[0027] Furthermore, the disk array controller chip test device, equipment, system, medium, and product of the present invention all have the above technical effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the embodiments of the present invention, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention, and those of ordinary skill in the art can obtain other drawings based on these drawings without creative efforts.

[0029] Figure 1 FIG. 1 is a schematic structural diagram of a verification test system based on error injection of a disk array controller chip provided by an embodiment of the present invention.

[0030] Figure 2 FIG. 2 is a schematic process diagram of IO execution in the related art.

[0031] Figure 3 FIG. 3 is a schematic process diagram of a verification test based on error injection of a disk array controller chip provided by an embodiment of the present invention.

[0032] Figure 4 FIG. 4 is a schematic diagram of a general form of a TDC provided by an embodiment of the present invention.

[0033] Figure 5 FIG. 5 is a schematic diagram of a test method provided by an embodiment of the present invention.

[0034] Figure 6 FIG. 6 is a schematic diagram of an IO simulation for simulating a hardware exception provided by an embodiment of the present invention.

[0035] Figure 7 FIG. 7 is a schematic diagram of a TDC corresponding to a TD1 hardware unit with an additional simulated input / output provided by an embodiment of the present invention.

[0036] Figure 8 It is a schematic flowchart of an IO simulation provided by an embodiment of the present invention.

[0037] Figure 9 It is a schematic diagram of the process of parsing by an injection management module provided by an embodiment of the present invention.

[0038] Figure 10 It is a schematic diagram of a global work process provided by an embodiment of the present invention.

[0039] Figure 11 It is a schematic structural diagram of a device provided by an embodiment of the present invention.

[0040] Figure 12 It is a schematic structural diagram of an electronic device provided by an embodiment of the present invention. Detailed implementation manners

[0041] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present invention.

[0042] The terms "including" and "having" in the specification of the present invention and the accompanying drawings above, and any variations related to "including" and "having", are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but may include steps or units not listed.

[0043] In order to enable those skilled in the art of the present technology to better understand the solution of the present invention, the present invention will be further described in detail below in conjunction with the accompanying drawings and specific implementation manners.

[0044] In the related art, during functional-level verification, the test work is carried out from the perspective of users using the function. At this time, in order to ensure the consistency between the test verification and the user's use, commonly used hosts and test tools in the industry are used for test verification. Therefore, the IO issued by it is generally standard and belongs to the IO in the normal scenario of users. The entire test system is closed and difficult to customize. This test method also has the following problems:

[0045] It is difficult to trigger abnormal conditions of the chip hardware. At this time, after the test verification is completed, it is difficult to determine whether the abnormal reporting and its processing logic of the hardware module in the formal environment meet the expectations of the overall architecture design; it is difficult to put all or part of the engines of the chip hardware under a high workload to test and verify their behaviors. Especially in the simulation environment, the overall simulation environment runs slowly, and most hardware modules are in a low-load state for a long time during the entire test process. After the test is completed, it is impossible to determine whether the actual performance of the hardware module in the formal environment and under high-load conditions meets the architecture design expectations. It is difficult to test the performance of the chip under special host input and output conditions, such as the performance when the memory address is not 4K-aligned.

[0046] When performing hardware module-level verification, a lot of piling and simulation are required to make the test work properly. This test method is quite different from the actual situation. Similar to the front-end simulation verification of the chip, it is difficult to directly test and verify whether the overall performance of each hardware module in the real user usage environment meets the expectations of the architecture design.

[0047] It can be understood that the disk array controller chip belongs to a hardware acceleration chip, which generally uses multiple acceleration engines to parallel process host input and output to achieve the acceleration of IO processing. Specifically for a specific IO, its processing generally includes: locking, resource allocation, RAID operation, data transfer, resource release, and unlocking and other processing links, and each link is one or more acceleration engines (or acceleration units / hardware units).

[0048] In view of the above deficiencies in the test system and method, combined with the characteristics of the disk array controller chip, the present invention proposes a disk array controller chip error injection system and method. The invention realizes a customizable and developed functional-level test verification system by autonomously injecting simulated input and output inside the disk array controller chip.

[0049] Specifically, refer to Figure 1 , Figure 1 which is a schematic structural diagram of a verification test system based on disk array controller chip error injection provided by an embodiment of the present invention. Among them, it includes a host and an electronic device with a disk array controller chip. Figure 1 The solid lines in represent the interaction of the control plane, and the dotted lines represent the interaction of IO data. The functional modules involved in the present invention are described as follows:

[0050] The management command module and the read / write input / output test program are functional modules on the host. The command method module, injection management, input / output simulation function, firmware input / output engine module, and input / output distribution module are internal software functional modules of the disk array controller chip, and the hardware unit is the internal hardware acceleration engine module of the disk array controller chip. Among these modules, the injection management module and the input / output simulation function module are newly added modules of the present invention and constitute the main components of the system of the present invention. Other software modules are either existing functional modules or have their functions customized and extended for the needs of the present invention.

[0051] Among them, the management command module is used to issue management commands for the control plane of the disk array controller chip on the host. The management commands include service management commands such as RAID creation and deletion. For the present invention, this module adds support for test management commands such as injection start and injection stop.

[0052] The command distribution module docks with the management command module on the host and distributes the commands of the control plane issued by the host to the corresponding modules for processing according to the type of the commands. For example, the RAID service-related management commands will be distributed to the RAID service management module. Here, the test management commands are distributed to the injection management module, which simulates the injection of input / output according to the parameters of the test management commands, including the creation and management of specific simulated input / output.

[0053] The injection management module is responsible for parsing the test management commands, parsing out the test types and their related parameters in the test management commands, and handing them over to the input / output simulation function module. At the same time, it is necessary to configure and change the error handling mode of the disk array controller chip according to the test type. For example, when performing a hardware engine exception test, when an exception is encountered, only a report will be made without performing real exception handling. Because real exception handling may perform unexpected behaviors such as restarting the disk array controller chip.

[0054] The input / output simulation function module is responsible for simulating the test input / output. By injecting the simulated input / output into the hardware unit, it triggers exceptions in the hardware function module (hardware unit), increases its load, or allows the hardware unit to execute the constructed specific simulated host input / output. When the RAID card is under normal test, it thus completes the verification in the real environment that the exception function of the hardware unit and its processing flow meet the expectations; verifies whether the operation performance of the hardware unit under high load meets the expectations; verifies the performance of the hardware unit when executing specific IOs.

[0055] The read / write input / output test program generally refers to test programs such as FIO.

[0056] Input / Output distribution module, which interfaces with input / output test programs such as FIO on the host and is responsible for processing all IOs sent from the host. Generally, this module is implemented in hardware (it can also be implemented in software). Regardless of which implementation method is used, there are cases where IOs need to be handed over to the firmware input / output engine module for processing.

[0057] Firmware input / output engine module, which is a pure software module. Its function is to split, reorganize, etc. the host input / output sent by the IO distribution module or the IOs transferred by the hardware unit, and finally complete it through software or by handing it over to the hardware unit again.

[0058] See Figure 2 , in the related technology, the host input / output is executed according to the Figure 2 process. Steps ① to ② are the execution of management commands in the control plane, which are used to create and configure the RAID and will not be elaborated here.

[0059] Step ③, the issuance of host input / output; Step ④, the input / output distribution module distributes or splits the host input / output according to the characteristics of the host input / output or the configuration of the disk array controller chip. The host input / output with direct hardware acceleration execution (complete or partial, the same below) is routed to the hardware unit for processing; Step ⑤, the host input / output that needs to be executed by the firmware input / output engine module (complete or partial, the same below) is routed to the firmware input / output engine module for processing; Step ⑥, for the host input / output processed by the firmware input / output engine module, if it still meets the conditions for hardware acceleration, it continues to be routed to the hardware unit for processing; Step ⑦, during the hardware processing of the host input / output routed to the hardware unit in Step ④ before, difficulties are encountered (the hardware, due to the simplicity of the design, only processes simple IOs and cannot process complex IOs), then it is routed to the firmware input / output engine module for processing again.

[0060] However, a verification test system and method based on error injection of a disk array controller chip proposed by the present invention has the principle as Figure 3 shown, and adds steps four steps.

[0061] Step ⑧, the command distribution module needs to route the management commands for error injection to the injection management module.

[0062] In step ⑨, after the injection management module completes the global configuration of relevant error injection (the configuration content refers to the handling after an exception occurs. For example, when performing a hardware engine exception test, when an exception is encountered, it will be reported instead of performing real exception handling), it passes the error injection test type and its parameters to the input / output simulation function module. The input / output simulation function module creates simulated input / outputs alone or in cooperation with the firmware input / output engine module, and finally sends them to the hardware unit.

[0063] In step ⑩, when the input / output simulation function module needs to simulate by means of host input / output, it configures the firmware input / output engine module to obtain a real host input / output information, and creates (simulates) a simulated input / output based on this host input / output information and sends it to the hardware unit. Inside the firmware input / output engine module, the execution of this host input / output information is paused. After the simulated input / output is completed, the input / output simulation function module notifies the firmware input / output engine module to continue completing the previously paused host input / output information, and returns the execution result of this host input / output information to the host after the execution is completed.

[0064] Step , the IO simulated by the input / output simulation function module is directly sent to the hardware unit for execution.

[0065] It can be understood that the main function of the hardware unit inside the disk array controller chip is to accelerate the storage (read / write) operation of host input / output information based on the RAID algorithm. To achieve the goal of acceleration, the storage operation of host input / output information needs to be split into steps according to its requirements, and the split steps are handed over to the corresponding hardware modules for execution respectively, so as to achieve the effect of parallel acceleration. The storage based on the RAID algorithm is generally split into multiple steps, corresponding to different hardware engines respectively. For example, a lock management engine, a resource management engine, a hanging disk engine, a RAID calculation engine, etc. It can be seen that inside the disk array controller chip, the execution of a piece of host input / output information involves multiple task descriptions that drive different hardware engines to execute. These different task descriptions (TD: Task Description) corresponding to the same piece of host input / output information together form a task chain (TDC: Task Description Chain). When this task chain is executed, the host input / output information is normally completed. It should be noted that the hardware engine only perceives the TD it receives and hardly perceives the TDC. See Figure 4 , Figure 4 is a schematic diagram of a general form of a TDC provided by an embodiment of the present invention. As Figure 4 shown, in the schematic diagram of the TDC, it includes the sequential execution of n TDs. It should be noted that Figure 4For illustration purposes only, it is not the specific design of the TDC inside the actual disk array controller chip, and no further explanation will be given here.

[0066] See Figure 5 , Figure 5 is a schematic diagram of a test method provided by an embodiment of the present invention, which is executed by an electronic device having a disk array controller chip. The test method includes:

[0067] S101. During the input / output test based on the read / write input / output test program, obtain the test management command sent by the host, where the test management command represents an input / output management command for error injection.

[0068] In the embodiment of the present invention, the read / write input / output test program can be a test program such as FIO for performing input / output tests. That is, during the normal test of the RAID card, obtain the test management command sent by the host in a real environment.

[0069] The input / output management command for error injection is a command used to simulate or trigger specific error scenarios during the input / output test, and can actively introduce error IOs in a real environment to detect the reaction of the hardware unit when facing errors.

[0070] The host, through the management command module, distributes the test management command to the task distribution module of the storage device. Further, the test management command can also be verified to ensure whether the format and content of the test management command conform.

[0071] S102. Analyze the test management command to obtain the error injection test type and the corresponding relevant parameters, and change the error handling mode according to the error injection test type. The changed error handling mode is used to indicate that only reporting is performed when an exception is encountered during the test without performing exception handling.

[0072] In the embodiment of the present invention, the error injection test types include: the first type, the second type, and the third type. Among them, the first type represents the hardware unit exception type, the second type represents the hardware unit high-load type, and the third type represents the specific input / output type. Of course, other types can also be included, which are not limited in the embodiment of the present invention, and users can set according to actual needs. Correspondingly, the relevant parameters corresponding to the first type can include: task description, task type, and data; the relevant parameters corresponding to the second type can include: task description, task type, task times, and data; the relevant parameters corresponding to the third type can include: input / output size, input / output type. The error handling mode refers to the handling strategy adopted when an abnormal situation is encountered, and specifically defines the response method as: only reporting is performed when an exception is encountered without performing exception handling.

[0073] Specifically, when a test management command is received, the injection management module is used to parse the command byte by byte in a predefined format, and identify the error injection test type and related parameters through specific fields; and according to the parsed error injection test type, configure the corresponding error handling mode configuration in the configuration file to complete the change of the error handling mode.

[0074] S103. According to the error injection test type and related parameters, construct simulated input and output; inject the simulated input and output into the target hardware unit to perform an execution behavior test on the target hardware unit, where the target hardware unit is the hardware unit corresponding to the hardware identifier in the related parameters.

[0075] In an embodiment of the present invention, the simulated input and output are constructed by the input / output simulation function module according to the error injection test type and related parameters; the simulated input and output are injected into the target hardware unit to perform an execution behavior test on the target hardware unit.

[0076] Among them, the input / output simulation function is the simulation of TDC. Generally, the exception of a hardware unit is that it encounters a situation that does not conform to the design expectation when parsing TD and the data pointed to by the pointer in TD. When a hardware unit encounters an exception, there are interrupts, event reports, freezes, etc. Exemplarily, the hardware unit may trigger an interrupt to notify the firmware input / output engine module to perform exception handling, or may trigger an event to notify the firmware input / output engine module to perform exception correction.

[0077] The simulated input and output are specifically a task chain, and the task chain includes the sequential execution of n task descriptions. Each task description corresponds to corresponding data, and each task description corresponds to a hardware unit that executes the task description.

[0078] After constructing the simulated input and output, the simulated input and output can be injected into the target hardware unit to perform an execution behavior test on the target hardware unit, and then the execution behavior can be obtained, so as to determine whether the execution behavior meets the expectation. Specifically, the function of the test function index of the host input / output is not affected; the influence on the test performance index meets the expectation; the performance monitoring data of the tested hardware unit meets the expectation; the exception report of the tested hardware module meets the expectation; the customized IO is completed as expected.

[0079] It can be seen that in the embodiment of the present invention, in the actual working environment of the disk array controller chip, a test management command for characterizing the input / output management command of error injection is obtained, and then an injection management mechanism and an input / output simulation mechanism are added. Specifically, the command is parsed to obtain the error injection test type and corresponding relevant parameters, and the error handling mode is changed according to the error injection test type, so that only reporting but not processing is performed when an exception is encountered during the test, avoiding the interference of exception handling on the test process and ensuring that the test can proceed smoothly according to the preset error injection scenario; a simulated input / output is constructed according to the error injection test type and relevant parameters and injected into the target hardware unit for execution behavior testing, realizing accurate testing of a specific hardware unit in a specific error scenario in an environment where input / output testing is performed based on a read / write input / output test program, making the test more comprehensive and the test accuracy higher.

[0080] A possible implementation manner of the embodiment of the present invention, S103 constructs a simulated input / output according to the error injection test type and relevant parameters, including: if the error injection test type is the first type or the second type, a simulated input / output corresponding to the first task chain is constructed according to the task description, task type, and data in the relevant parameters; the first type represents the hardware unit exception type, and the second type represents the hardware unit high-load type; if the error injection test type is the third type, the firmware input / output engine module is used to determine the target input / output; and a simulated input / output corresponding to the second task chain is constructed according to the target input / output; the third type represents a specific input / output type, and the target input / output is an input / output in the firmware input / output engine module that is greater than the target input / output size in the relevant parameters and has the same input / output type as that in the relevant parameters.

[0081] In the embodiment of the present invention, the first type is to simulate the exception of the hardware unit. If the error injection test type is the first type, a simulated input / output corresponding to the first task chain is constructed according to the task description, task type, and data in the relevant parameters. The first task chain includes task descriptions corresponding to at least one hardware unit, so that when constructing the simulated input / output, tasks can be set and simulated for multiple hardware units, thereby comprehensively testing the collaboration ability between multiple hardware units and their performance in a specific error scenario, and being able to more comprehensively and realistically test the situation where multiple hardware units simultaneously face error injection in the actual operating environment, making the test more comprehensive and reliable.

[0082] The exception of the hardware unit generally occurs when it encounters a situation that does not conform to the design expectation when parsing the task description and the data pointed to by the pointer in the task description. It may trigger an interrupt to notify the firmware input / output engine module to perform exception handling, or it may trigger an event to notify the firmware input / output engine module to perform exception correction.

[0083] Refer to the first task chain for the first type of analog input / output Figure 6 , Figure 6 Figure 0000198 is a schematic diagram of IO simulation for simulating hardware exceptions provided by an embodiment of the present invention. In this task chain TDC, the IO simulation function uses the hardware unit identifier, task description 1 (TD1), and data (Data) passed by the injection management module. Of course, TD1 and Data can also be independently created by the IO simulation module, and TDC is created and sent to the hardware unit through the software and hardware interface. After receiving the TDC, since TD1 and Data are test data, when the hardware unit parses and executes TD1 and its Data, it can trigger exception handling / exception correction, that is, report exceptions as needed. If the reported exception meets the expectations, it means that in the real working environment, the exception handling test of this hardware unit passes. It can be understood that Figure 6 is just an example. For different test purposes and the specific situation of the engine, the composition of TDC can be extended as needed. It can also sequentially include task description 1 and task description 2, corresponding to data 1 and data 2 respectively. Task description 1 points to hardware unit 1, and task description 2 points to hardware unit 2. After receiving the TDC, hardware unit 1 can parse and execute TD1 and data 1, triggering an exception. After receiving the TDC, hardware unit 2 can parse and execute TD2 and data 2, triggering an exception. This embodiment of the present invention will not elaborate further

[0084] For the second type, the load of the analog hardware unit is increased. If the error injection test type is the second type, the analog input / output corresponding to the first task chain is constructed according to the task description, task type, task times, and data in the relevant parameters

[0085] In a normal test verification environment, if you want to increase the load of a certain or certain hardware units, you can simulate the TDC corresponding to the hardware unit and hand it over to the hardware unit for execution to achieve the test purpose. At this time, in addition to handling the task description of the normal read / write input / output test program, the hardware unit also needs to handle the injected task description at the same time, thereby achieving the test purpose of whether the behavior of the hardware unit under increased load meets the expectations

[0086] As Figure 7 shown Figure 7 Figure 0000207 is a schematic diagram of TDC corresponding to the hardware unit of TD1 that conforms to the increased analog input / output. For different test purposes and the specific situation of the hardware unit, the composition of TDC can be extended as needed, and will not be elaborated further

[0087] For the third type, to simulate the specific IO processing of the analog hardware unit and simulate the processing of specific IO, the following steps are included: The injection management module transfers the size and type of the analog input / output to the input / output simulation function module; the input / output simulation function module sends the size and type of the analog input / output to the firmware input / output engine module to configure the required input / output size and type; when the firmware input / output engine module checks that there are conditions satisfied (the size of the host input / output information ≥ the configured input / output size and the same input / output type), during the search, all hardware IOs go through the hardware path and cannot be checked by software. At this time, through the firmware input / output engine module for searching, if not found at the current moment, wait. Since the number of host input / output information is large, host input / output information that meets the conditions can be obtained.

[0088] Furthermore, after determining the target input / output using the firmware input / output engine module, it further includes: pausing the execution operation of the target input / output in the firmware input / output engine module. Pause the processing of this host input / output information and transfer the host input / output information to the input / output simulation function module (this host input / output information is called the original host input / output information); based on the host input / output information transferred by the firmware input / output engine module, the input / output simulation function module creates an IO (i.e., analog input / output), that is, creates a TDC, which describes this analog input / output; the input / output simulation function module sends the analog input / output to the hardware unit for execution.

[0089] After injecting the analog input / output into the target hardware unit to perform the execution behavior test, it further includes: after completing the behavior test, resuming the execution operation of the target input / output in the firmware input / output engine module. Specifically, when all the TDCs of the analog input / output are executed, the input / output simulation function module notifies the firmware input / output engine module to resume the execution of the original host input / output. It can be understood that the analog input / output is equivalent to the IO for test purposes injected into the normal IO process. After its execution, if the functions and performance of the normal IO process are not affected or the impact is within the expected range, it means it meets the expectations. Thus, in the embodiments of the present invention, pausing the execution operation can ensure that during the process of injecting the analog input / output into the target hardware unit for testing, the firmware input / output engine module will not interfere with the test process of IO injection, enabling the test to focus on the impact of the analog input / output on the target hardware unit; resuming the execution operation after completing the test ensures that the firmware input / output engine module can normally perform the input / output test based on the tasks issued by the current read / write input / output test program, ensuring the stability and accuracy of the test environment and making the test results of the disk array controller chip more reliable.

[0090] Further, according to the target input / output, construct the simulated input / output corresponding to the second task chain, including: if the number of target input / outputs is multiple, select the input / output corresponding to the target hardware unit from the target input / outputs to construct the simulated input / output corresponding to the second task chain. Specifically, if the number of qualified I / Os is multiple, preferentially select the I / O corresponding to the target hardware unit from the target input / outputs. If the number of such I / Os is multiple, select the I / O with the size closest to the input / output size as the simulated input / output corresponding to the constructed second task chain. It can be understood that the target input / output can be the host input / output, the I / O returned by the hardware unit, or the split I / O, which can be the entire I / O or a part of the I / O. The embodiments of the present invention do not limit this. Through the above method, the optimal target input / output that meets the requirements can be found. In the embodiments of the present invention, when the number of target input / outputs is multiple, select the input / output corresponding to the target hardware unit from the target input / outputs to construct the simulated input / output corresponding to the second task chain, which improves the matching degree between the simulated input / output and the target hardware unit, thereby ensuring the pertinence and effectiveness of the test.

[0091] In summary, as can be seen from the above, the implementation of the I / O simulation provided by the present invention, as Figure 8 shown, Figure 8 is a schematic flowchart of an I / O simulation provided by an embodiment of the present invention, including: the input / output simulation function module determines the type of error injection test to be injected according to the Op-Code field of the error injection command. If it is the first type (hardware unit exception) or the second type (injection type of pressure), directly construct the task chain TDC through the task description TD sent by the host. If it is the third type (I / O simulation exception), the firmware input / output engine module can be notified, and it sends the information of the host input / output that meets the conditions (or the I / O transferred by the hardware unit) to the input / output simulation function module; after receiving the I / O information, the I / O simulation function module can build a new TDC based on it and send it to the hardware unit for execution; or obtain data according to the data PRP1 / PRP2 information in the NVMe extended command, construct a TDC, and send it to the hardware unit for execution; or apply for the Data space inside the disk array controller chip, construct a TDC, and send it to the hardware unit for execution. It can be seen that through the above technical solutions, an open verification test environment can be realized, which can well solve the problem that module-level verification of hardware cannot be performed in a real environment.

[0092] It can be seen that in the embodiments of the present invention, for the first type (hardware unit anomaly type) and the second type (hardware unit high load type), the simulated input and output corresponding to the first task chain are constructed based on the task description, task type, and data in the relevant parameters (the second type also includes the number of tasks); for the third type (specific input and output type), after determining the target input and output by using the firmware input and output engine module, the simulated input and output corresponding to the second task chain are constructed. The method of flexibly constructing the simulated input and output according to different error injection test types can more accurately simulate various specific test scenarios, making the test of the disk array controller chip more comprehensive, helping to discover potential problems of the chip in different complex scenarios, and thus improving the reliability of the test.

[0093] A possible implementation manner of the embodiments of the present invention is shown in Figure 9 , Figure 9 FIG. is a schematic diagram of the parsing process of an injection management module provided by the embodiments of the present invention, including: The injection management module first parses the test management command, that is, the NVMe extended command, and moves the task description to the internal space of the chip through the interaction interface between the disk array controller chip and the host. Subsequently, the data pointed to by Data, that is, PRP1 / PRP2, can also be moved to the internal space of the chip to create conditions for the input / output simulation function module to construct the TDC. Further, the integrity of TD and Data can be checked, and the TDC completion and exception handling flags can be set and handed over to the input / output simulation function module. The TDC is executed in the hardware unit, and after its execution, there are two results: one is to report an exception, and the other is the normal end of the TDC. Therefore, it needs to be configured so that the exception handling program for reporting an exception and the cleanup function at the end of the TDC can trigger the end of the error injection test and output the test result.

[0094] Specifically, after parsing the test management command to obtain the error injection test type and the corresponding relevant parameters, it further includes: moving the relevant parameters to the internal space of the chip; correspondingly, according to the error injection test type and the relevant parameters, constructing the simulated input and output, including: reading the relevant parameters from the internal space of the chip, and constructing the simulated input and output according to the error injection test type and the relevant parameters. In the embodiments of the present invention, moving the relevant parameters to the internal space of the chip can reduce the time delay of obtaining parameters from the outside. Subsequently, reading the relevant parameters from the internal space of the chip to construct the simulated input and output can improve the speed and efficiency of data reading. The internal space of the chip is relatively more stable than the external environment, which can reduce the influence of external interference on the parameters and ensure the accuracy and integrity of the parameters.

[0095] Specifically, after moving the relevant parameters to the internal space of the chip, it further includes: if the relevant parameters include a task description and data, check the integrity of the task description and data; correspondingly, change the error handling mode according to the error injection test type, including: if both the task description and data pass the integrity check, change the error handling mode according to the error injection test type. In the embodiments of the present invention, integrity means that information such as task descriptions and data has all elements in terms of content, structure, and format. Specifically, technologies such as MD5 can be used to verify integrity to ensure the validity of the information.

[0096] In the embodiments of the present invention, only when both the task description and data pass the integrity check, the error handling mode is changed and the simulated input and output are performed according to the error injection test type, which can ensure that the parameters on which the subsequent construction of the simulated input and output and the change of the error handling mode are based are accurate and complete, avoiding deviations or errors in the test process due to incorrect or incomplete parameters. By strictly controlling the integrity of the parameters, the reliability of the entire verification test can be improved.

[0097] A possible implementation manner of the embodiments of the present invention is that the test management command is generated by the host encoding the error injection test type and relevant parameters into the corresponding fields of the extended command format of the non-volatile memory host controller interface specification protocol; correspondingly, parsing the test management command to obtain the error injection test type and the corresponding relevant parameters, including: parsing the test management command according to the error injection definition table to obtain the error injection test type and relevant parameters.

[0098] It can be seen that in the embodiments of the present invention, the host encodes the error injection test type and relevant parameters into the corresponding fields of the extended command format of the non-volatile memory host controller interface specification protocol to generate a test management command, and parses the command according to the error injection definition table to obtain the error injection test type and relevant parameters.

[0099] The error injection definition table includes an opcode field for representing the error injection test type and fields corresponding to the relevant parameters; among them, the fields corresponding to the relevant parameters include: task description, task type, number of task executions, data, input / output type, input / output size, hardware identifier, and expected execution result.

[0100] Specifically, in the embodiments of the present invention, the definition of the test management command for error injection is carried out.

[0101] In a disk array controller chip, the Non-Volatile Memory Host Controller Interface Specification (NVMe) protocol is generally used to interact with the host, and its test management commands are implemented based on the extended commands in the NVMe protocol. Similarly, the commands for error injection defined in the present invention are also implemented based on a set of extended commands defined in the NVMe protocol. The definition of the extended commands, i.e., the error injection definition table, is shown in Table 1.

[0102] Table 1: Error Injection SQE Definition Table

[0103]

[0104] Among them, the Op-Code field is the operation code field indicating the error injection test type, used to explain the operation code of the SQE command. Here, it is extended as shown in Table 2 according to the NVMe specification.

[0105] Table 2: Definition Table of Op-Code Field

[0106]

[0107] For the / / / field in the table, it is a field already defined in NVMe and will not be elaborated here.

[0108] For the data fields, specifically, PRP1 and PRP2 are used according to the NVMe protocol. That is, when injection requires data, PRP1 and PRP2 are used to describe it.

[0109] For the injType field, it describes the injection type and can be used for further subdivision of the test type. Specifically, the engineID field is the hardware identifier, specifically the ID of the injection target hardware unit; the testTimes field is the number of tasks corresponding to this SQE command; the testResult is the expected test result, i.e., the expected execution result.

[0110] For the injTD_Addr_L / H fields, they record the pointer to the description of the TD of the injection hardware, i.e., the task description. When constructing the injection TD on the host, the address of the TD is configured into this field.

[0111] For the monitorIOInfo1 / monitorIOInfo2 field, this field records the IO information and Data configuration information of the IO to be simulated. The IO information includes RAID-based IO information. For example: SLBA, NLBA, etc.; the Data configuration information configures the source of the Data during the simulated input and output, which can use the PRP1 / PRP2 that comes with the extended command, or obtain the Data pointer from the firmware input and output engine module, or obtain the Data pointer through internal allocation.

[0112] A possible implementation method of an embodiment of the present invention, after injecting simulated input and output into the target hardware unit to perform execution behavior test on the target hardware unit, also includes: obtaining the execution result of the target hardware unit; and comparing the execution result with the expected execution result in the relevant parameters.

[0113] Specifically, the execution result can be compared with the expected execution result to determine whether the execution is completed, and the test result can be printed out.

[0114] In some feasible situations, if for the hardware unit abnormality type, it is determined whether the abnormality report of the tested hardware unit is in line with expectations; for the hardware unit high load type, it is determined whether the impact on the performance indicators of the tested hardware unit is in line with expectations; for the specific input and output types, it is determined whether the IO is completed as expected; of course, it is also possible to determine whether the functions of the test function indicators of the host input and output are affected; the performance monitoring data of the tested hardware unit is in line with expectations, etc. The embodiments of the present invention are no longer limited, and users can set them according to actual needs, as long as the purpose of the embodiments of the present invention can be achieved.

[0115] In an embodiment of the present invention, after injecting simulated input and output into the target hardware unit for execution behavior testing, the execution result of the target hardware unit is obtained and compared with the expected execution result in the relevant parameters. This can intuitively determine whether the execution of the target hardware unit in a specific error injection scenario meets expectations, thereby accurately evaluating the performance of the hardware unit.

[0116] A possible implementation method of an embodiment of the present invention also includes: obtaining the host input and output for testing issued by the host's read and write input and output test program; determining the execution unit according to the host input and output; if the execution unit is a firmware input and output engine module, sending the host input and output to the firmware input and output engine module, so that the firmware input and output engine module can split the host input and output, and send the split host input and output to the corresponding hardware unit for execution behavior testing; if the execution unit is a hardware unit, sending the host input and output to the corresponding hardware unit for execution behavior testing.

[0117] In an embodiment of the present invention, for the host input / output issued by the read / write input / output test program, the host input / output can be distributed or split according to the characteristics of the host input / output or the configuration of the disk array controller chip, and the complete host input / output with direct hardware acceleration execution or the split host input / output is routed to the hardware unit for processing; for complex I / O, the firmware input / output engine module needs to perform split processing. Furthermore, the complete host input / output or the split host input / output that needs to be executed by the firmware input / output engine module is routed to the firmware input / output engine module for processing; for the host input / output processed by the firmware input / output engine module, if it still meets the conditions for hardware acceleration, it is continuously routed to the hardware unit for processing.

[0118] In an embodiment of the present invention, by obtaining the host input / output for testing issued by the host read / write input / output test program, determining the execution unit according to the host input / output, and flexibly processing according to the difference of the execution unit, the split processing ability of the firmware input / output engine module can be fully utilized, ensuring that the host input / output can be accurately sent to the corresponding hardware unit for testing, and improving the pertinence and efficiency of the testing.

[0119] A possible implementation manner of the embodiment of the present invention is to send the host input / output to the corresponding hardware unit for execution behavior testing, including: splitting the storage operation of the host input / output according to the execution steps; determining the hardware unit corresponding to each task in the task chain obtained by splitting the storage operation; and sequentially sending each task in the task chain to the corresponding hardware unit for execution behavior testing based on the host input / output.

[0120] In an embodiment of the present invention, the I / O distribution module splits the storage operation of the host input / output according to the execution steps, and further obtains a task chain. Each task in the task chain describes that the corresponding task is executed by the corresponding hardware unit. Furthermore, the host input / output sequentially sends each task in the task chain to the corresponding hardware unit for execution behavior testing. By splitting and sequentially sending tasks, the execution process of the host input / output on multiple hardware units can be simulated more meticulously. Through this refined testing method, the accuracy and comprehensiveness of the testing can be improved.

[0121] A possible implementation manner of the embodiment of the present invention further includes: using the firmware input / output engine module to split the host input / output transferred by the hardware unit, and sending the split host input / output to the corresponding hardware unit for execution behavior testing.

[0122] Due to the simple design of the hardware unit, it can only handle simple I / O and cannot handle complex I / O issued by the host or the firmware engine. At this time, the I / O is forwarded to the firmware input / output engine module for splitting processing and then issued to the hardware unit again, ensuring that the test can proceed normally.

[0123] In the embodiment of the present invention, the firmware input / output engine module has powerful data processing and scheduling capabilities, can efficiently split the host input / output, and ensure that the split tasks can be accurately allocated to the corresponding hardware units for execution; the method of using the firmware input / output engine module to process the host input / output can improve the accuracy and efficiency of I / O task allocation.

[0124] Based on any of the above embodiments, specifically refer to Figure 10 , Figure 10 which is a schematic diagram of a global workflow provided by the embodiment of the present invention, including:

[0125] The first step is to trigger the simulated input / output injection behavior through the management plane during the host input / output test. The behaviors are of the following types: 1) The first type, abnormal trigger type, that is, in the real test environment, it is used to cover the test of the abnormal branch of the hardware module; 2) The second type, performance impact type, that is, in the real test environment, it is used to cover the functional test of the hardware module under high load; 3) The third type, customized I / O type, that is, in the real test environment, it is used to construct the test of customized I / O. It can be used for the requirements in specific scenarios such as fault reproduction related to customized I / O and long-term stress testing.

[0126] The second step is to complete the construction of the simulated input / output and the triggering of the simulated input / output (issued to the hardware unit for execution) inside the disk array controller chip according to the type and parameters of the simulated input / output injection behavior triggered by the management platform.

[0127] The third step is to observe on the host through the management plane whether the behavior of the SoC chip meets the expectations: 1) The function of the test function index of the host input / output is not affected; 2) The impact on the test performance index meets the expectations; 3) The performance monitoring data of the tested hardware unit meets the expectations; 4) The abnormal reporting of the tested hardware module meets the expectations; 5) The customized I / O is completed as expected.

[0128] In the overall test process, after the TDC is executed in the hardware, first judge the source of the simulated input / output. If it comes from the firmware input / output engine module, notify it to continue to complete the original I / O. Finally, by comparing the execution result of the TDC with the expected result in the NVMe extended command, it can be judged whether the result of the test meets the expectations, and finally print the result to complete this test.

[0129] An embodiment of the present invention provides a method for performing abnormal testing, stress testing, and customized input / output testing on internal hardware modules of a RAID card based on error injection, including the definition of error injection commands, injection methods, and testing methods; a method for enabling a disk array controller chip hardware to execute specific IOs is designed, including a method of directly using host NVMe extended commands to construct the input / output to be simulated, a method of internally allocating resources to directly construct simulated input / output, and a method of intercepting real host input / output or transferring IOs through a firmware input / output engine module.

[0130] Through the system and method provided by the present invention, a verification test system and method based on error injection of a disk array controller chip can be provided. It provides a method of extending NVMe commands in a host environment. In the real working environment of the disk array controller chip, without affecting the normal execution of host input / output, various customized host input / outputs can be injected according to the test verification requirements to directly and comprehensively test the hardware unit, which can meet various test verification requirements such as fault reproduction and regression, and can provide the pertinence and timeliness of test verification. The specific test method is flexible and open, with strong scalability, good customizability of test data, and high extensibility of the test method, which can cope with diverse test verification requirements. This system and method conduct hardware module test verification in a formal environment. Compared with the verification test of a single hardware module, the test environment is more real and effective, and the test results are more credible. On the one hand, it can effectively make up for the problem in chip hardware verification that the simulation speed is slow, resulting in the inability to test the behavior of the test engine under high workload in a real environment. This method can also be used as a method for pre-silicon performance evaluation. On the other hand, a customizable IO simulation system and method are proposed, which can test its concurrency with specified IOs in a real environment. Finally, a system and method for testing the performance of the test engine under various abnormal conditions in a real environment are also proposed. A developed and customizable test method based on a real environment is provided.

[0131] Figure 11 A schematic structural diagram of a test device provided by an embodiment of the present invention includes: a task distribution module 210, configured to obtain a test management command sent by a host during the process of performing input / output testing based on a read / write input / output test program, where the test management command represents an input / output management command for error injection;

[0132] An injection management module 220, configured to parse the test management command to obtain an error injection test type and corresponding relevant parameters, and change the error handling mode according to the error injection test type. The changed error handling mode is used to indicate that only reporting is performed when an exception is encountered during the test without performing exception handling;

[0133] The input / output simulation function module 230 is used to construct simulated input / outputs according to the error injection test type and related parameters; and inject the simulated input / outputs into the target hardware unit to perform an execution behavior test on the target hardware unit, where the target hardware unit is the hardware unit corresponding to the hardware identifier in the related parameters.

[0134] In a possible implementation, the input / output simulation function module 230 is used to: if the error injection test type is the first type or the second type, construct the simulated input / outputs corresponding to the first task chain according to the task description, task type, and data in the related parameters; the first type represents the hardware unit exception type, and the second type represents the hardware unit high-load type; if the error injection test type is the third type, use the firmware input / output engine module to determine the target input / output; and construct the simulated input / outputs corresponding to the second task chain according to the target input / output; the third type represents a specific input / output type, and the target input / output is the input / output in the firmware input / output engine module that is larger than the target input / output size in the related parameters and has the same input / output type as that in the related parameters.

[0135] In a possible implementation, the input / output simulation function module 230 is used to: if the error injection test type is the first type, construct the simulated input / outputs corresponding to the first task chain according to the task description, task type, and data in the related parameters; if the error injection test type is the second type, construct the simulated input / outputs corresponding to the first task chain according to the task description, task type, task count, and data in the related parameters.

[0136] In a possible implementation, the first task chain includes task descriptions corresponding to at least one hardware unit.

[0137] In a possible implementation, the input / output simulation function module 230 is further used to: pause the execution operation of the target input / output in the firmware input / output engine module; and resume the execution operation of the target input / output in the firmware input / output engine module after completing the behavior test.

[0138] In a possible implementation, the input / output simulation function module 230 is used to: if the number of target input / outputs is multiple, select the input / output corresponding to the target hardware unit from the target input / outputs and construct the simulated input / outputs corresponding to the second task chain.

[0139] In a possible implementation, the injection management module 220 is further used to: move the related parameters to the internal space of the chip; correspondingly, the input / output simulation function module 230 is used to: read the related parameters from the internal space of the chip and construct the simulated input / outputs according to the error injection test type and the related parameters.

[0140] In a possible implementation, the injection management module 220 is further configured to: if the relevant parameters include a task description and data, check the integrity of the task description and data; correspondingly, the injection management module 220 is further configured to: if both the task description and data pass the integrity check, change the error handling mode according to the error injection test type.

[0141] In a possible implementation, the test management command is generated by the host encoding the error injection test type and relevant parameters into the corresponding fields of the extended command format of the non-volatile memory host controller interface specification protocol; the injection management module 220 is configured to: parse the test management command according to the error injection definition table to obtain the error injection test type and relevant parameters.

[0142] In a possible implementation, the error injection definition table includes an opcode field for representing the error injection test type and fields corresponding to the relevant parameters; among them, the fields corresponding to the relevant parameters include: task description, task type, number of tasks, data, input / output type, input / output size, hardware identifier, and expected execution result.

[0143] In a possible implementation, it further includes a result comparison module, configured to obtain the execution result of the target hardware unit; compare the execution result with the expected execution result in the relevant parameters.

[0144] In a possible implementation, it further includes an input / output distribution module, configured to obtain the host input / output for testing sent by the read / write input / output test program of the host; determine the execution unit according to the host input / output; if the execution unit is the firmware input / output engine module, send the host input / output to the firmware input / output engine module, so that the firmware input / output engine module can split the host input / output and send the split host input / output to the corresponding hardware unit for execution behavior testing; if the execution unit is a hardware unit, send the host input / output to the corresponding hardware unit for execution behavior testing.

[0145] In a possible implementation, the input / output distribution module is configured to: split the storage operation of the host input / output according to the execution steps; determine the hardware unit corresponding to each task in the task chain obtained by splitting the storage operation; and sequentially send each task in the task chain to the corresponding hardware unit for execution behavior testing based on the host input / output.

[0146] In a possible implementation, it further includes a firmware input / output engine module, configured to split the host input / output transferred by the hardware unit and send the split host input / output to the corresponding hardware unit for execution behavior testing.

[0147] Figure 11For the description of the features in the corresponding embodiments, reference can be made to Figure 5 the relevant descriptions of the corresponding embodiments, which will not be elaborated here one by one.

[0148] Figure 12 The following is a structural diagram of an electronic device provided by an embodiment of the present invention. As Figure 12 shown, the electronic device includes: a memory 60 for storing a computer program; a processor 61 for implementing the steps of the method in the above embodiment when executing the computer program.

[0149] The electronic device provided in this embodiment may include, but is not limited to, a smart phone, a tablet computer, a laptop computer, or a desktop computer, etc.

[0150] Among them, the processor 61 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 61 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the wake state, also known as the central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 61 may be integrated with a graphics processing unit (GPU), and the GPU is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 61 may further include an artificial intelligence (AI) processor for processing computational operations related to machine learning.

[0151] The memory 60 may include one or more computer-readable storage media, and the computer-readable storage media may be non-transitory. The memory 60 may further include a high-speed random access memory and a non-volatile memory, such as one or more disk storage devices and flash storage devices. In this embodiment, the memory 60 is at least used to store the following computer program 601. After the computer program is loaded and executed by the processor 61, it can implement the relevant steps of the method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 60 may further include an operating system 602 and data 603, etc., and the storage method may be transient storage or permanent storage. Among them, the operating system 602 may include Windows, Unix, Linux, etc.

[0152] In some embodiments, the electronic device may further include a display screen 62, an input / output interface 63, a communication interface 64, a power supply 65, and a communication bus 66.

[0153] Those skilled in the art can understand that Figure 12 the structure shown in does not constitute a limitation on the electronic device, and it may include more or fewer components than those shown in the figure.

[0154] It can be understood that if the disk array controller chip verification test method in the above embodiments is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the current technology, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drives, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), electrically erasable programmable ROMs, registers, hard disks, removable disks, CD-ROMs, magnetic disks, or optical disks, and other various media that can store program codes.

[0155] Based on this, the embodiments of the present invention further provide a test system, including: the electronic device as described above; a host for sending test management commands to the electronic device and obtaining test results.

[0156] In an implementable manner, the host is further configured to: obtain a test result set for each hardware unit, where the test result set includes result subsets corresponding to multiple error injection test types respectively; draw a change curve for each error injection test type according to the test time of each test result in the result subset; for each error injection test type, determine a performance score according to the corresponding change curve; and determine the performance of each hardware unit according to the performance scores corresponding to the multiple error injection test types respectively.

[0157] Specifically, multiple error types may be tested for the same hardware unit, and then each error type is tested multiple times to obtain a subset of results corresponding to each test category. For each error injection test type, a change curve is plotted based on the test time of each test result in the corresponding subset of results. For each error injection test type, a performance score is determined based on the corresponding change curve. For different types, different score determination methods are defined. Furthermore, after obtaining the change curves, the performance scores can be determined according to the determination methods. The invention embodiments do not limit the score determination methods, which can be preset by users. Furthermore, after obtaining the performance scores corresponding to all types, a comprehensive performance score can be determined by weighted calculation or average calculation to intuitively understand the performance of the hardware unit.

[0158] Based on this, the embodiments of the present invention further provide a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above method are implemented.

[0159] Based on this, the embodiments of the present invention further provide a computer program product, including computer programs / instructions. When the computer programs / instructions are executed by a processor, the steps of the above method are implemented.

[0160] The above has introduced in detail a method, device, equipment, medium, and product for verifying and testing a disk array controller chip provided by the embodiments of the present invention. The embodiments in the specification are described in a progressive manner. The key point of each embodiment is to illustrate the differences from other embodiments. The same or similar parts among the embodiments can be referred to each other. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions in the method part.

[0161] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0162] The above has introduced in detail a method, device, equipment, medium and product for verifying and testing a disk array controller chip provided by the present invention. Specific examples are used in this article to elaborate on the principle and implementation manner of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the protection scope of the present invention.

Claims

1. A testing method, characterized in that, Performed by an electronic device having a disk array controller chip, the test method includes: During the input / output test based on a read / write input / output test program, obtain a test management command sent by a host, where the test management command represents an input / output management command for error injection; Parse the test management command to obtain an error injection test type and corresponding related parameters, and change the error handling mode according to the error injection test type. The changed error handling mode is used to indicate that only reporting is performed when an exception is encountered during the test without performing exception handling; Construct a simulated input / output according to the error injection test type and the related parameters; inject the simulated input / output into a target hardware unit to perform an execution behavior test on the target hardware unit, where the target hardware unit is the hardware unit corresponding to the hardware identifier in the related parameters.

2. The test method according to claim 1, wherein Construct a simulated input / output according to the error injection test type and the related parameters, including: If the error injection test type is the first type or the second type, construct a simulated input / output corresponding to a first task chain according to the task description, task type, and data in the related parameters; the first type represents a hardware unit exception type, and the second type represents a hardware unit high-load type; If the error injection test type is the third type, use a firmware input / output engine module to determine a target input / output; and construct a simulated input / output corresponding to a second task chain according to the target input / output; the third type represents a specific input / output type, and the target input / output is an input / output in the firmware input / output engine module that is greater than the target input / output size in the related parameters and has the same input / output type as the related parameters.

3. The test method according to claim 2, wherein If the error injection test type is the first type or the second type, construct a simulated input / output corresponding to a first task chain according to the task description, task type, and data in the related parameters, including: If the error injection test type is the first type, construct a simulated input / output corresponding to the first task chain according to the task description, task type, and data in the related parameters; If the error injection test type is the second type, construct a simulated input / output corresponding to the first task chain according to the task description, task type, number of tasks, and data in the related parameters.

4. The testing method according to claim 3, wherein The first task chain includes task descriptions corresponding to at least one hardware unit.

5. The test method according to claim 2, characterized in that After using the firmware input / output engine module to determine the target input / output, it further includes: Pause the execution operation of the target input / output in the firmware input / output engine module; Correspondingly, after injecting the simulated input / output into the target hardware unit to perform an execution behavior test on the target hardware unit, it further includes: After completing the behavior test, resume the execution operation of the target input / output in the firmware input / output engine module.

6. The test method according to claim 2, wherein Construct a simulated input / output corresponding to a second task chain according to the target input / output, including: If the number of the target input / outputs is multiple, select the input / output corresponding to the target hardware unit from the target input / outputs, and construct the analog input / output corresponding to the second task chain.

7. The test method according to claim 1, wherein After parsing the test management command to obtain the error injection test type and the corresponding relevant parameters, it further includes: Move the relevant parameters to the internal space of the chip; Correspondingly, constructing the analog input / output according to the error injection test type and the relevant parameters includes: Read the relevant parameters from the internal space of the chip, and construct the analog input / output according to the error injection test type and the relevant parameters.

8. The test method according to claim 7, characterized in that After moving the relevant parameters to the internal space of the chip, it further includes: If the relevant parameters include: task description and data, check the integrity of the task description and the data; Correspondingly, changing the error handling mode according to the error injection test type includes: If both the task description and the data pass the integrity check, change the error handling mode according to the error injection test type.

9. The test method according to claim 1, wherein The test management command is generated by the host encoding the error injection test type and the relevant parameters into the corresponding fields of the extended command format of the Non-Volatile Memory Host Controller Interface Specification protocol; Correspondingly, parsing the test management command to obtain the error injection test type and the corresponding relevant parameters includes: Parse the test management command according to the error injection definition table to obtain the error injection test type and the relevant parameters.

10. The test method according to claim 9, characterized in that, The error injection definition table includes an opcode field for representing the error injection test type and fields corresponding to the relevant parameters; among them, the fields corresponding to the relevant parameters include: task description, task type, number of tasks, data, input / output type, input / output size, hardware identifier, and expected execution result.

11. The testing method according to claim 10, characterized in that, After injecting the analog input / output into the target hardware unit to perform an execution behavior test on the target hardware unit, it further includes: Obtain the execution result of the target hardware unit; Compare the execution result with the expected execution result in the relevant parameters.

12. The test method according to claim 1, characterized in that, It further includes: Obtain the host input / output for testing sent by the read / write input / output test program of the host; Determine the execution unit according to the host input / output; If the execution unit is the firmware input / output engine module, send the host input / output to the firmware input / output engine module, so that the firmware input / output engine module can perform splitting processing on the host input / output and send the split host input / output to the corresponding hardware unit for execution behavior testing; If the execution unit is a hardware unit, send the host input / output to the corresponding hardware unit for execution behavior testing.

13. The test method according to claim 12, characterized in that, Sending the host input / output to the corresponding hardware unit for execution behavior testing includes: Split the storage operation of the host input / output according to the execution steps; Determine the hardware unit corresponding to each task in the task chain obtained by splitting the storage operation; Based on the host input / output, sequentially send each task in the task chain to the corresponding hardware unit for execution behavior testing.

14. The test method according to claim 12, wherein It further includes: Using the firmware input / output engine module, the host input / output transferred by the hardware unit is split, and the split host input / output is sent to the corresponding hardware unit for execution behavior testing.

15. A testing device, characterized in that, It includes: A task distribution module, which is used to obtain a test management command sent by the host during the input / output test based on the read / write input / output test program, and the test management command represents an input / output management command for error injection. An injection management module, which is used to parse the test management command to obtain the error injection test type and the corresponding relevant parameters, and change the error handling mode according to the error injection test type. The changed error handling mode is used to indicate that only reporting is performed when an exception is encountered during the test and no exception handling is performed. An input / output simulation function module, which is used to construct simulated input / output according to the error injection test type and the relevant parameters. Inject the simulated input / output into the target hardware unit to perform an execution behavior test on the target hardware unit, where the target hardware unit is the hardware unit corresponding to the hardware identifier in the relevant parameters.

16. An electronic device with a disk array controller chip, characterized in that, It includes: A memory, which is used to store computer programs. A processor, which is used to execute the computer program to implement the steps of the method according to any one of claims 1 to 14.

17. A test system, characterized in that, It includes: The electronic device according to claim 16; A host, which is used to send a test management command to the electronic device and obtain the test result.

18. The test system according to claim 17, wherein The host is further used for: Obtaining a test result set of each hardware unit, where the test result set includes result subsets corresponding to multiple error injection test types respectively; Drawing a change curve for each error injection test type according to the test time of each test result in the result subset; For each error injection test type, determining a performance score according to the corresponding change curve; Determining the performance of each hardware unit according to the performance scores corresponding to multiple error injection test types respectively.

19. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, and when the computer program is executed by the processor, the steps of the method according to any one of claims 1 to 14 are implemented.

20. A computer program product, comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, the steps of the method according to any one of claims 1 to 14 are implemented.

Images