Model-based Qemu rear-end driving simulation system and method

Abstract

The invention relates to a model-based Qemu rear-end drive simulation system and method. The simulation system comprises a rear-end equipment module, a rear-end hardware adaptation module and a rear-end model module, the rear-end model module is a hardware model for simulating behaviors of various types of hardware; the type is the type of hardware simulated by a Qemu rear-end driver; the input data of the training hardware model is register information and context information of input hardware when the hardware is called for read / write operation, and the output data of the hardware model is current state information of a register when the hardware is called completely; when the rear-end equipment module receives the read / write operation of the memory io triggered by the front-end drive, context information, current memory io interrupt information and an io read / write address instruction are sent to the hardware model through the rear-end hardware adaptation module, and the output of the hardware model is used as the output of the simulation system; hardware behavior consistency can be guaranteed to be higher, and understanding of individuals on hardware is prevented from becoming a bottleneck of Qemu back-end driver development.

Description

Technical Field

[0001] The present invention relates to the field of virtualization platform production, and in particular, to a model-based Qemu backend driver simulation system and method. Background Art

[0002] Qemu (Quick EMULATOR) is a set of simulation processor software written by Fabrice Bellard and distributed under the GPL license. As an open-source hardware emulator project, Qemu supports multiple hardware architectures such as x86, arm, arm64, mips, powerpc, and ia64. In Qemu, the backend driver is responsible for simulating specific hardware devices. These devices may include network interfaces, disk drives, graphics adapters, etc.

[0003] In the existing Qemu backend driver solutions, developers need to have a very good understanding of the hardware IP core behavior and data manuals in order to write the corresponding hardware Qemu backend drivers, which requires high requirements for developers. Complex hardware cannot be simulated using traditional methods, and the state management is complex. Compared with the actual hardware behavior, the consistency cannot reach a high level, and the hardware behavior consistency is strongly related to the developer's understanding of the hardware IP core. Especially in fields with high requirements for hardware behavior consistency such as vehicles and airplanes, the more complex the hardware behavior, the more difficult it is to achieve a high level of consistency. Therefore, the traditional solutions are untrustworthy or even unusable. Summary of the Invention

[0004] In view of the technical problems existing in the prior art, the present invention provides a model-based Qemu backend driver simulation system and method, which can ensure higher hardware behavior consistency and prevent personal understanding of hardware from becoming a bottleneck in Qemu backend driver development.

[0005] According to a first aspect of the present invention, there is provided a model-based Qemu backend driver simulation system, including: a backend device module, a backend hardware adaptation module, and a backend model module; The backend model module is a hardware model that simulates the behavior of various types of hardware; the type is the type of hardware simulated by the Qemu backend driver; The input data for training the hardware model is the register information and context information input to the hardware when the hardware is called for read / write operations, and the output data of the hardware model is the current state information of the register when the hardware call is completed; When the backend device module receives a front-end drive to trigger a memory I / O read / write operation, it sends context information, current memory I / O interrupt information, and I / O read / write address instructions to the hardware model through the backend hardware adaptation module, and uses the output of the hardware model as the output of the simulation system.

[0006] Based on the above technical solutions, the present invention can also be improved as follows.

[0007] Optionally, the construction process of the dataset for training the input data of the hardware model includes: Based on the composition of the register list in the hardware IP core datasheet, use a script to generate multiple register information, and filter through random values to obtain register information containing context information as test cases; Use a debugging tool that captures snapshot information of the memory I / O and interrupt information of the hardware IP to capture each of the test cases, and use the captured information as the dataset.

[0008] Optionally, the backend device module completes the front-end address request by mapping the device address to the CPU unified addressing bus, and triggers the front-end interrupt by applying for an interrupt from the backend interrupt controller.

[0009] Optionally, the backend hardware adaptation module is used to adapt to different native hardware environments and provide an interface for the backend device module to call.

[0010] Optionally, the initialization process of the simulation system includes: Start Qemu, initialize the backend device module, the backend device module maps the device address to the CPU unified addressing bus, applies for an interrupt from the backend interrupt controller, and calls the backend hardware adaptation module for initialization; The backend hardware adaptation module loads the hardware model into the real hardware according to the current hardware environment to complete the initialization of the backend model module; The backend device module provides power-on initial context information, calls the interface of the hardware adaptation module to pass it into the hardware model, obtains initial memory I / O and interrupt information, and completes the initialization of the simulation system.

