Pre-silicon test method and device

Abstract

The invention provides a pre-silicon test method and device. According to the method and the device, the bottleneck of the real hard disk is simulated, so that the processing capacity of the virtual hard disk simulated in the operating system is close to the processing capacity of the real hard disk as much as possible, and the test scene is close to the real scene as much as possible; therefore, the condition that the software accesses the virtual hard disk simulated in the operating system is as close as possible to the condition that the software accesses the real hard disk, for example, the test result that whether the tested virtual processor can support the normal operation of the software according to the expected requirement is as close as possible to the real condition. By means of the method and device, the accuracy of the test result can be improved, or the test result can conform to the real situation as much as possible, and it is avoided that follow-up software normally provides data services externally as much as possible.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a pre-silicon testing method and device. Background Art

[0002] With the rapid development of technology, the functions of processors are becoming more and more powerful, and the application of processors in people's lives and work is becoming more and more extensive. Correspondingly, major manufacturers are gradually entering the processor industry.

[0003] The formation of a processor involves a design stage and a production stage. The design stage is used to design the circuit structure of the processor, and the production stage is used to produce the processor (physical object) according to the designed circuit structure of the processor.

[0004] However, processors include highly complex circuit systems. Therefore, the circuit structure of the processor designed during the design phase is inevitably subject to logical errors or defects where performance does not meet expectations. Consequently, processors manufactured based on this designed circuit structure may also contain logical errors or defects where performance does not meet expectations. Therefore, testing is often necessary to eliminate logical errors or defects where performance does not meet expectations.

[0005] However, the test results of the current testing method deviate greatly from the actual situation and the test accuracy is low. Summary of the Invention

[0006] The present application provides a pre-silicon testing method and apparatus.

[0007] In a first aspect, the present application shows a pre-silicon testing method, wherein a virtual processor runs on an electronic device, an operating system runs on the virtual processor, the operating system has a simulated virtual hard disk, and software runs on the operating system. The method is applied to the virtual processor, and the method includes: when an access request to the virtual hard disk submitted by the software is dispatched to the virtual hard disk for processing, and an indication is received from the virtual hard disk indicating that the access request has been processed, the access request is stored in a first queue; the access requests stored in the first queue are access requests that have been processed; the processing capacity parameters of the real hard disk are obtained; according to the processing capacity parameters of the real hard disk, the access request to be released is selected in the first queue; and the access request to be released is returned to the software.

[0008] On the second aspect, the present application shows a pre-silicon testing method, in which a virtual processor runs on an electronic device, an operating system runs on the virtual processor, the operating system has a simulated virtual hard disk, and software runs on the operating system. The method is applied to the virtual processor, and the method includes: dispatching an access request to the virtual hard disk submitted by the software to the virtual hard disk for processing, and receiving an indication returned by the virtual hard disk indicating that the access request has been processed, generating an interrupt signal; responding to the interrupt signal; and returning the access request to the software after the interrupt signal is responded to.

[0009] On the third aspect, the present application shows a pre-silicon testing device, in which a virtual processor runs on an electronic device, an operating system runs on the virtual processor, the operating system has a simulated virtual hard disk, and software runs on the operating system. The device is applied to the virtual processor, and the device includes: a storage module for storing the access request submitted by the software to the virtual hard disk in a first queue when scheduling the access request to the virtual hard disk to the virtual hard disk for processing and receiving an indication returned by the virtual hard disk indicating that the access request has been processed; the access request stored in the first queue is the access request that has been processed; an acquisition module for obtaining the processing capacity parameters of the real hard disk; a selection module for selecting the access request to be released in the first queue according to the processing capacity parameters of the real hard disk; and a first return module for returning the access request to be released to the software.

[0010] In a fourth aspect, the present application shows a pre-silicon testing device, in which a virtual processor runs on an electronic device, an operating system runs on the virtual processor, the operating system has a simulated virtual hard disk, and software runs on the operating system. The device is applied to the virtual processor, and the device includes: a first generation module, which is used to dispatch an access request to the virtual hard disk submitted by the software to the virtual hard disk for processing, and generates an interrupt signal when receiving an indication returned by the virtual hard disk indicating that the access request has been processed; a first response module, which is used to respond to the interrupt signal; and a second return module, which is used to return the access request to the software after the interrupt signal is responded to.

[0011] In a fifth aspect, the present application shows an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method shown in any of the aforementioned aspects when executing the program.

[0012] In a sixth aspect, the present application shows a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the method shown in any of the aforementioned aspects is implemented.

[0013] In a seventh aspect, the present application shows a computer program product, including a computer program / computer executable instructions, which, when executed by a processor in an electronic device, implements the method shown in any of the aforementioned aspects.

[0014] Compared with the prior art, this application has the following advantages:

[0015] Through this application, by simulating the bottleneck of a real hard disk, the processing power of the virtual hard disk simulated in the operating system is made as close as possible to the processing power of the real hard disk, and the test scenario is made as close as possible to the real scenario, so that the situation in which the software accesses the virtual hard disk simulated in the operating system is made as close as possible to the situation in which the software accesses the real hard disk. For example, the test result of "whether the virtual processor can support the normal operation of the software according to the expected requirements" is made as close as possible to the real situation.

[0016] For example, in an objective and real situation, after a processor (a physical object) is produced according to the designed processor circuit structure and an operating system is run on the produced processor and software is run on the operating system, the operating system cannot support the normal operation of the software according to the expected requirements (for example, it cannot meet the requirement of a short time spent on reading and writing on a real hard disk, etc.). That is, the produced processor cannot meet the requirements of the software, and the produced processor cannot support the normal operation of the software according to the expected requirements, and thus cannot provide normal data services to the outside world.

[0017] Correspondingly, the test results obtained through the solution of this application are also: the virtual processor generated according to the circuit structure of the designed processor cannot support the normal operation of the software according to the expected requirements (for example, it cannot meet the requirement of short time consumption for reading and writing the virtual hard disk, etc.).

[0018] It can be seen that through this application, the accuracy of the test results can be improved, or the test results can be made as consistent as possible with the actual situation, thereby avoiding affecting the normal provision of data services to the outside world by subsequent software as much as possible. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 This is a schematic diagram of an application scenario of the present application.

[0020] Figure 2 This is a flowchart of the steps of a pre-silicon testing method of the present application.

[0021] Figure 3 This is a flowchart of the steps of a method for selecting an access request to be released in the present application.

[0022] Figure 4This is a schematic diagram of an application scenario of the present application.

[0023] Figure 5 This is a flowchart of the steps of a method for storing access requests in the present application.

[0024] Figure 6 It is a schematic diagram of a pre-silicon testing method of the present application.

[0025] Figure 7 This is a structural block diagram of a pre-silicon testing device of the present application.

[0026] Figure 8 This is a structural block diagram of a pre-silicon testing device of the present application.

[0027] Figure 9 This is a structural block diagram of a device of the present application. DETAILED DESCRIPTION

[0028] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0029] The following description sets forth many specific details to facilitate a thorough understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the scope of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0030] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "the," and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0031] First, explain the professional terms that may be involved in the subsequent text description.

[0032] Pre-silicon testing: Before production, chips designed using hardware description languages ​​must be tested to ensure that their functionality and performance meet expectations. This testing process is called pre-silicon testing. Pre-silicon testing can identify errors in the hardware design phase earlier, shortening hardware development time.

[0033] Software: A collection of computer programs and related data, documentation, and configuration files. It is a set of instructions and data used in a computer system to perform a specific function or complete a specific task.

[0034] Kernel: The internal core program of the operating system.

[0035] Hard Drive: A computer storage device used for long-term storage and retrieval of data.

[0036] IO: Abbreviation for Input / Output. It refers to the process of exchanging data between a computer system and external devices. Each device has a dedicated I / O address that handles its own input and output information. Input is the signal or data received by a system, while output is the signal or data sent from it. The term can also be used to refer to an action; to "perform I / O" is to perform an input or output operation. Input / output devices are hardware components used by people (or other systems) to communicate with a computer. For example, a keyboard or mouse is an input device for a computer, while a printer is an output device. Communication devices between computers, such as telecommunications modems and network cards, typically perform input and output operations.

[0037] IO bandwidth: The average amount of data read and written to the hard disk device per second.

[0038] IO latency: The average completion time of read and write requests to the hard disk device.

[0039] I / O interrupts: An interrupt is a signal sent by a hardware device to the CPU, interrupting its operation. An I / O interrupt is a signal sent by a hard drive to the processor, notifying the processor that the hard drive has completed an I / O request or that a failure has occurred while the hard drive is processing an I / O request.

[0040] ramdisk: A type of virtual storage device. Unlike traditional hard disk devices, ramdisk uses a continuous block of memory as a storage area, and its read and write operations are the most direct memory copies.

[0041] Null blk: A type of virtual storage device. Null blk devices use discrete memory pages as storage media. Memory pages can be dynamically allocated and released. In addition, null blk implements a complex multi-queue mechanism.

[0042] IPI: Inter-Processor Interrupt, an inter-processor core interrupt, which is controlled by software to cause a processor core to interrupt another processor core.

[0043] MQ queue, Multi-Queue, block device multi-queue.

[0044] FIO is an open source disk IO performance testing tool that aims to provide a comprehensive testing solution that can simulate common I / O scenarios, including parameters such as random / sequential reads and writes, read-write ratios, block size, and I / O depth. Its test results are detailed and accurate and can be used to evaluate system disk performance, locate bottlenecks, optimize parameters, and more. FIO's testing principle is to perform a series of simulated I / O operations on the target device, record the performance indicators of each test task (including IOPS, throughput, latency, CPU utilization, etc.), and finally generate a result report. FIO's testing process is very precise and detailed, and can be optimized according to different test scenarios and parameters.

[0045] In one approach, the processor (physical object) can be produced during the production phase and then tested. However, if the produced processor is found to have logical errors or design defects that do not meet expected specifications, the produced processor can only be scrapped, and the resources and time previously consumed in the process of producing the processor are basically wasted. It can be seen that the above approach is costly and inefficient in producing a defect-free processor.

