Virtual test method and device of multi-core architecture processor and electronic equipment

Abstract

The invention provides a virtual test method and device for a multi-core architecture processor, electronic equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: sending a request message to a kernel module through an application program of a tested kernel; performing matching processing on the request message in a message model through the kernel module to obtain a response message corresponding to the request message; and sending the response message to the application program of the tested core through the core module. According to the method and the device, the inter-core communication function can be well simulated, the tested core can be effectively tested, and meanwhile, the implementation cost is relatively low.

Description

Technical Field

[0001] The present application relates to computer technology, and in particular to a virtual testing method, device, electronic device, computer-readable storage medium and computer program product for a multi-core architecture processor. Background Art

[0002] A multi-core architecture processor refers to a processor that integrates multiple complete computing engines (cores). For example, the S32G2 is an ARM architecture multi-core heterogeneous processor that integrates the ARM Cortex-A53 application processor (A core for short) and the Cortex-M7 real-time microcontroller (M core for short). The Linux operating system is usually deployed in the A core and the RTOS operating system is deployed in the M core. Under this architecture, complex control tasks can be processed by the A core equipped with the Linux operating system, while the collection and processing of real-time data can be completed by the M core running the RTOS operating system.

[0003] In the development and testing phase of a multi-core processor, it is necessary to test a core in the multi-core processor. In the solutions provided by related technologies, embedded flashing is usually performed on the development board where the multi-core processor is actually deployed, and related testing is performed. However, the steps of this solution are cumbersome and the cost is too high. Summary of the invention

[0004] The present application provides a virtual testing method, device, electronic device, computer-readable storage medium and computer program product for a multi-core architecture processor, which can well simulate the inter-core communication function, realize effective testing of the tested core, and achieve low cost.

[0005] The technical solution of this application is implemented as follows:

[0006] The present application provides a virtual testing method for a multi-core architecture processor, which is applied to a first computer system running on a first electronic device, wherein the first computer system is deployed with an application program of a tested core in the multi-core architecture processor and a kernel module for simulating an inter-core communication driver, wherein the kernel module is injected with a message model for inter-core communication; the method comprises:

[0007] Sending a request message to the kernel module through the application of the tested core;

[0008] Matching the request message in the message model through the kernel module to obtain a response message corresponding to the request message;

[0009] The response message is sent to the application program of the tested core through the kernel module.

[0010] The present application provides a virtual testing method for a multi-core architecture processor, which is applied to a second computer system, where the second computer system is run by a first electronic device or a second electronic device, and the second computer system is deployed with application programs for other cores of the multi-core architecture processor that are different from the tested core; the method includes:

[0011] Building a message model for inter-core communication through the application programs of the other cores;

[0012] Sending the message model to the daemon process through the application of the other core;

[0013] Among them, the daemon process is deployed on a first computer system running on the first electronic device, and the first computer system is also deployed with the application of the tested core and a kernel module for simulating an inter-core communication driver; the daemon process is used to inject the message model into the kernel module so that the kernel module simulates inter-core communication between the application of the tested core based on the message model.

[0014] The present application provides a virtual testing device for a multi-core processor, which is applied to a first computer system running on a first electronic device, wherein the first computer system is deployed with an application program of a tested core in the multi-core processor and a kernel module for simulating an inter-core communication driver, wherein the kernel module is injected with a message model for inter-core communication; the device comprises:

[0015] A request module, used for sending a request message to the kernel module through the application of the tested core;

[0016] A matching module, used for matching the request message in the message model through the kernel module to obtain a response message corresponding to the request message;

[0017] A response module is used to send the response message to the application program of the tested core through the kernel module.

[0018] The present application provides a virtual testing device for a multi-core processor, which is applied to a second computer system, where the second computer system is run by a first electronic device or a second electronic device, and the second computer system is deployed with application programs for other cores of the multi-core processor that are different from the core under test; the device includes:

[0019] A message model building module, used to build a message model for inter-core communication through the application programs of the other cores;

[0020] A message model sending module, used for sending the message model to the daemon process through the application of the other core;

[0021] Among them, the daemon process is deployed on a first computer system running on the first electronic device, and the first computer system is also deployed with the application of the tested core and a kernel module for simulating an inter-core communication driver; the daemon process is used to inject the message model into the kernel module so that the kernel module simulates inter-core communication between the application of the tested core based on the message model.

[0022] The present application provides an electronic device, including:

[0023] A memory for storing executable instructions;

[0024] The processor is used to implement the virtual testing method of the multi-core architecture processor provided in the present application when executing the executable instructions stored in the memory.

[0025] The present application provides a computer-readable storage medium storing executable instructions for causing a processor to execute and implement a virtual testing method for a multi-core architecture processor provided in the present application.