[0011] Optionally, when the front-end drive triggers a memory I / O write operation, the processing process of the simulation system includes: The backend device module receives an io call callback, sends context information, current memory io interrupt information, and a write io address instruction to the hardware model matching through the backend hardware adaptation module, and sends all memory io and interrupt information to the backend device module for backup and storage; when the backend device module detects a change in the interrupt information, it triggers an interrupt. When it detects a change in the memory io information, it writes the changed information to the memory io address and waits for the next operation of the front end.

[0012] Optionally, when the front-end driver triggers a memory io read operation, the processing process of the simulation system includes: The backend device module receives an io call callback, sends context information, current memory io interrupt information, and a read io address instruction to the hardware model matching through the backend hardware adaptation module, and sends all memory io and interrupt information to the backend device module for backup and storage; when the backend device module detects a change in the interrupt information, it triggers an interrupt. When it detects a change in the memory io information, it writes the changed information to the memory io address and waits for the next operation of the front end.

[0013] According to a second aspect of the present invention, there is provided a model-based Qemu backend driver simulation method, including: constructing and training a hardware model that simulates the behaviors of various types of hardware; the type is the type of hardware for Qemu backend driver simulation; The input data for training the hardware model is the register information and context information input to the hardware when the hardware is called for read / write operations, and the output data of the hardware model is the current state information of the register when the hardware call is completed; When the front-end driver triggers a memory io read / write operation, it sends context information, current memory io interrupt information, and an io read / write address instruction to the hardware model, and uses the output of the hardware model as the output of the Qemu backend driver simulation.

[0014] According to a third aspect of the present invention, there is provided an electronic device, including a memory and a processor, and the processor is used to implement the steps of the model-based Qemu backend driver simulation method when executing a computer management program stored in the memory.

[0015] According to a fourth aspect of the present invention, there is provided a computer-readable storage medium, on which a computer management program is stored, and the computer management program implements the steps of the model-based Qemu backend driver simulation method when executed by a processor.

[0016] A model-based Qemu backend driver simulation system, method, electronic device, and storage medium provided by the present invention reduce the understanding required by developers of the simulated hardware. They only need to understand basic hardware manuals, register usage, etc., and can use scripts to randomly generate values and fill test cases. Complex hardware itself has a very complex state machine management internally, and it is impossible to simulate such hardware comprehensively in the traditional way, and the consistency will be greatly reduced. However, this solution entrusts such complex logic to the model and solves such problems in a very ingenious way. By continuously increasing test cases and iterating the data set, it will become more and more consistent with the hardware, thus achieving a very high degree of consistency and meeting the usage in some fields. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 is a structural block diagram of a model-based Qemu backend driver simulation system provided by the present invention; Figure 2 is a schematic hardware structure diagram of a possible electronic device provided by the present invention; Figure 3 is a schematic hardware structure diagram of a possible computer-readable storage medium provided by the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0018] The principles and features of the present invention are described below with reference to the accompanying drawings. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0019] Figure 1 is a structural block diagram of a model-based Qemu backend driver simulation system provided by the present invention, as Figure 1 shown. The simulation system includes: a backend device module, a backend hardware adaptation module, and a backend model module.

[0020] The backend model module is a hardware model that simulates the behaviors of various types of hardware; the type is the type of hardware for Qemu backend driver simulation.

[0021] The input data for training the hardware model is the register information and context information input to the hardware when the hardware is called for read / write operations, and the output data of the hardware model is the current state information of the register when the hardware call is completed.

[0022] When the backend device module receives a memory io read / write operation triggered by the front-end driver, it sends context information, the current memory io interrupt information, and the io read / write address instruction to the hardware model through the backend hardware adaptation module, and uses the output of the hardware model as the output of the simulation system.

[0023] A model-based Qemu backend driver simulation system provided by the present invention can ensure higher hardware behavior consistency and prevent an individual's understanding of hardware from becoming a bottleneck in the development of Qemu backend drivers.

[0024] Embodiment 1 Embodiment 1 provided by the present invention is an embodiment of a model-based Qemu backend driver simulation system provided by the present invention. Combining Figure 1 it can be seen that the embodiment of this simulation system includes: a backend device module, a backend hardware adaptation module, and a backend model module.