[0046] Therefore, in order to reduce costs and improve efficiency, another approach is proposed. For example, after the circuit structure of the processor is designed in the design phase and before the production phase, the designed circuit structure of the processor can be tested, for example, pre-silicon testing.

[0047] Among them, pre-silicon testing is one of the important processes in the processor R&D cycle. It can discover logical errors in the circuit structure of the designed processor or defects such as design indicators not meeting expectations before the processor (physical form) is produced according to the circuit structure of the designed processor, which can greatly reduce costs and improve efficiency.

[0048] In the pre-silicon testing scenario, a pre-silicon testing platform is required. For example, the circuit structure of the designed processor can be input into the pre-silicon testing platform. The pre-silicon testing platform can generate a virtual processor and sometimes virtual memory. The virtual processor is generated based on the circuit structure of the designed processor. The virtual processor can be regarded as a processor simulator. After that, the operating system can be run on the virtual processor, and the software can be run on the operating system to test the circuit structure of the designed processor through the software to see if there are logical errors or defects in the design indicators not meeting expectations.

[0049] For example, after obtaining the result of running the software on the operating system, it can be determined whether the result of running the software on the operating system is consistent with the expected result.

[0050] Among them, since the operating system runs on a virtual processor and the software runs on the operating system, it can be regarded as the virtual processor providing resources for the software, that is, the virtual processor indirectly runs the software, and the running results of the software on the operating system can be regarded as the running results of the software on the virtual processor. The running results of the software on the virtual processor can be used to determine whether there are logical errors in the circuit structure of the designed processor or defects such as design indicators not meeting expectations.

[0051] If the running results of the software on the operating system do not match the expected results, it means that there are logical errors in the circuit structure of the designed processor or the design indicators do not meet the expected defects. The circuit structure of the designed processor cannot be put into production and needs to be readjusted until the circuit structure of the designed processor no longer has the defects of logical errors and no longer has the defects of design indicators not meeting the expectations. It can then be put into production.

[0052] Alternatively, if the running results of the software on the operating system are consistent with the expected results, it means that the circuit structure of the designed processor does not have any logical error defects and does not have any defects that the design indicators do not meet expectations, and the circuit structure of the designed processor can be put into production.

[0053] Among them, the software running on the operating system includes test software, which is developed in advance and is used to test whether the circuit structure of the designed processor has logical errors or design indicators do not meet expected defects.

[0054] However, sometimes there is a need to run software with more complex functions, software with more complex internal logic, or software that can provide a variety of services on the operating system. Such software may include processing software based on neural network models to process data, management software that provides management services to enterprises, and game software for running games, etc., or such software may include software that takes up more than 1GB of space.

[0055] This type of software often has very stringent requirements on the operating environment. For example, the operation of this type of software requires the support of a powerful processor. Therefore, this type of software often has very stringent requirements on the processor.

[0056] To this end, in order to ensure that such software can operate normally as expected and thus provide external data services normally as expected, the developers of such software may request the processor manufacturer to customize a powerful processor for such software, so that the customized processor can meet the stringent requirements of such software on the processor, and thus ensure that such software can operate normally as expected based on the customized processor and provide external data services normally as expected.

[0057] Therefore, after running the test software on the operating system to test whether the circuit structure of the designed processor has logical errors and whether the design indicators do not meet expectations, it is still necessary to run such software on the operating system to test whether the virtual processor can support the normal operation of such software according to the expected requirements, and to test whether the circuit structure of the designed processor can support the normal operation of such software according to the expected requirements.

[0058] However, after the inventors ran this type of software on the operating system to test whether the virtual processor could support the normal operation of this type of software as expected, the test result was: the virtual processor could not support the normal operation of this type of software as expected, that is, this type of software based on the virtual processor could not operate normally as expected.

[0059] The inventor then readjusted the circuit structure of the designed processor to obtain a readjusted circuit structure of the processor, and then repeated the above test process on the readjusted circuit structure of the processor. However, the test results were still: the virtual processor generated based on the readjusted circuit structure of the processor still could not support the normal operation of this type of software as expected.

[0060] The inventor then adjusted the circuit structure of the designed processor again to obtain a re-adjusted circuit structure of the processor, and then repeated the above test process on the re-adjusted circuit structure of the processor. However, the test results were still: the virtual processor generated based on the re-adjusted circuit structure of the processor still could not support the normal operation of this type of software as expected.

[0061] This goes on and on... After the inventor adjusted the circuit structure of the designed processor several times and then tested it again, the test results were still: the virtual processor generated according to the adjusted circuit structure of the processor could not support the normal operation of this type of software as expected.

[0062] In view of this, the inventors took a different approach and thought of a possibility: the above test results may not be caused by the circuit structure of the designed processor, but may be caused by the characteristics of the pre-silicon test platform itself.

[0063] For example, the circuit structure of the designed processor itself does not have any logical errors or design indicators that do not meet expectations, but the pre-silicon test platform itself has defects, resulting in the test results always being: the virtual processor generated according to the circuit structure of the designed processor cannot support the normal operation of this type of software according to the expected requirements.

[0064] That is, in objective reality, after a processor (physical object) is produced according to the designed processor circuit structure and an operating system is run on the produced processor and such software is run on the operating system, the operating system can support such software to operate normally according to the expected requirements. That is, the produced processor can meet the needs of such software, and the produced processor can support such software to operate normally according to the expected requirements, and thus can provide data services to the outside world normally.

[0065] However, the test results show that the virtual processor generated according to the circuit structure of the designed processor cannot support the normal operation of this type of software as expected. It can be seen that the test results are wrong, or the test results do not match the actual situation.

[0066] Furthermore, the inventors attempted to explore the reasons why the test results were erroneous due to the characteristics of the pre-silicon test platform itself, and found that:

[0067] The current test scenario only includes two components, for example, only a virtual processor and memory generated by a pre-silicon test platform, without other components. That is, the components generated by the current pre-silicon test platform are incomplete and have fewer components than those in a normal device.

[0068] The virtual processor and memory components generated by the pre-silicon test platform can meet the requirements of the test software for the operating environment, that is, the virtual processor and memory components generated by the pre-silicon test platform can support the operation of the test software to support the test software to test whether there are logical errors in the circuit structure of the designed processor or defects in the design indicators not meeting expectations.

[0069] For example, the virtual processor generated on the pre-silicon test platform can run the operating system and can run the test software on the operating system, and the test functions of the test software can be realized. That is, the running results of the test software on the virtual processor generated by the pre-silicon test platform can be used to accurately test whether there are logical errors in the circuit structure of the designed processor or defects that the design indicators do not meet expectations.

[0070] However, this type of software has many functions. After running an operating system on a virtual processor generated by a pre-silicon test platform and running this type of software on the operating system, many functions of this type of software cannot be realized, resulting in the test result that the virtual processor cannot support the normal operation of this type of software as expected.

[0071] For example, when this type of software is officially running, it runs on a real device. The real device has a real processor, etc. The operating system runs on the real processor, and this type of software runs on the operating system. Secondly, the real device includes not only a real processor and memory, but also commonly used real components such as network cards and hard drives, etc., for this type of software to use during operation.

[0072] Reading and writing to the hard drive is often a crucial component of this type of software. When running on an operating system, the real processor provides operational support for large commercial software. Sometimes, to implement certain features of this software, the real processor needs to read and write to the operating system's hard drive to read or store data.

[0073] However, the components generated by current pre-silicon test platforms often only have virtual processors, and may also include memory, but no components such as hard disks. As a result, when such software is run on the operating system, the functions that require reading and writing hard disks to support such software cannot be implemented, which in turn leads to the above-mentioned erroneous test results: the virtual processor generated according to the circuit structure of the designed processor cannot support the normal operation of such software as expected.

[0074] In view of this, it is proposed that after a virtual processor is generated on a pre-silicon test platform and an operating system is run on the virtual processor, the hard disk requirement is simulated in the operating system so that the operating system has a virtual hard disk. In this way, during the operation of such software on the operating system, the virtual processor can read and write the virtual hard disk according to the functions supported by such software that need to read and write the hard disk, so that the functions in such software that need to read and write the hard disk can be implemented. In this way, when the circuit structure of the designed processor itself does not have the defect of logical error and the defect of design indicators not meeting expectations, the test result can be: the virtual processor generated according to the circuit structure of the designed processor can support the normal operation of such software according to the expected requirements, that is, the test result is accurate, or the test result is consistent with the actual situation.

[0075] In order to simulate the hard disk in the operating system after the pre-silicon test platform generates a virtual processor and runs the operating system on the virtual processor, in another way, after the pre-silicon test platform generates a virtual processor and runs the operating system on the virtual processor, a ramdisk can be used in the operating system to simulate the hard disk.

[0076] For example, ramdisk can simulate a virtual hard disk through memory (the memory here can be at least a portion of the memory generated by the pre-silicon test platform, etc.), that is, ramdisk uses memory as the storage medium of the virtual hard disk.

[0077] It can be seen that the virtual processor's reading and writing process of the virtual hard disk simulated based on the ramdisk in response to the instructions of this type of software is a "synchronous" process of reading and writing memory, for example, it may include:

[0078] 01. This type of software generates IO requests.

[0079] 02. This type of software passes IO requests to ramdisk.

[0080] 03. Ramdisk converts the hard disk address involved in the IO request into a memory address (the virtual hard disk is the memory, and the converted memory address is the memory address corresponding to the virtual hard disk).

[0081] 04. Ramdisk performs memory copy based on the converted memory address to complete the processing of IO request.

[0082] 05. Ramdisk returns the result of processing the IO request to this type of software.

[0083] From the preceding process, we can see that the process of processing I / O requests based on a ramdisk is almost equivalent to the process of copying memory. Therefore, the I / O bandwidth and I / O latency of the process of processing I / O requests based on a ramdisk are almost equal to the I / O bandwidth and I / O latency of the memory copy process.

[0084] Among them, 01 to 02 are executed by the processor, and 03 to 05 are executed by the ramdisk.