[0026] The present application provides a computer program product, which includes executable instructions for causing a processor to execute and implement the virtual testing method for a multi-core architecture processor provided by the present application.

[0027] This application has the following beneficial effects:

[0028] The present application deploys the application of the tested core in the multi-core architecture processor and the kernel module for simulating the inter-core communication driver in the first computer system. The kernel module is injected with the message model of inter-core communication, so that the inter-core communication is simulated through the interaction between the application of the tested core and the kernel module. For example, the application of the tested core sends a request message to the kernel module; the kernel module matches the request message in the message model to obtain a response message corresponding to the request message; and the kernel module sends the response message to the application of the tested core. The present application does not need to rely on the development board of the multi-core architecture processor for testing, and the implementation cost is low; at the same time, it can well simulate the inter-core communication between different cores in the multi-core architecture processor, thereby improving the test effect. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0030] Figure 1 It is a first architecture schematic diagram of a virtual test system for a multi-core architecture processor provided in an embodiment of the present application;

[0031] Figure 2A is a first structural schematic diagram of an electronic device provided in an embodiment of the present application;

[0032] Figure 2B is a second structural schematic diagram of an electronic device provided in an embodiment of the present application;

[0033] Figure 3A It is a first flow chart of a virtual testing method for a multi-core architecture processor provided in an embodiment of the present application;

[0034] Figure 3B It is a second flow chart of the virtual testing method of the multi-core architecture processor provided in the embodiment of the present application;

[0035] Figure 3C It is a third flow chart of the virtual testing method for a multi-core architecture processor provided in an embodiment of the present application;

[0036] Figure 3D It is a fourth flow chart of the virtual testing method for a multi-core architecture processor provided in an embodiment of the present application;

[0037] Figure 4 It is a second architecture schematic diagram of a virtual test system for a multi-core architecture processor provided in an embodiment of the present application;

[0038] Figure 5 It is a fifth flow chart of the virtual testing method of the multi-core architecture processor provided in the embodiment of the present application;

[0039] Figure 6 It is a sixth flow chart of the virtual testing method for a multi-core architecture processor provided in an embodiment of the present application;

[0040] Figure 7 This is the seventh flow chart of the virtual testing method for a multi-core architecture processor provided in an embodiment of the present application. DETAILED DESCRIPTION

[0041] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of this application.

[0042] In the following description, reference is made to "some embodiments", which describes a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict. In the following description, reference is made to the term "multiple" to mean at least two.

[0043] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0044] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0045] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0046] 1) Computer system: refers to a complete system consisting of computer hardware and software that work together to perform specific data processing tasks. Computer systems can receive, store, process, analyze and output information.

[0047] 2) Virtual Machine: A virtual computer system with complete hardware functions simulated by software. A virtual machine runs on a physical computer (electronic device), but is logically independent and has complete hardware functions and an operating system.

[0048] 3) Physical machine: A computer system built on real hardware with independent physical resources and operating system.

[0049] 4) Inter-Processor Communication (IPC): refers to a communication method for information transmission and sharing between different processor cores (hereinafter referred to as cores) in a multi-core architecture processor. With the continuous development of computer technology, modern processors generally adopt multi-core technology, that is, integrating multiple cores in a processor chip to achieve efficient parallel processing and collaborative work. As a very critical function in a multi-core architecture processor, inter-core communication enables different cores to work together effectively and complete tasks together. Therefore, it is usually necessary to test the inter-core communication function in the development and testing of multi-core architecture processors.

[0050] 5) Kernel Object (KO) module: deployed on the same computer system as the application of the tested core, used to simulate the inter-core communication driver in the embodiment of the present application, that is, the kernel module can be regarded as a fake inter-core communication driver, and the kernel module shields the dependence on hardware.

[0051] 6) Daemon process: Deployed on the same computer system as the application of the tested core, the daemon process is the bridge between the kernel module and the application of other cores.

[0052] The embodiments of the present application provide a virtual testing method, device, electronic device, computer-readable storage medium, and computer program product for a multi-core architecture processor, which can well simulate the inter-core communication function, realize effective testing of the tested core, and realize low cost. The following describes an exemplary application of the electronic device provided by the embodiments of the present application. The electronic device provided by the embodiments of the present application can be implemented as various types of terminal devices, and can also be implemented as a server.