[0025] The backend model module is a hardware model that simulates the behaviors of various types of hardware; the type is the type of hardware for Qemu backend driver simulation.

[0026] The input data for training the hardware model is the register information and context information input to the hardware when the hardware is called for read / write operations, and the output data of the hardware model is the current state information of the register when the hardware call is completed.

[0027] In specific implementation, the context information may be the relevant information of the register during the previous read / write operation.

[0028] In a possible embodiment, the construction process of the dataset of the input data for training the hardware model includes: Based on the composition of the register list in the IP core datasheet of the hardware, multiple register information is generated using a script, and the register information containing context information is obtained through random value screening as test cases.

[0029] The information of each test case is captured through a debugging tool that captures the snapshot information of the memory IO and interrupt information of the hardware IP, and the captured information is used as the dataset. In specific implementation, the dataset content includes snapshot information such as registers, memory, and interrupts of different test cases. The hardware model is trained using the dataset generated by the above test cases, the test case samples are continuously expanded, the collection of the board-end dataset is completed, and the dataset of the model is improved.

[0030] When the backend device module receives a memory io read / write operation triggered by the front-end driver, it sends the context information, the current memory io interrupt information, and the io read / write address instruction to the hardware model through the backend hardware adaptation module, and uses the output of the hardware model as the output of the simulation system.

[0031] In a possible embodiment, the backend device module completes the front-end address request by mapping the device address to the cpu unified addressing bus, and triggers the front-end interrupt by applying for an interrupt from the backend interrupt controller.

[0032] In a possible embodiment, the backend hardware adaptation module is used to adapt to different native hardware environments (NPU, GPU, CPU) and provide an interface for the backend device module to call.

[0033] In a possible embodiment, the initialization process of the simulation system includes: Start Qemu, initialize the backend device module. The backend device module maps the device address to the CPU unified addressing bus, applies for an interrupt from the backend interrupt controller, and calls the backend hardware adaptation module for initialization.

[0034] The backend hardware adaptation module loads the hardware model into the real hardware according to the current hardware environment (NPU, GPU, CPU) to complete the initialization of the backend model module.

[0035] The backend device module provides the power-on initial context information, calls the hardware adaptation module interface to pass in the hardware model, obtains the initial memory I / O and interrupt information, and completes the initialization of the simulation system.

[0036] In a possible embodiment, when the front-end driver triggers a memory I / O write operation, the processing process of the simulation system includes: The backend device module receives the I / O call callback, sends the context information, the current memory I / O interrupt information, and the write I / O address instruction to the hardware model for matching through the backend hardware adaptation module, and sends all the memory I / O and interrupt information to the backend device module for backup and storage; when the backend device module detects a change in the interrupt information, it triggers an interrupt, and when it detects a change in the memory I / O information, it writes the changed information to the memory I / O address and waits for the next front-end operation.

[0037] In a possible embodiment, when the front-end driver triggers a memory I / O read operation, the processing process of the simulation system includes: The backend device module receives the I / O call callback, sends the context information, the current memory I / O interrupt information, and the read I / O address instruction to the hardware model for matching through the backend hardware adaptation module, and sends all the memory I / O and interrupt information to the backend device module for backup and storage; when the backend device module detects a change in the interrupt information, it triggers an interrupt, and when it detects a change in the memory I / O information, it writes the changed information to the memory I / O address and waits for the next front-end operation.

[0038] A model-based Qemu backend driver simulation system provided by an embodiment of the present invention. The backend device module provides context information and front-end requests for the backend adaptation module to perform inference work. The backend hardware adaptation module adapts to different native hardware environments, such as GPUs, NPUs, and CPUs, and is responsible for model initialization and inference work, providing relevant interfaces for the backend device module to call. Finally, the overall simulation solution of the Qemu backend driver is completed using three modules. For the simulation of different hardware devices, the backend device module, the backend hardware adaptation module, and the backend model module correspond one by one. Among them, the backend device module and part of the backend hardware adaptation module can be shared, while the backend model module changes with the hardware model and is completely independent and cannot be shared.

[0039] Embodiment 2 Embodiment 2 provided by the present invention is an embodiment of a model-based Qemu backend driver simulation method provided by the present invention. Combining Figure 2 it can be seen that the embodiments of this simulation method include: constructing and training a hardware model that simulates the behaviors of various types of hardware; the type of hardware is the type of Qemu backend driver simulation.