[0085] However, because the IO bandwidth and IO latency of a real hard disk are limited by the characteristics of the real hard disk itself, the MQ queue, and the processing power of the IO scheduler, the IO bandwidth of a real hard disk is different from the IO bandwidth of the memory, and the IO latency of a real hard disk is different from the IO latency of the memory.

[0086] For example, the read and write process of a real processor on a real hard disk may include:

[0087] 11. This type of software generates IO requests.

[0088] 12. This type of software passes IO requests to the kernel of the computer system.

[0089] 13. The computer system's kernel dispatches the IO request to the real hard disk driver.

[0090] 14. The queue manager in the real hard disk driver adds the IO request to the MQ queue.

[0091] 15. The IO scheduler in the real hard disk driver dispatches the IO requests that need to be scheduled in the MQ queue to the real hard disk.

[0092] 16. Real hard disk IO request processing.

[0093] 17. The real hard disk returns the result of processing the IO request to the real hard disk driver.

[0094] 18. The real hard disk driver returns the result of processing the IO request to the kernel of the computer system.

[0095] 19. The kernel of the computer system returns the results of processing the IO request to this type of software.

[0096] Among them, 11 to 15 are executed by the processor, 18 to 19 are executed by the processor, and 16 to 17 are executed by the actual hard disk.

[0097] It can be seen that the reading and writing processes of the virtual hard disk simulated based on RAM disk are very different from those of the real hard disk. For example, the IO bandwidth of the memory is greater than the IO bandwidth of the real hard disk, and the IO latency of the memory is less than the IO latency of the real hard disk.

[0098] In summary, the IO bandwidth and IO latency of the virtual hard disk in the operating system are different from those of the real hard disk. In other words, the test scenario is different from the real scenario, which will cause the situation when such software accesses the virtual hard disk simulated in the operating system to be different from the situation when such software accesses the real hard disk. For example, the test result of "whether the virtual processor can support the normal operation of such software as expected" will not match the actual situation.

[0099] For example, in an objective and real situation, after a processor (a physical object) is produced according to the designed processor circuit structure and an operating system is run on the produced processor and such software is run on the operating system, the operating system cannot support such software to run normally according to the expected requirements (for example, it cannot meet the requirement of a short time spent on reading and writing on a real hard disk, etc.). That is, the produced processor cannot meet the needs of such software, and cannot support such software to run normally according to the expected requirements, and thus cannot provide normal data services to the outside world.

[0100] However, the test results show that the virtual processor generated according to the circuit structure of the designed processor can support the normal operation of such software according to the expected requirements (for example, it can meet the requirement of short reading and writing time of the virtual hard disk, etc.).

[0101] It can be seen that incorrect test results, or test results that do not match the actual situation, will affect the subsequent normal provision of data services by such software.

[0102] To this end, in order to improve the accuracy of the test results, or to make the test results consistent with the actual situation as much as possible, so as to avoid affecting the subsequent normal external data service provision of such software as much as possible, the situation of such software accessing the virtual hard disk simulated in the operating system can be made as close as possible to, or even the same as, the situation of such software accessing the real hard disk. For example, the test results of "whether the virtual processor can support the normal operation of such software according to the expected requirements" can be made consistent with the actual situation as much as possible.

[0103] For example, it is possible to ensure that when the test result is "the virtual processor can support the normal operation of this type of software as expected", after a processor (physical object) is produced according to the designed circuit structure of the processor and an operating system is run on the produced processor and this type of software is run on the operating system, the produced processor (physical object) in the operating system can also support the normal operation of this type of software as expected.

[0104] In order to make the situation when such software accesses the virtual hard disk simulated in the operating system as close as possible to, or even identical to, the situation when such software accesses the real hard disk, the IO bandwidth and IO latency of the virtual hard disk simulated in the operating system can be made as close as possible to, or even identical to, the IO bandwidth and IO latency of the real hard disk.

[0105] In order to make the IO bandwidth and IO latency of the virtual hard disk simulated in the operating system as close as possible to, or even identical to, the IO bandwidth and IO latency of the real hard disk, the solution of the present application is proposed.

[0106] See also Figure 1 , shows a schematic diagram of an application scenario of the present application, including an electronic device, the electronic device may include a terminal or a server, the server may include a physical server or a virtual server, etc., the virtual server may include a virtual machine, etc., the virtual machine may include an ECS (Elastic Cloud Server), etc.

[0107] The electronic device runs a virtual processor, and the virtual processor runs an operating system. The operating system at least has a simulated virtual hard disk, and of course, can also simulate components such as memory, which is not limited in this application.

[0108] The virtual processor may be generated based on a pre-silicon test platform according to the circuit structure of the designed processor.

[0109] The virtual hard disk may be virtualized based on memory using a specific tool, and the specific tool may include null bik and / or ramdisk.

[0110] Software can be installed and run in the operating system so that the software runs on a virtual processor.

[0111] The virtual hard disk has the basic hardware parameters of a real hard disk, such as the hard disk capacity, hard disk rotation speed, hard disk sector number, queue capacity / depth of the MQ queue in the hard disk, and hard disk sector size, etc.

[0112] The software may include testing software and / or the aforementioned software with relatively complex functions and relatively complex internal logic, as well as software capable of providing various services.

[0113] See also Figure 2 , shows a pre-silicon testing method of the present application, which is applied to Figure 1 In the virtual processor shown, the method may include:

[0114] In step S101 , when an access request submitted by software to a virtual hard disk is scheduled to be processed by the virtual hard disk and an indication indicating that the processing of the access request is completed is received from the virtual hard disk, the access request is stored in a first queue.

[0115] The access requests stored in the first queue are access requests that have been processed.

[0116] In the present application, the software contains instructions for accessing the hard disk. When the instructions for accessing the hard disk are executed, there is no real hard disk at this time, but a virtual hard disk is simulated in the operating system. In this way, an access request to the virtual hard disk can be generated and submitted to the virtual processor. The virtual processor obtains the access request to the virtual hard disk submitted by the software, and then dispatches the access request to the virtual hard disk to the virtual hard disk for processing. After the virtual hard disk completes processing the access request, it returns an indication to the virtual processor indicating that the processing of the access request has been completed. After obtaining the indication indicating that the processing of the access request has been completed, the virtual processor can obtain the processing result of the access request according to the indication indicating that the processing of the access request has been completed (for example, the processing result of the access request is carried in the indication indicating that the processing of the access request has been completed, etc.), and then the relevant information of the processing result of the access request can be added to the access request, and the access request can be stored in a first queue. The first queue can be maintained by the virtual processor.

[0117] Among them, the relevant information of the processing result may include the processing result of the access request, or, if the processing result of the access request is not located in the access request but is located at another location, the relevant information of the processing result may include indication information for indicating the location of the processing result of the access request (such as the "other location" mentioned above).

[0118] The access request may include an IO request, etc.

[0119] In step S102, the actual processing capability parameters of the hard disk are obtained.

[0120] In one embodiment of the present application, the processing capacity parameters of the real hard disk include at least the target amount of data that the real hard disk can process per unit time and the target time taken by the real hard disk to process an access request.

[0121] The target data volume that a real hard disk can process within a unit time may include a maximum data volume that a real hard disk can process within a unit time.

[0122] The target time taken for the actual hard disk to process the access request may include the shortest time taken for the actual hard disk to process the access request.

[0123] Real hard disks include manufactured hard disks (physical objects).

[0124] The unit duration can be determined according to actual conditions, for example, 50ms (milliseconds), 100ms, 150ms or 200ms, etc., and this application does not impose any limitation on this.

[0125] The target amount of data a real hard drive can process per unit time can be understood as the real hard drive's bandwidth. This refers to the target amount of data a real hard drive can read per unit time, the target amount of data a real hard drive can write per unit time, or the target amount of data a real hard drive can "write + read" per unit time. A read action is a read action on a real hard drive, and a write action is a write action on a real hard drive.

[0126] The target time taken by a real hard disk to process an access request can be understood as: the target time taken by a real hard disk in the process of processing each access request in a scenario where a large number of access requests are processed, or the average time taken by a real hard disk in the process of processing each access request in a scenario where a large number of access requests are processed (as the target time taken by the real hard disk to process access requests).

[0127] In step S103, an access request to be released is selected in the first queue according to the actual processing capability parameter of the hard disk.

[0128] In the present application, step S103 may be performed with a unit time length as the polling period. The specific value of the unit time length may be determined according to actual conditions and is not limited in the present application.

[0129] In one embodiment of the present application, access requests to be released can be selected from the access requests stored in the first queue based on the target data volume and the target time duration, the total amount of data involved in the access requests to be released is less than or equal to the target data volume, and the duration between the time when the access requests to be released are scheduled to the virtual hard disk and the current time is greater than or equal to the target time duration.

[0130] There may be one access request to be released or two or more. If there is one access request to be released, the amount of data involved in the one access request to be released is less than or equal to the target data amount. Alternatively, if there are two or more access requests to be released, the total amount of data involved in the two or more access requests to be released is less than or equal to the target data amount.

[0131] The current time may be the current time of the electronic device, or the current time of the operating system. The current time of the electronic device or the current time of the operating system is respectively the same as the universal time.

[0132] The first queue stores access requests that have been processed by the virtual hard disk but have not yet been returned to the software. The access requests that have been processed by the virtual hard disk may carry information related to the processing results of the access requests.

[0133] In the present application, each access request involves a data volume, and the data volumes involved in different access requests are not all the same or completely different.

[0134] The amount of data involved in an access request can be understood as: the amount of data that the hard disk needs to process within a unit time for the access request, for example, the amount of data that the hard disk needs to read within a unit time for the access request, or the amount of data that the hard disk needs to write within a unit time for the access request, or the amount of data that the hard disk needs to "write + read" within a unit time for the access request.

[0135] In step S104, the access request to be released is returned to the software.

[0136] Furthermore, after returning the access request to be released to the software, there is no need to return the access request to be released to the software again. In this way, the access request to be released stored in the first queue will no longer be effective. In this way, in order to save storage space, the access request to be released can be deleted from the first queue.