[0053] See also Figure 1 , Figure 1 1 is a schematic diagram of the architecture of a virtual test system for a multi-core processor provided in an embodiment of the present application. The electronic device 100 ( Figure 1 In the example of the electronic device 100 as a terminal device, a virtual machine 100-1 and a physical machine 100-2 are running. The virtual machine 100-1 is deployed with an application of a tested core in a multi-core architecture processor, a kernel module for simulating an inter-core communication driver, and a daemon process. The physical machine 100-2 is deployed with applications of other cores in the multi-core architecture processor that are different from the tested core.

[0054] In some embodiments, the physical machine 100-2 builds a message model for inter-core communication through the applications of other cores; the physical machine 100-2 sends the message model to the daemon process in the virtual machine 100-1 through the applications of other cores; the virtual machine 100-1 injects the message model into the kernel module through the daemon process; the virtual machine 100-1 sends the request message to the kernel module through the application of the tested core; the virtual machine 100-1 matches the request message in the message model through the kernel module to obtain a response message corresponding to the request message; the virtual machine 100-1 sends the response message to the application of the tested core through the kernel module; the virtual machine 100-1 performs log scanning and processing through the daemon process to extract the request message; the virtual machine 100-1 sends the request message to the applications of other cores through the daemon process; the physical machine 100-2 displays the request message through the applications of other cores.

[0055] It is worth noting that the embodiment of the present application does not limit the communication method between the virtual machine 100 - 1 and the physical machine 100 - 2 . For example, TCP socket communication can be performed through the network card of the electronic device 100 .

[0056] In some embodiments, the virtual machine 100 - 1 and the physical machine 100 - 2 may also run on different electronic devices respectively, for example, the virtual machine 100 - 1 runs on a terminal device, and the physical machine 100 - 2 runs on a server.

[0057] In some embodiments, the electronic device 100 can implement the virtual testing method of the multi-core architecture processor provided in the embodiment of the present application by running a computer program. For example, the computer program can be a native program or software module in the operating system; it can be a native application (APP, Application), that is, a program that needs to be installed in the operating system to run; it can also be a small program, that is, a program that can be run only by downloading it to a browser environment; it can also be a small program that can be embedded in any APP, and the small program can be controlled to run or closed by the user. In short, the above-mentioned computer program can be an application, module or plug-in in any form.

[0058] See also Figure 2A , Figure 2A is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of the present application, Figure 2A The electronic device 100 shown includes: at least one processor 110, a memory 150 and at least one network interface 120. The various components in the electronic device 100 are coupled together via a bus system 140. It is understood that the bus system 140 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 140 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, the bus system 140 is not described in detail. Figure 2A Various buses are labeled as bus system 140 .

[0059] The processor 110 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0060] The memory 150 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. The memory 150 may optionally include one or more storage devices that are physically remote from the processor 110.

[0061] The memory 150 includes a volatile memory or a non-volatile memory, and may also include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), and the volatile memory may be a random access memory (RAM). The memory 150 described in the embodiments of the present application is intended to include any suitable type of memory.

[0062] In some embodiments, the memory 150 can store data to support various operations, examples of which include programs, modules, and data structures, or a subset or superset thereof, as exemplarily described below.

[0063] Operating system 151, including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

[0064] A network communication module 152, used to reach other computing devices via one or more (wired or wireless) network interfaces 120, exemplary network interfaces 120 include: Bluetooth, Wireless Authentication (WiFi), and Universal Serial Bus (USB);

[0065] In some embodiments, the virtual testing device for a multi-core processor provided in the embodiments of the present application may be implemented in software. Figure 2A A virtual test device 1551 of a multi-core architecture processor stored in the memory 150 is shown, which can be software in the form of a program and a plug-in, including the following software modules: a request module 15511, a matching module 15512, and a response module 15513. These modules are logical, and therefore can be arbitrarily combined or further split according to the functions implemented. The functions of each module will be described below.

[0066] In some embodiments, Figure 2B A virtual test device 1552 of a multi-core architecture processor stored in the memory 150 is shown, which can be software in the form of a program and a plug-in, including the following software modules: a message model building module 15521 and a message model sending module 15522. These modules are logical, so they can be arbitrarily combined or further split according to the functions implemented. The functions of each module will be explained below.

[0067] The virtual testing method for the multi-core architecture processor provided in the embodiment of the present application will be described in combination with the exemplary application and implementation of the electronic device provided in the embodiment of the present application.

[0068] See also Figure 3A, Figure 3A is a flowchart of a virtual testing method for a multi-core architecture processor provided in an embodiment of the present application, which will be combined with Figure 3A The steps shown are explained.

[0069] In step 101, the application of the tested core sends a request message to the kernel module.

[0070] Here, the first electronic device runs a first computer system, the first computer system deploys an application of the tested core in the multi-core architecture processor, and a kernel module for simulating the inter-core communication driver, and the kernel module is injected with a message model for inter-core communication. It is worth noting that the first electronic device can be a terminal device or a server, the first computer system can be a virtual machine or a physical machine, and the multi-core architecture processor can be a multi-core homogeneous processor or a multi-core heterogeneous processor, which is not limited; the application of the tested core deployed by the first computer system is a mirror, that is, the embodiment of the present application does not involve the deployment at the hardware level, but only involves the deployment at the software level, and realizes virtual testing based on the deployment at the software level, which can effectively reduce the testing cost; the message model includes multiple <request message, reply message> message pairs, and the pre-configured message model can be injected into the kernel module when the kernel module is deployed. Of course, the message model can also be configured in other ways, wherein the message model can be injected into the kernel module by memory mapping.