[0040] The input data for training the hardware model is the register information and context information input to the hardware when the hardware is called for read / write operations, and the output data of the hardware model is the current state information of the register when the hardware call is completed.

[0041] When the front-end driver triggers a memory I / O read / write operation, it sends context information, the current memory I / O interrupt information, and the I / O read / write address instruction to the hardware model, and uses the output of the hardware model as the output of the Qemu backend driver simulation.

[0042] It can be understood that a model-based Qemu backend driver simulation system provided by the present invention corresponds to the model-based Qemu backend driver simulation methods provided in the foregoing embodiments. The relevant technical features of the model-based Qemu backend driver simulation system can refer to the relevant technical features of the model-based Qemu backend driver simulation method, which will not be elaborated here.

[0043] Please refer to Figure 2 , Figure 2 which is a schematic diagram of an embodiment of an electronic device provided by an embodiment of the present invention. As Figure 2As shown in the figure, an embodiment of the present invention provides an electronic device, including a memory 1310, a processor 1320, and a computer program 1311 stored in the memory 1310 and executable on the processor 1320. When the processor 1320 executes the computer program 1311, the following steps are implemented: constructing and training a hardware model that simulates the behaviors of various types of hardware; the type of hardware simulated by the Qemu backend driver; the input data for training the hardware model is the register information and context information input to the hardware when the hardware is called for read / write operations, and the output data of the hardware model is the current state information of the register when the hardware call is completed; when the front-end driver triggers a memory io read / write operation, sending the context information, the current memory io interrupt information, and the io read / write address instruction to the hardware model, and using the output of the hardware model as the output of the Qemu backend driver simulation.

[0044] Please refer to Figure 3 , Figure 3 which is a schematic diagram of an embodiment of a computer-readable storage medium provided by the present invention. As Figure 3 shown in the figure, this embodiment provides a computer-readable storage medium 1400, on which a computer program 1411 is stored. When the computer program 1411 is executed by a processor, the following steps are implemented: constructing and training a hardware model that simulates the behaviors of various types of hardware; the type of hardware simulated by the Qemu backend driver; the input data for training the hardware model is the register information and context information input to the hardware when the hardware is called for read / write operations, and the output data of the hardware model is the current state information of the register when the hardware call is completed; when the front-end driver triggers a memory io read / write operation, sending the context information, the current memory io interrupt information, and the io read / write address instruction to the hardware model, and using the output of the hardware model as the output of the Qemu backend driver simulation.

[0045] A model-based Qemu backend driver simulation system, method, electronic device, and storage medium provided by an embodiment of the present invention reduce the need for developers to understand the simulated hardware. They only need to understand basic hardware manuals, register usage, etc., and can use scripts to randomly generate values and fill in test cases. Complex hardware itself has a very complex state machine management internally. In the traditional way, it is impossible to simulate such hardware in all aspects, and the consistency will be greatly reduced. However, this solution hands over such complex logic to the model to handle and solves such problems in a very ingenious way. By continuously increasing test cases and iterating the data set, it will become more and more consistent with the hardware, thus achieving a very high degree of consistency and meeting the usage in some fields.

[0046] It should be noted that in the above embodiments, the descriptions of the various embodiments have their own focuses. For parts not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0047] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) containing computer-usable program code.

[0048] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to the embodiments of the present invention. It should be understood that each flow and / or block in the flowchart and / or block diagram, as well as the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded computer, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate means for implementing the functions specified in Figure 1 one or more of the processes or multiple processes and / or blocks Figure 1 one or more of the blocks or multiple blocks.

[0049] These computer program instructions can also be stored in a computer-readable memory capable of guiding a computer or other programmable data processing devices to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means, and the instruction means implement the functions specified in Figure 1 one or more of the processes or multiple processes and / or blocks Figure 1 one or more of the blocks or multiple blocks.

[0050] These computer program instructions can also be loaded onto a computer or other programmable data processing devices, such that a series of operation steps are executed on the computer or other programmable devices to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable devices provide steps for implementing the functions specified in Figure 1 one or more of the processes or multiple processes and / or blocks Figure 1 one or more of the blocks or multiple blocks.

[0051] Although the preferred embodiments of the present invention have been described, those skilled in the art can make additional changes and modifications to these embodiments once they learn the basic creative concepts. Therefore, the appended claims are intended to be construed as including the preferred embodiments and all changes and modifications falling within the scope of the present invention.