[0137] Through this application, by simulating the bottleneck of a real hard disk, the processing power of the virtual hard disk simulated in the operating system is made as close as possible to the processing power of the real hard disk, and the test scenario is made as close as possible to the real scenario, so that the situation in which the software accesses the virtual hard disk simulated in the operating system is made as close as possible to the situation in which the software accesses the real hard disk. For example, the test result of "whether the virtual processor can support the normal operation of the software according to the expected requirements" is made as close as possible to the real situation.

[0138] For example, in an objective and real situation, after a processor (a physical object) is produced according to the designed processor circuit structure and an operating system is run on the produced processor and software is run on the operating system, the operating system cannot support the normal operation of the software according to the expected requirements (for example, it cannot meet the requirement of a short time spent on reading and writing on a real hard disk, etc.). That is, the produced processor cannot meet the requirements of the software, and the produced processor cannot support the normal operation of the software according to the expected requirements, and thus cannot provide normal data services to the outside world.

[0139] Correspondingly, the test results obtained through the solution of this application are also: the virtual processor generated according to the circuit structure of the designed processor cannot support the normal operation of the software according to the expected requirements (for example, it cannot meet the requirement of short time consumption for reading and writing the virtual hard disk, etc.).

[0140] It can be seen that through this application, the accuracy of the test results can be improved, or the test results can be made as consistent as possible with the actual situation, thereby avoiding affecting the normal provision of data services to the outside world by subsequent software as much as possible.

[0141] For example, the processing capacity of the virtual hard disk simulated in the operating system is as close as possible to the processing capacity of the real hard disk, which can be understood as: the target amount of data that the virtual hard disk can process per unit time and the target time it takes for the virtual hard disk to process an access request are as close as possible to the target amount of data that the real hard disk can process per unit time and the target time it takes for the real hard disk to process an access request.

[0142] In real scenarios with real processors and real hard disks, the actions executed by the real processor and the actions of the real hard disk in processing access requests are often asynchronous. Thus, after the real processor dispatches the access request to the real hard disk, the real processor often continues to execute other actions.

[0143] Secondly, after the real hard disk completes processing the request and obtains the processing result, the real hard disk can return the access request to the real processor. At this time, the access request will carry relevant information about the processing result of the access request. For example, the relevant information about the processing result may include the processing result of the access request, or, the processing result of the access request is not located in the access request, but is located at other locations. The relevant information about the processing result may include indication information for indicating the location of the processing result of the access request (such as the "other location" mentioned above).

[0144] Generally, after the real processor receives the access request returned by the real hard disk, it is often necessary to promptly return the access request to the software so that the software can obtain the processing result of the access request in a timely manner.

[0145] However, when the real processor receives the access request returned by the hard disk, the real processor is often executing other actions. In view of this, in order to return the access request to the software in a timely manner, it is necessary to trigger the interrupt mechanism of the real processor so that the real processor interrupts the execution of other actions and then returns the access request to the software. For example, the real processor records the status of other actions currently being executed, and after the recording is completed, it executes the action of returning the access request to the software, and then continues to execute other actions.

[0146] It is clear that the process of the real processor executing the interrupt action before executing the action of returning the access request to the software will take a long time. For example, the process of the real processor recording the status of other actions currently being executed will take a long time, thereby delaying the timing of the real processor returning the access request to the software, and further delaying the moment when the software receives the access request returned by the real processor.

[0147] In the test scenario of the virtual processor and the virtual hard disk, the virtual hard disk is obtained based on memory simulation. Access to the virtual hard disk can almost be regarded as access to the memory. Access to the memory is synchronous access, not asynchronous access. Therefore, access to the memory does not involve interruption matters, and access to the virtual hard disk does not involve interruption matters, and will not cause delays caused by interruptions, thereby not delaying the timing of the virtual processor returning the access request to the software, and thus not delaying the moment when the software receives the access request returned by the virtual processor. It can be seen that the test situation is inconsistent with the actual situation, resulting in inaccurate test results.

[0148] In view of this, in the virtual hard disk solution of the present application, interruption events can be introduced to make the test situation as close to the real situation as possible, so as to improve the accuracy of the test results as much as possible.

[0149] For example, in another embodiment of the present application, after the virtual processor dispatches the access request to the virtual hard disk and the virtual hard disk completes the processing of the access request and obtains the processing result, the virtual hard disk can return an indication to the virtual processor indicating that the processing of the access request has been completed. When the virtual processor receives the indication returned by the virtual hard disk indicating that the processing of the access request has been completed, an interrupt signal can be generated (for example, an interrupt signal can be generated using a core-based interrupt mechanism, or an interrupt signal can be generated using a message-based interrupt mechanism, etc.), for example, an interrupt signal is generated asynchronously, and then the interrupt signal is responded to (the priority of the action executed in response to the interrupt signal is greater than the priority of the action currently being executed by the virtual processor), the interrupt signal carries the function name of the interrupt handling function, and the interrupt handling function can be called by the function name of the interrupt handling function to interrupt the action currently being executed by the virtual processor and record the status of the action currently being executed. Secondly, after the virtual processor completes the response to the interrupt signal, the access request is returned to the software, and then the action currently being executed is continued according to the recorded status of the action currently being executed.

[0150] In another embodiment of the present application, the virtual processor includes multiple processor cores, at least two of the multiple processor cores respectively run an operating system, and the at least two processor cores include a first processor core and a second processor core; software runs on the operating system run by the first processor core; the number of first processor cores may be one or more.

[0151] In one example, the first processor core that performs the action of "scheduling the access request submitted by the software to the virtual hard disk to the virtual hard disk for processing", the first processor core that performs the action of "receiving the indication returned by the virtual hard disk to indicate that the access request has been processed", the first processor core that performs the action of "generating an interrupt signal", the first processor core that performs the action of "responding to an interrupt signal", and the first processor core that performs the action of "returning the access request to be released to the software" can be the same processor core, that is, the interrupt mechanism used in this example is an intra-processor core interrupt.

[0152] In another example, the first processor core that performs the action of "scheduling the access request to the virtual hard disk submitted by the software to the virtual hard disk processing", the first processor core that performs the action of "receiving the indication returned by the virtual hard disk to indicate that the access request has been processed", and the first processor core that performs the action of "generating an interrupt signal" can be the same processor core, for example, processor core A.

[0153] The first processor core that performs the action of "responding to the interrupt signal" and the first processor core that performs the action of "returning the access request to be released to the software" can be the same processor core, for example, processor core B.

[0154] Processor core A and processor core B are different processor cores, and after processor core A "generates an interrupt signal", processor core A will send an interrupt signal to processor core B.

[0155] It can be seen that the interrupt mechanism used in this example is an inter-processor core interrupt.

[0156] In another example, the virtual processor includes multiple processor cores, at least two of the multiple processor cores respectively run an operating system, and the at least two processor cores include a first processor core and a second processor core; the operating system run by the first processor core runs software; the operating system run by the second processor core does not run software; access requests processed by the virtual hard disk are stored in a first queue maintained by the second processor core.

[0157] Regarding interrupts, after the second processor core selects the access request to be released from the access requests in the first queue, it can generate an interrupt signal that carries at least the access request to be released. The second processor core can then send the interrupt signal to the first processor core. The first processor core receives the interrupt signal and responds to it. For example, the interrupt signal also carries the name of an interrupt handler function. The first processor core can call the interrupt handler function using the name to interrupt the action currently being executed by the first processor core and record the status of the action being executed. After responding to the interrupt signal, the first processor core returns at least the access request to be released carried by the interrupt signal to the software.

[0158] In one example, the first processor core that performs the action of "scheduling the access request submitted by the software to the virtual hard disk to the virtual hard disk for processing" and the first processor core that performs the action of "receiving the indication returned by the virtual hard disk indicating that the access request has been processed" can be the same processor core, for example, processor core A.

[0159] The second processor core that performs the action of "generating an interrupt signal" is processor core B.

[0160] The first processor core that performs the action of "responding to the interrupt signal" and the first processor core that performs the action of "returning the access request to be released to the software" can be the same processor core, for example, processor core C.

[0161] Processor core A and processor core C may be the same processor core, or may not be the same processor core.

[0162] Processor core B and processor core A are not the same processor core, and processor core B and processor core C are not the same processor core.

[0163] After processor core A “receives the indication returned by the virtual hard disk indicating completion of processing the access request,” processor core A sends an access request to processor core B.

[0164] After the processor core B "generates an interrupt signal", the processor core B will send an interrupt signal to the processor core C. The interrupt signal carries at least an access request to be released.

[0165] It can be seen that the interrupt mechanism used in this example is an inter-processor core interrupt.

[0166] In one embodiment of the present application, see Figure 3 , based on the target data volume and the target time duration, the process of selecting the access request to be released in the first queue may include:

[0167] In step S201 , at least one access request is searched in a first queue for which the duration between the time when the request was scheduled to the virtual hard disk and the current time is greater than or equal to the target duration.

[0168] For any access request, before being processed by the virtual hard disk, the virtual processor will dispatch the access request to the virtual hard disk, and then the virtual hard disk will process the access request. When the virtual processor dispatches the access request to the virtual hard disk, it will record the time when the access request is dispatched to the virtual hard disk and establish an association relationship between the time and the access request.

[0169] In this way, in this step, for any access request stored in the first queue, the moment when the access request is scheduled to the virtual hard disk can be obtained based on the established association relationship, and then it is determined whether the duration between the moment when the access request is scheduled to the virtual hard disk and the current moment is greater than or equal to the target time duration.

[0170] In the case that the duration between the time when the access request is scheduled to the virtual hard disk and the current time is greater than or equal to the target time duration, the access request can be regarded as the “at least one access request” mentioned above.

[0171] Alternatively, when the duration between the time when the access request is scheduled to the virtual hard disk and the current time is less than the target time duration, the access request will not be regarded as the "at least one access request" mentioned above, and the process of the access request can be terminated.