[0071] The application of the tested core will generate a request message during its operation, and the application of the tested core will send the generated request message to the kernel module.

[0072] In some embodiments, the first computer system is a virtual machine. Since the virtual machine in the first electronic device is isolated from the physical machine, even if the test process is destructive, it will only affect the virtual machine (for example, causing the virtual machine to need to be restarted or reinstalled), and will not affect the physical machine, which can well protect the first electronic device.

[0073] In step 102, the kernel module matches the request message in the message model to obtain a response message corresponding to the request message.

[0074] When the kernel module receives a request message sent by the application program of the tested core, it matches the request message in the message model to obtain a response message corresponding to the request message.

[0075] For example, the message model includes three message pairs, namely <request message 1, response message 1>, <request message 2, response message 2> and <request message 3, response message 3>. If the request message received by the kernel module and sent by the application of the tested core is request message 1, then request message 1 will be matched in the message model to obtain response message 1.

[0076] In step 103, the kernel module sends a response message to the application program of the tested core.

[0077] The kernel module sends the response message obtained by the matching process to the application of the tested core, thereby simulating the inter-core communication process between the application of the tested core and the applications of other cores. When the application of the tested core receives the response message, it can continue to process the logic and trigger the sending of the next request message.

[0078] In some embodiments, the kernel module can create multiple channels and simulate inter-core communication with the application of the tested core through the multiple channels, which can improve the traffic load capacity and help achieve load balancing.

[0079] like Figure 3A As shown, the embodiment of the present application deploys the application of the tested core in the multi-core architecture processor and the kernel module for simulating the inter-core communication driver in the first computer system, and the kernel module is injected with the message model of inter-core communication, so that the inter-core communication is simulated through the interaction between the application of the tested core and the kernel module. For example, the application of the tested core sends a request message to the kernel module; the kernel module matches the request message in the message model to obtain a response message corresponding to the request message; and the kernel module sends the response message to the application of the tested core. The embodiment of the present application does not need to rely on the development board for deploying the multi-core architecture processor for testing (that is, there is no need to implement hardware-level deployment), and the implementation cost is low; at the same time, it can well simulate the inter-core communication between different cores in the multi-core architecture processor, thereby improving the test effect.

[0080] In some embodiments, see Figure 3B , Figure 3B is a flowchart of a virtual testing method for a multi-core architecture processor provided in an embodiment of the present application. Figure 3A The illustrated step 103 can be implemented through steps 201 to 202 , which will be described in conjunction with each step.

[0081] In step 201, the kernel module stores the response message in a memory buffer and sends a message arrival notification to the application of the tested core.

[0082] Here, the kernel module may store the response message in a memory buffer and send a message arrival notification to the application of the tested core, wherein the data structure used by the memory buffer is not limited, for example, it may be a ring queue (ringBuffer).

[0083] In step 202, upon receiving the message arrival notification, the application of the tested core obtains the response message from the memory buffer.

[0084] The memory buffer is used as a communication medium between the kernel module and the application of the tested core to temporarily store the response message. When the application of the tested core receives the message arrival notification, it obtains the response message from the memory buffer to complete a communication process.

[0085] It is worth mentioning that the use of memory buffer can improve communication efficiency on the one hand, that is, using memory buffer as a communication medium makes the communication process smoother and more efficient; on the other hand, it can enhance the reliability and integrity of communication, and can apply error handling, flow control and other mechanisms.

[0086] In some embodiments, the above-mentioned sending of the request message by the application of the tested core to the kernel module can be implemented in the following manner: the application of the tested core calls the data write interface of the first computer system to send the request message to the kernel module; the above-mentioned obtaining of the response message from the memory buffer can be implemented in the following manner: the application of the tested core calls the data acquisition interface of the first computer system to obtain the response message from the memory buffer.

[0087] Here, the application of the tested core can call the data writing interface of the first computer system to send the request message to the kernel module. The data writing interface is provided by the operating system of the first computer system. Taking the Linux operating system as an example, the data writing interface can be a write() interface.

[0088] The application of the tested core can call the data acquisition interface of the first computer system to obtain the response message from the memory buffer. Similarly, the data acquisition interface is provided by the operating system of the first computer system. Taking the Linux operating system as an example, the data acquisition interface can be a read() interface.