[0052] Obviously, those skilled in the art can make various modifications and variations to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalent technologies, the present invention also intends to include these modifications and variations.

Claims

1. A model-based Qemu backend driver simulation system, characterized in that: The simulation system includes: a back-end device module, a back-end hardware adaptation module and a back-end model module; The backend model module includes: a hardware model that simulates the behavior of various types of hardware, the type being the type of hardware simulated by the Qemu backend driver; The input data for training the hardware model is the register information and context information input to the hardware when the hardware is called for read / write operations, and the output data of the hardware model is the current state information of the register when the hardware call is completed; When the back-end device module receives the memory IO read / write operation triggered by the front-end driver, the context information, current memory IO interrupt information and IO read / write address instructions are sent to the hardware model through the back-end hardware adapter module, and the output of the hardware model is used as the output of the simulation system.

2. The simulation system according to claim 1, characterized in that The process of constructing a data set of input data for training the hardware model includes: Based on the composition of the register list of the IP core datasheet of the hardware, a script is used to generate multiple register information, and register information containing context information is obtained by random value screening as a use case; Each of the use cases is captured by a debugging tool that captures snapshot information of memory IO and interrupt information of the hardware IP, and the captured information is used as a data set.

3. The simulation system according to claim 1, characterized in that: The back-end device module completes the front-end address request by mapping the device address to the CPU unified addressing bus, and completes the triggering of the front-end interrupt by applying for an interrupt to the back-end interrupt controller.

4. The simulation system according to claim 1, characterized in that: The back-end hardware adaptation module is used to adapt to different local hardware environments and provide an interface called by the back-end device module.

5. The simulation system according to claim 1, characterized in that: The initialization process of the simulation system includes: Start Qemu, initialize the backend device module, map the device address to the CPU unified addressing bus, apply for interrupt to the backend interrupt controller, and call the backend hardware adapter module for initialization; The back-end hardware adaptation module loads the hardware model into the real hardware according to the current hardware environment and completes the initialization of the back-end model module; The back-end device module provides the power-on initial context information to call the hardware adaptation module interface to pass it into the hardware model, obtain the initial memory io and interrupt information, and complete the initialization of the simulation system.

6. The simulation system according to claim 1, characterized in that: When the front-end driver triggers a memory IO write operation, the processing process of the simulation system includes: The back-end device module receives the io call callback, sends context information, current memory io interrupt information and write io address instructions to the hardware model for matching through the back-end hardware adapter module, and sends all memory io and interrupt information to the back-end device module for backup and storage; the back-end device module triggers an interrupt when it detects that the interrupt information has changed, and writes the changed information to the memory io address when it detects that the memory io information has changed, and waits for the next operation of the front-end.

7. The simulation system according to claim 1, characterized in that: When the front-end driver triggers a memory IO read operation, the processing process of the simulation system includes: The back-end device module receives the io call callback, sends context information, current memory io interrupt information and read io address instructions to the hardware model for matching through the back-end hardware adapter module, and sends all memory io and interrupt information to the back-end device module for backup and storage; the back-end device module triggers an interrupt when it detects that the interrupt information has changed, and writes the changed information to the memory io address when it detects that the memory io information has changed, and waits for the next operation of the front-end.

8. A model-based Qemu backend driver simulation method, characterized in that: The simulation method comprises: Build and train hardware models that simulate the behavior of various types of hardware; the types are the types of hardware simulated by the Qemu backend driver; The input data for training the hardware model is the register information and context information input to the hardware when the hardware is called for read / write operations, and the output data of the hardware model is the current state information of the register when the hardware call is completed; When the front-end driver triggers a memory io read / write operation, it sends context information, current memory io interrupt information, and io read / write address instructions to the hardware model, and uses the output of the hardware model as the output of the Qemu back-end driver simulation.

9. An electronic device, characterized in that: It includes a memory and a processor, and the processor is used to implement the steps of the model-based Qemu back-end driver simulation method as claimed in claim 8 when executing the computer management program stored in the memory.

10. A computer-readable storage medium, characterized in that: A computer management program is stored thereon, and when the computer management program is executed by the processor, the steps of the model-based Qemu backend driver simulation method as described in claim 8 are implemented.

Images