[0172] The same is done for each of the other access requests stored in the first queue.

[0173] In step S202 , it is determined whether the sum of the data volume involved in at least one access request is less than or equal to the target data volume.

[0174] There are two branches after this step, for example, the branch of step S203 and the branch of step S204.

[0175] In the case that the at least one access request is one access request, the amount of data involved in the one access request may be taken as the sum of the amount of data involved in the at least one access request.

[0176] Alternatively, in the case where at least one access request is more than two access requests, the data amounts involved in the more than two access requests can be summed to obtain the total data amounts involved in the more than two access requests, and the total data amounts involved can be used as the total data amounts involved in the at least one access request.

[0177] When the total amount of data involved in at least one access request is less than or equal to the target data amount, in step S203 , all of the at least one access request are selected as access requests to be released.

[0178] When the sum of the data amounts involved in at least one access request is less than or equal to the target data amount, it means that the sum of the data amounts involved in all access requests in the at least one access request does not exceed the target data amount that the real hard disk can process within a unit time, that is, it does not exceed the processing capacity of the real hard disk. In this way, all access requests in the at least one access request can be selected as access requests to be released.

[0179] In the case that the total amount of data involved in at least one access request is greater than the target data amount, in step S204, some access requests from the at least one access request are selected, and the total amount of data involved in the some access requests is less than or equal to the target data amount, and the some access requests are selected as access requests to be released.

[0180] In the case where the sum of the amounts of data involved in at least one access request is greater than the target data amount, it means that the sum of the amounts of data involved in all access requests in the at least one access request exceeds the target data amount that the real hard disk can process within a unit time, that is, exceeds the processing capacity of the real hard disk. In this way, not all access requests in the at least one access request may be selected as access requests to be released, and some access requests in the at least one access request may be selected as access requests to be released. For example, some access requests in the at least one access request whose sum of the amounts of data involved is less than or equal to the target data amount may be selected, and the selected some access requests may be selected as access requests to be released.

[0181] In one embodiment, when selecting some of the at least one access request, some of the at least one access request can be selected in descending order of the duration between the time when they were scheduled to the virtual hard disk and the current time, so as to make the test situation closer to the real situation.

[0182] exist Figure 1 Based on the application scenario shown, in one embodiment of the present application, see Figure 4 , shows a schematic diagram of another application scenario, wherein the virtual processor includes multiple processor cores, at least two of the multiple processor cores respectively run an operating system, and the at least two processor cores include a first processor core and a second processor core; software runs on the operating system run by the first processor core, the first processor is part of the multiple processor cores included in the virtual processor, and there is one first processor, or there are multiple first processors.

[0183] Figure 4 The processor core 0, processor core 1, processor core 2 and processor core 3 are included.

[0184] Processor core 0, processor core 1, and processor core 2 are first processor cores, and software runs on operating systems running on processor core 0, processor core 1, and processor core 2, respectively.

[0185] Processor core 3 is a second processor core, and no software is running on the operating system running on processor core 3 .

[0186] Thus, in another embodiment of the present application, see Figure 5 , step S101 includes:

[0187] In step S301, after the first processor core schedules the access request to the virtual hard disk submitted by the software to the virtual hard disk for processing and receives an indication returned by the virtual hard disk indicating that the access request has been processed, the first processor core passes the access request to the second processor core among the multiple processor cores, and the operating system running on the second processor core does not run the software.

[0188] In step S302 , the second processor core stores the access request in the first queue.

[0189] The first queue may be maintained by the second processor core. For example, a polling process is started in the second processor core, and the first queue is maintained by the polling process in the second processor core.

[0190] Accordingly, steps S102 to S104 may be executed by the second processor core. For example, the second processor core obtains the processing capability parameters of the real hard disk; selects the access request to be released in the first queue according to the processing capability parameters of the real hard disk; and returns the access request to be released to the software.

[0191] In the real scenario of a real processor and a real hard disk, the real processor and the real hard disk are independent components. The software runs on the operating system run by the real processor, not on the real hard disk. That is, since the real processor runs the operating system and the operating system runs the software, the resources in the real processor serve the operation of the software, not the real hard disk.

[0192] For example, the software runs on an operating system running on a portion of processor cores in a real processor, and all resources in the portion of processor cores serve the running of the software rather than the real hard disk.

[0193] The processing capacity parameters of a real hard disk are determined by the characteristics of the real hard disk itself. For example, the target amount of data that the real hard disk can process per unit time and the target time it takes for the real hard disk to process an access request are determined by the characteristics of the real hard disk itself. After the real processor dispatches the access request to the real hard disk to the real hard disk, it is the real hard disk that processes the access request and returns the processing result to the real processor.

[0194] Among them, the duration from "the real processor dispatches the access request to the real hard disk" to "the real processor obtains the processing result returned by the real hard disk" is determined by the characteristics of the real hard disk itself, not by the real processor. In addition, the process from "the real processor dispatches the access request to the real hard disk" to "the real processor obtains the processing result returned by the real hard disk" does not consume the resources of the real processor, and thus does not affect the real processor from running the software (the software runs on the operating system run by the real processor, and the real processor provides resources for the software, which can be regarded as the processor indirectly running the software), and does not affect the performance of the software.

[0195] For example, the real processor or a part of the processor cores in the real processor that run the software does not execute the process of steps S102 to S104, for example, it does not execute the process of "obtaining the processing capacity parameters of the real hard disk; selecting the access request to be released in the first queue according to the processing capacity parameters of the real hard disk; returning the access request to be released to the software". Therefore, the real processor or a part of the processor cores in the real processor that run the software will not consume the resources required to execute the process of steps S102 to S104.

[0196] However, in the solution of the present application, in the test scenario of a virtual processor and a virtual hard disk, the software runs on the operating system running on the virtual processor. For example, the software runs on the operating system running on a part of the processor cores in the virtual processor. Since the operating system runs on this part of the processor cores and the operating system runs the software, all the resources in this part of the processor cores serve the operation of the software.

[0197] In the solution of the present application, the virtual processor needs to execute the process of step S102 to step S104 , and therefore, the virtual processor consumes resources required for executing the process of step S102 to step S104 .

[0198] For example, if the processor core in the virtual processor that runs the software (the software runs on the operating system run by the processor core in the virtual processor, and the processor core in the virtual processor provides resources for the software, which can be regarded as the processor core in the virtual processor indirectly running the software) is the same as the processor core that executes the process of steps S102 to S104, that is, if the processor core that runs the software is used to execute the process of steps S102 to S104, then since the execution of the process of steps S102 to S104 requires some resources, part of the resources in the processor core that runs the software cannot be used to run the software, resulting in reduced software performance, which in turn causes the test results to be far from the actual situation and the test results to be inaccurate.

[0199] Therefore, in order to avoid the above-mentioned problems, in another embodiment of the present application, the operating system running on the first processor core in the virtual processor runs the software, and the operating system running on the second processor core in the virtual processor does not run the software. The second processor core in the virtual processor executes the process of steps S102 to S104, so that all resources in the first processor core running the software can be used to run the software, and the second processor core that is not running the software is used to control the release of access requests to avoid reducing the performance of the software, so as to make the test results as close to the actual situation as possible and improve the accuracy of the test.

[0200] In another embodiment of the present application, at least two processor cores among the multiple processor cores respectively run an operating system, and the at least two processor cores include a first processor core and a second processor core; the operating system run by the first processor core runs software, and the operating system run by the second processor core does not run software; access requests processed by the virtual hard disk are stored in a first queue maintained by the second processor core.

[0201] With respect to interrupts, after the second processor core selects an access request to be released from the access requests in the first queue, it can generate an interrupt signal, which carries at least the access request to be released. The second processor core can then send the interrupt signal to the first processor core. The first processor core receives the interrupt signal and responds to it. For example, the interrupt signal also carries the name of an interrupt handler function. The first processor core can call the interrupt handler function using the name of the interrupt handler function to interrupt the action currently being executed by the first processor core and record the status of the action currently being executed. Secondly, after responding to the interrupt signal, the first processor core returns at least the access request to be released carried by the interrupt signal to the software.

[0202] In one example, the first processor core that performs the action of "scheduling the access request submitted by the software to the virtual hard disk to the virtual hard disk for processing" and the first processor core that performs the action of "receiving the indication returned by the virtual hard disk indicating that the access request has been processed" can be the same processor core, for example, processor core A.

[0203] The second processor core that performs the action of "generating an interrupt signal" is processor core B.

[0204] The first processor core that performs the action of "responding to the interrupt signal" and the first processor core that performs the action of "returning the access request to be released to the software" can be the same processor core, for example, processor core C.

[0205] Processor core A and processor core C may be the same processor core, or may not be the same processor core.

[0206] Processor core B and processor core A are not the same processor core, and processor core B and processor core C are not the same processor core.

[0207] After processor core A "receives the indication returned by the virtual hard disk indicating that the processing of the access request is complete", processor core A will send an access request to processor core B.

[0208] After processor core B "generates an interrupt signal", processor core B will send an interrupt signal to processor core C.

[0209] It can be seen that the interrupt mechanism used in this example is an inter-processor core interrupt.

[0210] In one example, the second processor core generates an interrupt signal that carries the function name of an IPI interrupt callback function and the processed access request. The second processor core then sends the interrupt signal to the first processor core. The first processor core calls the IPI interrupt callback function based on the function name of the IPI interrupt callback function in the interrupt signal, performs interrupt-related actions to respond to the interrupt signal, and then returns the processed access request to the software.

[0211] In one embodiment, the first processor core that performs the action of "responding to an interrupt signal" may be a specific first processor core among multiple first processor cores, a first processor core specifically used for processing interrupts, and the like.

[0212] When executing step S102 to obtain the processing capacity parameters of the real hard disk, in one embodiment of the present application, the processing capacity parameters of the real hard disk can be tested in real time. For example, the processing capacity of the real hard disk is stress-tested based on FIO to obtain the processing capacity parameters of the real hard disk.