[0089] In the above method, the application of the tested core can implement operations such as sending request messages and obtaining response messages by calling the interface of the first computer system. Therefore, as long as the application of the tested core can communicate with the operating system of the first computer system, the virtual testing method of the multi-core architecture processor provided in the embodiment of the present application can be applied, which can effectively improve compatibility and applicability.

[0090] like Figure 3B As shown, the embodiment of the present application adopts a memory buffer as a communication medium when transmitting a response message, which can improve the communication efficiency on the one hand, making the communication process smoother and more efficient; on the other hand, it can enhance the reliability and integrity of the communication, and can apply error handling, flow control and other mechanisms to ensure that the response message can smoothly reach the application of the tested core.

[0091] In some embodiments, see Figure 3C , Figure 3C is a flowchart of a virtual testing method for a multi-core architecture processor provided in an embodiment of the present application. Figure 3A Before step 101 shown, steps 301 to 302 may also be performed.

[0092] In step 301, the application programs of other cores send the message model to the daemon process.

[0093] Here, the first computer system is also deployed with a daemon process; the second computer system is deployed with applications for other cores in a multi-core architecture processor that are different from the tested core. The second computer system and the first computer system can be run by the same electronic device (i.e., the first electronic device), or by different electronic devices, i.e., the second computer system is run by the second electronic device. It is worth noting that the second electronic device can be a terminal device or a server, and the second computer system can be a virtual machine or a physical machine, without limitation; the application for other cores deployed by the second computer system is a mirror image, i.e., it only involves software-level deployment.

[0094] The application programs of other cores can be used to configure the message model, for example, to provide a visual interface for users to configure the message model. After completing the configuration of the message model, the application programs of other cores send the message model to the daemon process.

[0095] In some embodiments, the first computer system is a virtual machine, the second computer system is a physical machine, and both the first computer system and the second computer system are run by the first electronic device. Considering that the applications of other cores do not actually participate in the communication process with the application of the tested core, it is usually impossible to cause damage to the second computer system, so the second computer system can be a physical machine; in addition, the first computer system and the second computer system can be run in the same electronic device, which can further reduce the test cost, that is, only one electronic device is needed to implement the test, which can also avoid resource consumption caused by communication between different electronic devices.

[0096] In step 302, the daemon process injects the message model into the kernel module.

[0097] When receiving the message model, the daemon process injects the message model into the kernel module, for example, by injecting the message model into the kernel module through a memory mapping mechanism for subsequent calls by the kernel module. In this way, the kernel module has the ability to simulate inter-core communication.

[0098] like Figure 3C As shown, in the embodiment of the present application, the application program of other cores sends the message model to the daemon process, which enables flexible configuration of the message model, for example, the specific content of the request message and the response message can be flexibly customized to meet various testing requirements; the daemon process injects the message model into the kernel module, which enables smooth transmission and injection of the message model, laying the foundation for subsequent simulation of inter-core communication.

[0099] In some embodiments, see Figure 3D , Figure 3D is a flowchart of a virtual testing method for a multi-core architecture processor provided in an embodiment of the present application. Figure 3A After step 101 shown ( Figure 3D In the description, the process after step 103 is taken as an example), and steps 401 to 403 may also be performed.

[0100] In step 401, the daemon process performs kernel log scanning processing to extract the request message.

[0101] Here, the first computer system is also deployed with a daemon process; the second computer system is deployed with applications of other cores in the multi-core architecture processor that are different from the tested core. Since the request information sent by the application of the tested core will be stored in the kernel log, the daemon process can perform kernel log scanning processing (such as periodically performing kernel log scanning processing) to extract the request message.

[0102] In step 402, the daemon process sends a request message to the application programs of other cores.

[0103] In step 403, the application programs of other cores display the request message.

[0104] Here, the daemon sends the request message to the application of other cores so that the application of other cores can display the request message in the visual interface. For example, the application of other cores can print the received request message in the log text box and then display it visually. For the relevant personnel involved in the test, they can understand the processing logic of the application of the tested core through the displayed request message, and it is helpful to optimize the test process according to actual needs.

[0105] like Figure 3DAs shown, in the embodiment of the present application, a daemon process performs kernel log scanning and processing to extract request messages, and then sends the request messages to applications of other cores so that the applications of other cores display the request messages, thereby achieving a visual display of the test process, allowing relevant personnel involved in the test to understand the specific circumstances of the test, and at the same time helping to optimize the test process according to actual needs.

[0106] The following will describe an exemplary application of the present invention in a practical application scenario. Figure 4 As shown, the virtual test system for a multi-core architecture processor provided in an embodiment of the present application includes three other components in addition to the application program of the tested core:

[0107] 1) Inter-Process Communication Framework (IPCF) kernel module (corresponding to the kernel module above): The IPCF kernel module is deployed on the same virtual machine together with the application of the tested core to simulate the inter-core communication required for message interaction between multiple cores. On the hardware board with a multi-core architecture processor, the IPCF mechanism is used for inter-core communication between multiple cores. IPCF is a hardware-dependent driver. In the embodiment of the present application, the IPCF kernel module is a simulated driver that shields the dependence on hardware. The role of the IPCF kernel module is to reply to the corresponding response message when receiving the request message sent by the application of the tested core.

[0108] 2) Applications of other cores: They can be deployed to the host machine (referring to the physical machine where the terminal device where the virtual machine is located) or the cloud server. On the one hand, the applications of other cores are used to configure multiple <request message, response message> message pairs, and all message pairs are combined to obtain the message model; on the other hand, the visual effect is displayed based on the request message sent by the daemon process.

[0109] 3) Daemon: The daemon is deployed on the same virtual machine with the application of the tested core. The daemon is the bridge between the IPCF kernel module and the applications of other cores. The daemon is used to receive the message model configured by the applications of other cores and inject the message model into the IPCF kernel module. On the other hand, it is used to forward all request messages received by the IPCF kernel module from the application of the tested core for visual display of the effect.

[0110] The above three components interact with the application of the tested core through the following nine steps to complete a test of the <request message, response message> message pair. Through multiple rounds of testing, different application scenarios can be covered, thereby effectively testing the various functions of the tested core. Figure 5 Provide explanation.

[0111] Step 1: On the application of other cores, multiple <request message, response message> message pairs are configured in a visual way, and all message pairs are merged into a message model, or a pre-configured message model can be directly imported. Among them, a json file can be used to save the message model, of course, it is not limited to this.

[0112] Step 2: After configuring the good message model on the application of other cores, send the message model to the daemon process. For example, a "Send" button can be displayed in the visual interface of the application of other cores, and in response to a trigger operation (such as a click operation) on the "Send" button, the message model is sent to the daemon process.

[0113] Step 3: After receiving the message model, the daemon process calls the mmap() interface provided by the Linux operating system of the virtual machine to obtain the memory mapping address of the IPCF kernel module, and then writes the message model directly into the memory, that is, injects the message model into the IPCF kernel module.

[0114] Step 4: The application of the tested core calls the write() interface provided by the Linux operating system of the virtual machine to send the request message to the IPCF kernel module. It is worth noting that the send_ipcf_msg() function of the IPCF kernel module is ultimately called through the write() interface to implement the sending of the request message.

[0115] Step 5: The IPCF kernel module uses the message model to match the response message corresponding to the request message, puts the response message into the ring queue (ringBuffer), and notifies the application of the tested core that a message has arrived.

[0116] Step 6: The application of the tested core calls the read() interface provided by the Linux operating system of the virtual machine to read the reply message from the circular queue. It is worth noting that the read_ipcf_msg() function of the IPCF kernel module is ultimately called through the read() interface to obtain the reply message.

[0117] Step 7: The daemon process periodically scans the kernel log file / proc / kmsg to extract the request messages sent by the application of the tested core.

[0118] Step 8: The daemon process sends the extracted request message to the applications in other cores.

[0119] Step 9: The applications of other cores visualize the received request messages.

[0120] As an example, the present application also provides the following embodiments: Figure 6 and Figure 7 The flowchart of the virtual testing method for a multi-core architecture processor is shown, wherein the IPCF kernel module can create multiple IPCF channel devices (corresponding to the channels above), and realize message interaction with the application of the tested core through multiple IPCF channel devices, thereby improving the traffic load capacity and helping to improve the testing efficiency.

[0121] The embodiments of the present application can at least achieve the following technical effects:

[0122] 1) No changes need to be made to the application of the tested core. The same software package can be deployed to a real hardware development board and a virtual machine for testing, enabling seamless switching.

[0123] 2) The IPCF kernel module can receive request messages and reply to response messages like a real inter-core communication driver, which is completely unaware of the application of the tested core. The entire test process does not rely on the hardware development board deployed with a multi-core architecture processor, which can save the cost of purchasing hardware development boards.

[0124] 3) On the one hand, the daemon process can obtain the <request message, response message> message pair configured by the application program of other cores, convert it into the data structure required by the IPCF kernel module, and inject it into the IPCF kernel module as a message model; on the other hand, it can scan the kernel log in real time to obtain the request message, and pass it to the application program of other cores through the network card for visualization effect display. These two functions make the embodiment of the present application have the advantages of flexible configuration and visualization effect display.

[0125] 4) The applications of other cores can provide a visual interface for flexibly customizing the content of request messages and response messages. They can also be used to display the request messages sent by the application of the tested core, enabling visual interaction with relevant personnel and having the advantages of flexibility and intuitiveness.

[0126] 5) The embodiments of the present application can flexibly customize the content of request messages and response messages, and can simulate various application scenarios, for example, it can simulate abnormal scenarios, such as response message loss, error response, timeout response, etc. Therefore, the embodiments of the present application can fully meet the testing requirements and are very suitable for development testing of new functions and abnormal scenarios.

[0127] 6) The virtual machine runs in an isolated environment. Even if the testing process is destructive, it will only damage the virtual machine, such as causing the virtual machine to restart or need to be reinstalled, and will not damage the hardware equipment.

[0128] The following further describes an exemplary structure of a virtual test device 1551 for a multi-core processor provided in an embodiment of the present application implemented as a software module. In some embodiments, Figure 2A As shown, the software modules in the virtual test device 1551 of the multi-core architecture processor stored in the memory 150 may include: a request module 15511, used to send a request message to the kernel module through the application of the tested core; a matching module 15512, used to match the request message in the message model through the kernel module to obtain a response message corresponding to the request message; and a response module 15513, used to send a response message to the application of the tested core through the kernel module.

[0129] In some embodiments, the response module 15513 is also used to: store the response message in the memory buffer through the kernel module, and send a message arrival notification to the application of the tested core; when the application of the tested core receives the message arrival notification, obtain the response message from the memory buffer.

[0130] In some embodiments, the request module 15511 is also used to: call the data write interface of the first computer system through the application of the tested core to send the request message to the kernel module; the response module 15513 is also used to: call the data acquisition interface of the first computer system through the application of the tested core to obtain the response message from the memory buffer.

[0131] In some embodiments, the virtual testing device 1551 of the multi-core architecture processor also includes a message model receiving module, which is used to receive the message model sent by the application of other cores through the daemon process; the virtual testing device 1551 of the multi-core architecture processor also includes an injection module, which is used to inject the message model into the kernel module through the daemon process; wherein the other cores are cores in the multi-core architecture processor that are different from the core being tested; the application of the other cores is deployed in a second computer system, and the second computer system is run by the first electronic device or the second electronic device.

[0132] In some embodiments, the virtual testing device 1551 of the multi-core architecture processor also includes a kernel log scanning module, which is used to perform kernel log scanning processing through a daemon process to extract request messages; the virtual testing device 1551 of the multi-core architecture processor also includes a request message sending module, which is used to send request messages to applications of other cores through a daemon process so that the applications of other cores display the request messages; wherein the other cores are cores in the multi-core architecture processor that are different from the core being tested; the applications of the other cores are deployed in a second computer system, and the second computer system is run by the first electronic device or the second electronic device.

[0133] The following is a description of an exemplary structure of a virtual test device 1552 for a multi-core processor provided in an embodiment of the present application implemented as a software module. In some embodiments, Figure 2B As shown, the software modules in the virtual test device 1552 of the multi-core architecture processor stored in the memory 150 may include: a message model building module 15521, used to build a message model for inter-core communication through the applications of other cores; a message model sending module 15522, used to send the message model to the daemon process through the applications of other cores; wherein the daemon process is deployed on a first computer system running on a first electronic device, and the first computer system is also deployed with the application of the tested core and a kernel module for simulating the inter-core communication driver; the daemon process is used to inject the message model into the kernel module, so that the kernel module simulates the inter-core communication between the application of the tested core based on the message model.

[0134] In some embodiments, the virtual test device 1552 of the multi-core architecture processor also includes a request message receiving module for receiving request messages sent by the daemon process through the applications of other cores; the virtual test device 1552 of the multi-core architecture processor also includes a display module for displaying request messages through the applications of other cores.

[0135] The embodiment of the present application provides a computer program product or a computer program, which includes executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the executable instructions from the computer-readable storage medium, and the processor executes the executable instructions, so that the electronic device executes the virtual testing method of the multi-core architecture processor described in the embodiment of the present application.

[0136] An embodiment of the present application provides a computer-readable storage medium storing executable instructions, wherein executable instructions are stored. When the executable instructions are executed by a processor, the processor will execute the virtual testing method for the multi-core architecture processor provided in the embodiment of the present application.

[0137] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface storage, optical disk, or CD-ROM; or it may be various devices including one or any combination of the above memories.

[0138] In some embodiments, executable instructions may be in the form of a program, software, software module, script or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine or other unit suitable for use in a computing environment.

[0139] As an example, executable instructions may, but need not, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, such as in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or code portions).

[0140] As an example, the executable instructions may be deployed to be executed on one electronic device, or on multiple electronic devices located at one site, or on multiple electronic devices distributed at multiple sites and interconnected by a communication network.