[0213] Alternatively, in another embodiment of the present application, in order to improve the efficiency of obtaining the processing capacity parameters of the real hard disk, the processing capacity parameters of the real hard disk can be tested in advance, and the processing capacity parameters of the real hard disk obtained by the test can be stored. In this way, in the present application, the stored processing capacity parameters of the real hard disk can be obtained, and real-time testing is no longer required, saving the time consumed in the real-time testing process to improve efficiency.

[0214] In one possible case, there are various models of real hard disks on the market, and the processing capacity parameters of real hard disks of different models are not all the same or are completely different.

[0215] A real hard disk has a model. A virtual hard disk is simulated for a certain model of a real hard disk. Thus, the virtual hard disk also has a model. In this scenario, the model of the real hard disk is the same as the model of the simulated virtual hard disk.

[0216] The processing capability parameters of real hard disks of various models may be tested in advance, and the tested processing capability parameters of real hard disks of various models may be stored.

[0217] In this way, when obtaining the processing power parameters of the stored real hard disk, the model of the virtual hard disk simulated in the operating system can be obtained, and then the processing power parameters of the stored real hard disk can be obtained based on the model. The processing power parameters of the stored real hard disk are obtained after testing the real hard disk of the model in advance.

[0218] For example, for any model of real hard disk on the market, the model and the processing capacity parameters of the real hard disk corresponding to the model obtained through testing can be combined into a corresponding table item and stored in the correspondence between the model of the real hard disk and the processing capacity parameters of the real hard disk. The same is true for every other model of real hard disk on the market.

[0219] In this way, when obtaining the stored processing power parameters of the real hard disk according to the model, the processing power parameters of the real hard disk corresponding to the model can be found in the correspondence between the model of the real hard disk and the processing power parameters of the real hard disk, and used as the processing power parameters of the real hard disk of the model.

[0220] For example, in one example, when obtaining the target amount of data that a real hard disk can process per unit time and the target time it takes for the real hard disk to process an access request, in one embodiment of the present application, the target amount of data that the real hard disk can process per unit time and the target time it takes for the real hard disk to process an access request can be tested in real time. For example, based on FIO, a stress test of the processing capacity of the real hard disk is performed to obtain the target amount of data that the real hard disk can process per unit time and the target time it takes for the real hard disk to process an access request.

[0221] Alternatively, in another embodiment, in order to improve the efficiency of obtaining the target amount of data that a real hard disk can process within a unit time and the target time it takes for the real hard disk to process an access request, the target amount of data that a real hard disk can process within a unit time and the target time it takes for the real hard disk to process an access request can be tested in advance, and the target amount of data that the real hard disk can process within a unit time and the target time it takes for the real hard disk to process an access request obtained by the test can be stored. In this way, in the present application, the stored target amount of data and the stored target time it takes can be obtained. The stored target amount of data and the stored target time it takes are obtained after testing the real hard disk in advance, and real-time testing is no longer required, saving the time consumed in the real-time testing process to improve efficiency.

[0222] Among them, in one possible case, there are various models of real hard disks on the market, and the target data volume that can be processed by real hard disks of different models per unit time is not all the same or completely different, and the target time taken by real hard disks of different models to process access requests is not all the same or completely different.

[0223] A real hard disk has a model. A virtual hard disk is simulated for a certain model of a real hard disk. Thus, the virtual hard disk also has a model. In this scenario, the model of the real hard disk is the same as the model of the simulated virtual hard disk.

[0224] The target amount of data that each model of real hard disk can process within a unit time and the target time it takes for each model of real hard disk to process an access request can be tested in advance, and the target amount of data that each model of real hard disk can process within a unit time and the target time it takes for each model of real hard disk to process an access request can be stored.

[0225] In this way, when obtaining the target amount of stored data and the target time consumed for storage, the model of the virtual hard disk simulated in the operating system can be obtained, and then the target amount of stored data and the target time consumed for storage can be obtained based on the model. The target amount of stored data is obtained after testing the real hard disk of this model in advance, and the target time consumed for storage is obtained after testing the real hard disk of this model in advance.

[0226] For example, for any model of real hard disk on the market, the model, the target amount of data that the real hard disk corresponding to the model can process per unit time obtained by testing, and the target time taken by the real hard disk corresponding to the model to process an access request obtained by testing can be combined into a corresponding table entry and stored in the correspondence between the model of the real hard disk, the target amount of data that the real hard disk can process per unit time, and the target time taken by the real hard disk to process an access request. The same is true for every other model of real hard disk on the market.

[0227] In this way, when obtaining the stored target data volume and the stored target time duration based on the model, the target data volume and target time duration corresponding to the model can be found in the correspondence between the real hard disk model, the target data volume that the real hard disk can process within a unit time duration, and the target time duration for the real hard disk to process an access request, and they can be used as the target data volume that the real hard disk of this model can process within a unit time duration and the target time duration for the real hard disk of this model to process an access request.

[0228] In another embodiment of the present application, in a real scenario of a real processor and a real hard disk, the real processor schedules the access request to the real hard disk through the real hard disk driver. For example, after the real processor submits the access request to the real hard disk driver, the queue manager in the real hard disk driver will add the access request to the MQ queue (Multi-Queue, block device multi-queue), and then the scheduler in the real hard disk driver will schedule the access request that needs to be scheduled in the MQ queue to the real hard disk for processing.

[0229] However, after an access request enters the MQ queue, it is sometimes not immediately extracted from the MQ queue and dispatched to the real hard disk. It can be seen that it takes a period of time for the access request to be "added to the MQ queue" and "extracted from the MQ queue and dispatched to the real hard disk", which delays the timing of the access request being dispatched to the real hard disk, and further delays the time when the real hard disk processes the access request.

[0230] In the test scenarios of virtual processors and virtual hard disks, the virtual hard disk is obtained based on memory simulation. Access to the virtual hard disk can almost be regarded as access to the memory. Access to the memory is synchronous access, not asynchronous access. Therefore, access to the memory does not involve matters of the MQ queue, and access to the virtual hard disk does not involve matters of the MQ queue. It will not cause delays caused by the MQ queue, and will not delay the timing of the access request being dispatched to the virtual hard disk, and will not delay the moment when the virtual hard disk processes the access request, so that the test situation is inconsistent with the actual situation, resulting in inaccurate test results.

[0231] In view of this, in the virtual hard disk solution of the present application, an MQ queue can be introduced to make the test situation as close to the real situation as possible, so as to improve the accuracy of the test results as much as possible.

[0232] For example, in another embodiment of the present application, the virtual processor may generate a second queue in advance, and the second queue may include an MQ queue for storing access requests that are not scheduled to the virtual hard disk.

[0233] When the virtual processor receives an access request to the virtual hard disk submitted by the software, the virtual processor can first store the access request in the second queue, and then extract the access request that needs to be dispatched to the virtual hard disk from the access requests stored in the second queue (the extraction strategy can be based on the extraction strategy in the MQ queue in the real hard disk, etc., and this application does not limit the specific extraction strategy), and dispatch the extracted access request to the virtual hard disk for processing, so as to simulate the bottleneck of the MQ queue in the real hard disk.

[0234] Alternatively, in another embodiment of the present application, a virtual hard disk can be simulated based on null blk. Null blk itself has an MQ queue mechanism. In this way, the virtual hard disk simulated based on null blk also has an MQ queue mechanism, and the MQ queue can be the same as that of a real hard disk.

[0235] In this way, when the virtual processor receives an access request to the virtual hard disk submitted by the software, the virtual hard disk will not immediately dispatch the access request to the virtual hard disk to the virtual hard disk for processing. Instead, the access request to the virtual hard disk will be stored in the MQ queue first, and then the access request to be processed will be extracted from the access requests stored in the MQ queue (the extraction strategy can be based on the extraction strategy in the MQ queue in the real hard disk, etc.), and the extracted access request will be dispatched to the virtual hard disk for processing, so as to simulate the bottleneck of the MQ queue in the real hard disk.

[0236] Among them, see Figure 6, a schematic diagram is used to illustrate the solution of the present application, but it does not limit the scope of protection of the solution of the present application. The virtual processor includes processor core 0, processor core 1, processor core 2 and processor core 3, and operating systems are respectively run on processor core 0, processor core 1 and processor core 2, and software is respectively run on the operating systems respectively run on processor core 0, processor core 1 and processor core 2. Processor core 2 is a processor core that specializes in processing interrupts, that is, processor core 2 is an interrupt binding core. The operating system running on processor core 3 does not run software. Processor core 3 maintains a first queue for storing processed access requests. The interaction process between processor core 0, processor core 1, processor core 2 and processor core 3 can be found in Figure 6 shown.

[0237] It should be noted that for the method embodiments, for simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all optional embodiments, and the actions involved are not necessarily required by this application.

[0238] Reference Figure 7 , showing a structural block diagram of a pre-silicon test device of the present application, a virtual processor is running on the electronic device, an operating system is running on the virtual processor, the operating system has a simulated virtual hard disk, software is running on the operating system, the device is applied to the virtual processor, and the device includes: a storage module 11, which is used to store the access request to the virtual hard disk submitted by the software in a first queue when scheduling the access request to the virtual hard disk to the virtual hard disk for processing and receiving an indication returned by the virtual hard disk indicating that the access request has been processed; the access request stored in the first queue is the access request that has been processed; an acquisition module 12, which is used to obtain the processing capacity parameters of the real hard disk; a selection module 13, which is used to select the access request to be released in the first queue according to the processing capacity parameters of the real hard disk; a first return module 14, which is used to return the access request to be released to the software.

[0239] Among them, the processing capacity parameters of the real hard disk include at least the target data volume that the real hard disk can process within a unit time and the target time duration for the real hard disk to process the access request; the selection module includes: a first selection unit, used to select the access requests to be released in the first queue according to the target data volume and the target time duration, the total amount of data involved in the access requests to be released is less than or equal to the target data volume, and the time duration between the moment when the access requests to be released are scheduled to the virtual hard disk and the current moment is greater than or equal to the target time duration.

[0240] Among them, the first selection unit includes: a search subunit, which is used to search in the first queue for at least one access request whose duration between the time when it is scheduled to the virtual hard disk and the current time is greater than or equal to the target time duration; a determination subunit, which is used to determine whether the sum of the data amounts involved in at least one access request is less than or equal to the target data amount; a first selection subunit, which is used to select all access requests in at least one access request as access requests to be released when the sum of the data amounts involved in at least one access request is less than or equal to the target data amount; or, a selection subunit, which is used to select part of the access requests in at least one access request when the sum of the data amounts involved in at least one access request is greater than the target data amount, and the sum of the data amounts involved in the part of the access requests is less than or equal to the target data amount, and a second selection subunit, which is used to select part of the access requests as access requests to be released.

[0241] The selection subunit is specifically configured to select part of the at least one access request in descending order of the time between the time when the request is scheduled to the virtual hard disk and the current time.

[0242] The device also includes: a second generation module, which is used to generate an interrupt signal after selecting the access request to be released in the first queue; a second response module, which is used to respond to the interrupt signal; and a first return module, which is also used to return the access request to be released to the software after responding to the interrupt signal.

[0243] Among them, the virtual processor includes multiple processor cores, at least two processor cores among the multiple processor cores respectively run an operating system, and the at least two processor cores include a first processor core and a second processor core; the operating system running on the first processor core runs software; the storage module includes: a transfer unit in the first processor core, which is used to transfer the access request submitted by the software to the virtual hard disk for processing, and when the first processor core schedules the access request to the virtual hard disk to the virtual hard disk for processing and receives an indication returned by the virtual hard disk indicating that the access request has been processed, the access request is transferred to the second processor core among the multiple processor cores, and the operating system running on the second processor core does not run the software; the storage unit in the second processor core is used to store the access request in the first queue; accordingly, the acquisition module includes: a first acquisition unit in the second processor core, which is used to obtain the processing capacity parameters of the real hard disk; the selection module includes: a second selection unit in the second processor core, which is used to select the access request to be released in the first queue according to the processing capacity parameters of the real hard disk; the first return module includes: a first return unit in the second processor core, which is used to return the access request to be released to the software.

[0244] Among them, the first return unit in the second processor core includes: a generating subunit in the second processor core, used to generate an interrupt signal, the interrupt signal carries the access request to be released and the function name of the interrupt handling function; a sending subunit in the second processor core, used to send an interrupt signal to the first processor core; a receiving subunit in the first processor core, used to receive the interrupt signal; a responding subunit in the first processor core, used to respond to the interrupt signal; and a return subunit in the first processor core, used to return the access request to be released to the software after responding to the interrupt signal.

[0245] The acquisition module includes: a second acquisition unit, which is used to acquire the stored processing capacity parameters of the real hard disk, and the stored processing capacity parameters of the real hard disk are obtained after testing the real hard disk in advance.

[0246] Among them, the second acquisition unit includes: a first acquisition sub-unit, used to obtain the model of the virtual hard disk simulated in the operating system; a second acquisition sub-unit, used to obtain the processing power parameters of the stored real hard disk based on the model, and the processing power parameters of the stored real hard disk are obtained after testing the real hard disk of the model in advance.

[0247] The second acquisition subunit is specifically configured to search for a processing capability parameter corresponding to the model of the real hard disk in the correspondence between the model of the real hard disk and the processing capability parameter of the real hard disk.

[0248] The device further includes: a deleting module, configured to delete the access request to be released from the first queue after returning the access request to be released to the software.

[0249] Through this application, by simulating the bottleneck of a real hard disk, the processing power of the virtual hard disk simulated in the operating system is made as close as possible to the processing power of the real hard disk, and the test scenario is made as close as possible to the real scenario, so that the situation in which the software accesses the virtual hard disk simulated in the operating system is made as close as possible to the situation in which the software accesses the real hard disk. For example, the test result of "whether the virtual processor can support the normal operation of the software according to the expected requirements" is made as close as possible to the real situation.

[0250] For example, in an objective and real situation, after a processor (a physical object) is produced according to the designed processor circuit structure and an operating system is run on the produced processor and software is run on the operating system, the operating system cannot support the normal operation of the software according to the expected requirements (for example, it cannot meet the requirement of a short time spent on reading and writing on a real hard disk, etc.). That is, the produced processor cannot meet the requirements of the software, and the produced processor cannot support the normal operation of the software according to the expected requirements, and thus cannot provide normal data services to the outside world.

[0251] Correspondingly, the test results obtained through the solution of this application are also: the virtual processor generated according to the circuit structure of the designed processor cannot support the normal operation of the software according to the expected requirements (for example, it cannot meet the requirement of short time consumption for reading and writing the virtual hard disk, etc.).

[0252] It can be seen that through this application, the accuracy of the test results can be improved, or the test results can be made as consistent as possible with the actual situation, thereby avoiding affecting the normal provision of data services to the outside world by subsequent software as much as possible.

[0253] Reference Figure 8 , showing a structural block diagram of a pre-silicon test device of the present application, a virtual processor is running on the electronic device, an operating system is running on the virtual processor, the operating system has a simulated virtual hard disk, software is running on the operating system, the device is applied to the virtual processor, and the device includes: a first generation module 21, which is used to dispatch an access request to the virtual hard disk submitted by the software to the virtual hard disk for processing, and generates an interrupt signal when receiving an indication returned by the virtual hard disk to indicate that the access request has been processed; a first response module 22, which is used to respond to the interrupt signal; a second return module 23, which is used to return the access request to the software after the interrupt signal is responded to.

[0254] Among them, the virtual processor includes multiple processor cores, at least two of the multiple processor cores respectively run operating systems, and the at least two processor cores include a first processor core and a second processor core; the operating system run by the first processor core runs software, and the operating system run by the second processor core does not run software; the access request is stored on the second processor core; the access request is transmitted to the second processor core when the first processor core receives an indication returned by the virtual hard disk indicating that the access request has been processed; the first generation module includes: a generation unit in the second processor core, for generating an interrupt signal, the interrupt signal carries the access request and the function name of the interrupt processing function; accordingly, the first response module includes: a sending unit in the second processor core, for sending an interrupt signal to the first processor core; a receiving unit in the first processor core, for receiving the interrupt signal; a response unit in the first processor core, for responding to the interrupt signal; accordingly, the second return module includes: a second return unit in the first processor core, for returning the access request to the software after responding to the interrupt signal.

[0255] Through this application, by simulating the bottleneck of a real hard disk, the processing power of the virtual hard disk simulated in the operating system is made as close as possible to the processing power of the real hard disk, and the test scenario is made as close as possible to the real scenario, so that the situation in which the software accesses the virtual hard disk simulated in the operating system is made as close as possible to the situation in which the software accesses the real hard disk. For example, the test result of "whether the virtual processor can support the normal operation of the software according to the expected requirements" is made as close as possible to the real situation.

[0256] For example, in an objective and real situation, after a processor (a physical object) is produced according to the designed processor circuit structure and an operating system is run on the produced processor and software is run on the operating system, the operating system cannot support the normal operation of the software according to the expected requirements (for example, it cannot meet the requirement of a short time spent on reading and writing on a real hard disk, etc.). That is, the produced processor cannot meet the requirements of the software, and the produced processor cannot support the normal operation of the software according to the expected requirements, and thus cannot provide normal data services to the outside world.

[0257] Correspondingly, the test results obtained through the solution of this application are also: the virtual processor generated according to the circuit structure of the designed processor cannot support the normal operation of the software according to the expected requirements (for example, it cannot meet the requirement of short time consumption for reading and writing the virtual hard disk, etc.).

[0258] It can be seen that through this application, the accuracy of the test results can be improved, or the test results can be made as consistent as possible with the actual situation, thereby avoiding affecting the normal provision of data services to the outside world by subsequent software as much as possible.

[0259] An embodiment of the present application further provides a non-volatile readable storage medium, which stores one or more modules (programs). When the one or more modules are applied to a device, the device can execute instructions (instructions) of each method step in the embodiment of the present application.

[0260] The present application provides one or more machine-readable media having instructions stored thereon, which, when executed by one or more processors, cause an electronic device to perform one or more of the methods described in the above embodiments. In the present application, the electronic device includes a server, a gateway, a sub-device, and the like, wherein the sub-device is an IoT device or other device.

[0261] The embodiments of the present disclosure may be implemented as an apparatus configured as desired using any appropriate hardware, firmware, software, or any combination thereof, which may include a server (cluster), terminal devices such as IoT devices, and other electronic devices.

[0262] Figure 9 An exemplary apparatus 1300 that can be used to implement various embodiments of the present application is schematically shown.

[0263] For one embodiment, Figure 9 An exemplary apparatus 1300 is shown having one or more processors 1302, a control module (chip set) 1304 coupled to at least one of the processor(s) 1302, a memory 1306 coupled to the control module 1304, a non-volatile memory (NVM) / storage device 1308 coupled to the control module 1304, one or more input / output devices 1310 coupled to the control module 1304, and a network interface 1312 coupled to the control module 1304.

[0264] The processor 1302 may include one or more single-core or multi-core processors, and the processor 1302 may include any combination of general-purpose processors or dedicated processors (e.g., graphics processors, application processors, baseband processors, etc.). In some embodiments, the apparatus 1300 can serve as a server device such as a gateway in the embodiments of the present application.

[0265] In some embodiments, the apparatus 1300 may include one or more computer-readable media (e.g., memory 1306 or NVM / storage 1308) having instructions 1314 and one or more processors 1302 configured in conjunction with the one or more computer-readable media to execute the instructions 1314 to implement a module to perform the actions of the present disclosure.

[0266] For one embodiment, the control module 1304 may include any suitable interface controller to provide any suitable interface to at least one of the processor(s) 1302 and / or any suitable device or component in communication with the control module 1304 .

[0267] The control module 1304 may include a memory controller module to provide an interface to the memory 1306. The memory controller module may be a hardware module, a software module, and / or a firmware module.