[0141] The above are only embodiments of the present application and are not intended to limit the protection scope of the present application. Any modifications, equivalent substitutions and improvements made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A virtual testing method for a multi-core architecture processor, characterized in that: A first computer system applied to a first electronic device, wherein the first computer system is deployed with an application program of a tested core in the multi-core architecture processor and a kernel module for simulating an inter-core communication driver, wherein the kernel module is injected with a message model for inter-core communication; the method comprising: Sending a request message to the kernel module through the application of the tested core; Matching the request message in the message model through the kernel module to obtain a response message corresponding to the request message; The response message is sent to the application program of the tested core through the kernel module.

2. The method according to claim 1, characterized in that: The step of sending the response message to the application of the tested core through the kernel module includes: The kernel module stores the response message in a memory buffer, and sends a message arrival notification to the application of the tested core; When receiving the message arrival notification, the application program of the tested core obtains the response message from the memory buffer.

3. The method according to claim 2, characterized in that The step of sending a request message to the kernel module through the application of the tested core includes: calling the data writing interface of the first computer system through the application program of the tested core to send the request message to the kernel module; The acquiring the response message from the memory buffer comprises: The data acquisition interface of the first computer system is called by the application program of the tested core to obtain the response message from the memory buffer.

4. The method according to any one of claims 1 to 3, characterized in that: The first computer system is also deployed with a daemon process; the method further comprises: A model for receiving messages sent by applications of other cores through the daemon process; Injecting the message model into the kernel module through the daemon process; The other cores are cores in the multi-core architecture processor that are different from the core under test; and the applications of the other cores are deployed in a second computer system, and the second computer system is run by the first electronic device or the second electronic device.

5. The method according to any one of claims 1 to 3, characterized in that: The first computer system is also deployed with a daemon process; the method further comprises: Performing kernel log scanning processing through the daemon process to extract the request message; Sending the request message to the application programs of other cores through the daemon process, so that the application programs of the other cores display the request message; The other cores are cores in the multi-core architecture processor that are different from the core under test; and the applications of the other cores are deployed in a second computer system, and the second computer system is run by the first electronic device or the second electronic device.

6. A virtual testing method for a multi-core architecture processor, characterized in that: The method is applied to a second computer system, the second computer system is run by the first electronic device or the second electronic device, and the second computer system is deployed with application programs of other cores in the multi-core architecture processor that are different from the tested core; the method includes: Building a message model for inter-core communication through the application programs of the other cores; Sending the message model to the daemon process through the application of the other core; Among them, the daemon process is deployed on a first computer system running on the first electronic device, and the first computer system is also deployed with the application of the tested core and a kernel module for simulating an inter-core communication driver; the daemon process is used to inject the message model into the kernel module so that the kernel module simulates inter-core communication between the application of the tested core based on the message model.

7. The method according to claim 6, characterized in that After the application program of the other core sends the message model to the daemon process, the method further includes: Receiving, by the application of the other core, a request message sent by the daemon process; The request message is displayed by the application of the other core.

8. A virtual testing device for a multi-core processor, characterized in that: A first computer system applied to a first electronic device, wherein the first computer system is deployed with an application program of a tested core in the multi-core architecture processor and a kernel module for simulating an inter-core communication driver, wherein the kernel module is injected with a message model for inter-core communication; the device comprises: A request module, used for sending a request message to the kernel module through the application of the tested core; A matching module, used for matching the request message in the message model through the kernel module to obtain a response message corresponding to the request message; A response module is used to send the response message to the application program of the tested core through the kernel module.

9. A virtual testing device for a multi-core processor, characterized in that: The device is applied to a second computer system, the second computer system is run by the first electronic device or the second electronic device, and the second computer system is deployed with application programs of other cores in the multi-core architecture processor that are different from the tested core; the device includes: A message model building module, used to build a message model for inter-core communication through the application programs of the other cores; A message model sending module, used for sending the message model to the daemon process through the application of the other core; Among them, the daemon process is deployed on a first computer system running on the first electronic device, and the first computer system is also deployed with the application of the tested core and a kernel module for simulating an inter-core communication driver; the daemon process is used to inject the message model into the kernel module so that the kernel module simulates inter-core communication between the application of the tested core based on the message model.

10. An electronic device, characterized in that: include: A memory for storing executable instructions; A processor, configured to implement the method described in any one of claims 1 to 5, or the method described in any one of claims 6 to 7, when executing the executable instructions stored in the memory.

11. A computer-readable storage medium, characterized in that: Executable instructions are stored, which are used to implement the method described in any one of claims 1 to 5, or the method described in any one of claims 6 to 7 when executed by a processor.

12. A computer program product, characterized in that The method comprises executable instructions for implementing the method described in any one of claims 1 to 5, or the method described in any one of claims 6 to 7 when executed by a processor.

Images