[0268] The memory 1306 can be used, for example, to load and store data and / or instructions 1314 for the device 1300. For one embodiment, the memory 1306 can include any suitable volatile memory, such as a suitable DRAM. In some embodiments, the memory 1306 can include double data rate quad synchronous dynamic random access memory (DDR4 SDRAM).

[0269] For one embodiment, control module 1304 may include one or more input / output controllers to provide interfaces to NVM / storage device 1308 and input / output device(s) 1310 .

[0270] For example, NVM / storage 1308 may be used to store data and / or instructions 1314. NVM / storage 1308 may include any suitable non-volatile memory (e.g., flash memory) and / or may include any suitable non-volatile storage device(s) (e.g., one or more hard disk drives (HDDs), one or more compact disk (CD) drives, and / or one or more digital versatile disk (DVD) drives).

[0271] NVM / storage device 1308 may include storage resources that are physically part of the device on which apparatus 1300 is installed, or it may be accessible to the device without being part of the device. For example, NVM / storage device 1308 may be accessible over a network via input / output device(s) 1310.

[0272] (One or more) input / output devices 1310 may provide an interface for apparatus 1300 to communicate with any other appropriate device. Input / output devices 1310 may include a communication component, a phonetic component, a sensor component, etc. Network interface 1312 may provide an interface for apparatus 1300 to communicate via one or more networks. Apparatus 1300 may wirelessly communicate with one or more components of a wireless network according to any of one or more wireless network standards and / or protocols, for example, accessing a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G, 5G, etc., or a combination thereof for wireless communication.

[0273] For one embodiment, at least one of the processor(s) 1302 may be packaged together with the logic of one or more controllers of the control module 1304 (e.g., a memory controller module). For one embodiment, at least one of the processor(s) 1302 may be packaged together with the logic of one or more controllers of the control module 1304 to form a system-in-package (SiP). For one embodiment, at least one of the processor(s) 1302 may be integrated on the same die with the logic of one or more controllers of the control module 1304. For one embodiment, at least one of the processor(s) 1302 may be integrated on the same die with the logic of one or more controllers of the control module 1304 to form a system-on-chip (SoC).

[0274] In various embodiments, the apparatus 1300 may be, but is not limited to, a terminal device such as a server, a desktop computing device, or a mobile computing device (e.g., a laptop computing device, a handheld computing device, a tablet computer, a netbook, etc.). In various embodiments, the apparatus 1300 may have more or fewer components and / or a different architecture. For example, in some embodiments, the apparatus 1300 includes one or more cameras, a keyboard, a liquid crystal display (LCD) screen (including a touchscreen display), a non-volatile memory port, multiple antennas, a graphics chip, an application-specific integrated circuit (ASIC), and a speaker.

[0275] An embodiment of the present application provides an electronic device, comprising: one or more processors; and one or more machine-readable media having instructions stored thereon, which, when executed by the one or more processors, enable the electronic device to perform one or more methods as described in the present application.

[0276] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0277] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0278] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, and the combination of the processes and / or boxes in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable information processing terminal device to produce a machine, so that the instructions executed by the processor of the computer or other programmable information processing terminal device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0279] These computer program instructions may also be stored in a computer readable memory that can guide a computer or other programmable information processing terminal device to work in a specific manner, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0280] These computer program instructions can also be loaded onto a computer or other programmable information processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable terminal device. Figure 1 a process or multiple processes and / or boxes Figure 1 The steps for the function specified in one or more boxes.

[0281] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they are aware of the basic creative concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0282] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or terminal device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or terminal device that includes the element.

[0283] The above is a detailed introduction to the pre-silicon testing method and device provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core idea of ​​the present application. At the same time, for technical personnel in this field, based on the ideas of the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A pre-silicon testing method, characterized in that: An electronic device runs a virtual processor, an operating system runs on the virtual processor, the operating system has a simulated virtual hard disk, and software runs on the operating system. The method is applied to the virtual processor and includes: When an access request to a virtual hard disk submitted by the software is dispatched to the virtual hard disk for processing and an indication indicating completion of processing of the access request is received from the virtual hard disk, the access request is stored in a first queue; the access request stored in the first queue is the access request that has been processed; Get the actual hard disk processing capacity parameters; Selecting access requests to be released in the first queue according to the actual processing capability parameters of the hard disk; Returns the access request to the software to be released.

2. The method according to claim 1, characterized in that The processing capacity parameters of the real hard disk include at least a target amount of data that the real hard disk can process within a unit time and a target time duration for the real hard disk to process an access request; The step of selecting the access request to be released in the first queue according to the actual processing capability parameter of the hard disk includes: Based on the target data volume and the target time duration, the access requests to be released are selected in the first queue, the total amount of data involved in the access requests to be released is less than or equal to the target data volume, and the duration between the moment when the access requests to be released are scheduled to the virtual hard disk and the current moment is greater than or equal to the target time duration.

3. The method according to claim 2, characterized in that The step of selecting the access request to be released in the first queue according to the target data volume and the target time duration includes: Searching the first queue for at least one access request whose duration between the time when the request was scheduled to the virtual hard disk and the current time is greater than or equal to the target time duration; determining whether a sum of data amounts involved in at least one access request is less than or equal to a target data amount; When a total amount of data involved in at least one access request is less than or equal to a target amount of data, selecting all of the at least one access request as access requests to be released; or, When the total amount of data involved in at least one access request is greater than the target data amount, some access requests from the at least one access request are selected, and the total amount of data involved in the some access requests is less than or equal to the target data amount, and the some access requests are selected as access requests to be released.

4. The method according to any one of claims 1 to 3, characterized in that The method further comprises: After selecting the access request to be released in the first queue, an interrupt signal is generated; Respond to interrupt signals; After responding to the interrupt signal, the access request to be released is returned to the software.

5. The method according to claim 4, characterized in that The virtual processor includes a plurality of processor cores, at least two of the plurality of processor cores respectively running an operating system, and the at least two processor cores include a first processor core and a second processor core; Software is running on the operating system running on the first processor core; The step of dispatching the access request submitted by the software to the virtual hard disk to be processed by the virtual hard disk and storing the access request in the first queue when receiving an indication returned by the virtual hard disk indicating that the processing of the access request is complete includes: When the first processor core dispatches an access request submitted by the software to the virtual hard disk for processing and receives an indication returned by the virtual hard disk indicating completion of processing the access request, the first processor core transmits the access request to a second processor core among the multiple processor cores, where the second processor core runs an operating system but does not run the software; The second processor core stores the access request in the first queue; Accordingly, the obtaining of the actual hard disk processing capability parameter, selecting the access request to be released in the first queue according to the actual hard disk processing capability parameter, and returning the access request to be released to the software includes: The second processor core obtains the processing capability parameter of the real hard disk, selects the access request to be released in the first queue according to the processing capability parameter of the real hard disk, and returns the access request to be released to the software.

6. The method according to claim 5, characterized in that The second processor core returns the access request to be released to the software, including: The second processor core generates an interrupt signal, where the interrupt signal carries the access request to be released and the function name of the interrupt processing function; The second processor core sends an interrupt signal to the first processor core; The first processor core receives an interrupt signal; The first processor core responds to the interrupt signal; After responding to the interrupt signal, the first processor core returns the access request to be released to the software.

7. A pre-silicon testing method, characterized in that: An electronic device runs a virtual processor, an operating system runs on the virtual processor, the operating system has a simulated virtual hard disk, and software runs on the operating system. The method is applied to the virtual processor and includes: When the access request submitted by the software to the virtual hard disk is dispatched to the virtual hard disk for processing and an indication indicating completion of processing of the access request is returned by the virtual hard disk, an interrupt signal is generated; Respond to interrupt signals; After responding to the interrupt signal, the access request is returned to the software.

8. The method according to claim 7, characterized in that The virtual processor includes a plurality of processor cores, at least two of the plurality of processor cores respectively running an operating system, and the at least two processor cores include a first processor core and a second processor core; The operating system running on the first processor core has software running on it, while the operating system running on the second processor core does not have software running on it; the access request is stored on the second processor core; The access request is transmitted to the second processor core when the first processor core receives an indication returned by the virtual hard disk indicating that the access request has been processed; The generating of the interrupt signal comprises: The second processor core generates an interrupt signal, where the interrupt signal carries an access request and a function name of an interrupt handling function; Accordingly, the responding interrupt signal includes: The second processor core sends an interrupt signal to the first processor core; The first processor core receives an interrupt signal; The first processor core responds to the interrupt signal; Accordingly, after responding to the interrupt signal, returning the access request to the software includes: After completing responding to the interrupt signal, the first processor core returns the access request to the software.

9. A pre-silicon testing device, characterized in that: An electronic device runs a virtual processor, an operating system runs on the virtual processor, the operating system has a simulated virtual hard disk, and software runs on the operating system. The device is applied to the virtual processor and includes: a storage module configured to, upon dispatching an access request submitted by the software to the virtual hard disk for processing and receiving an indication returned by the virtual hard disk indicating completion of processing of the access request, store the access request in a first queue; the access request stored in the first queue is the access request that has been processed; The acquisition module is used to obtain the actual hard disk processing capacity parameters; A selection module, configured to select an access request to be released in the first queue according to a real processing capability parameter of the hard disk; The first returning module is configured to return the access request to be released to the software.

10. A pre-silicon testing device, characterized in that: An electronic device runs a virtual processor, an operating system runs on the virtual processor, the operating system has a simulated virtual hard disk, and software runs on the operating system. The device is applied to the virtual processor and includes: a first generating module, configured to generate an interrupt signal when dispatching an access request submitted by the software to the virtual hard disk for processing and receiving an indication returned by the virtual hard disk indicating completion of processing the access request; A first response module, configured to respond to an interrupt signal; The second return module is used to return the access request to the software after responding to the interrupt signal.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When a processor executes the program, the method according to any one of claims 1 to 8 is implemented.

12. 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 a processor, the method according to any one of claims 1 to 8 is implemented.

13. A computer program product, characterized in that The method comprises a computer program / computer executable instructions, which implements the method according to any one of claims 1 to 8 when executed by a processor in an electronic device.

Images