Full-system simulation snapshot generation and recovery method

Abstract

The invention discloses a full-system simulation snapshot generation and recovery method. The recovery method comprises a declarative attribute reflection and registration mechanism based on X-Macro; generating a snapshot by adopting a hybrid storage strategy; external resource dynamic reconstruction based on the SetHook is carried out; object life cycle management is seen from the overall process, and snapshot loading is fused into the standard initialization process. According to the method, the get / set accessor and the registration code with the safe type are automatically generated through the preprocessing macro, the code quantity for storing the equipment state is greatly reduced, the equipment structure definition is realized in a declarative manner, and the problem of omission is solved.

Description

Technical Field

[0001] This invention relates to the field of computer simulation and software debugging technology, and in particular to a method for generating and restoring full-system simulation snapshots. Background Technology

[0002] In the fields of embedded system development, chip verification, and operating system debugging, full-system simulators (such as SkyEye, QEMU, and Simics) play a crucial role. Snapshot functionality is one of the core features of a simulator, allowing users to save the current simulation state for restoration at any future time, thus greatly improving debugging efficiency and the flexibility of regression testing.

[0003] The closest existing technology is patent CN120704804A, "A Method and Apparatus for Generating ELF Files Based on Virtual Machine Memory Snapshots." This solution primarily focuses on preserving virtual machine "memory (RAM)" data by dividing the memory into blocks and converting them into ELF file format, supporting debugger loading and analysis. However, this solution is limited to the single resource of "memory." In full-system simulation, the system state includes not only memory data but also numerous peripheral controllers' internal registers, state machine variables, FIFO queue states, etc. Simply saving memory snapshots cannot restore a complete embedded system runtime environment. Furthermore, this solution cannot handle dynamic resources (such as open file handles and network sockets) interacting between the simulation model and the host environment, leading to the failure of external connections after restoration.

[0004] The existing simulation model development suffers from high redundancy in state saving code and difficulty in maintenance.

[0005] The problem of external volatile resources (such as socket connections, file handles, and host threads) becoming invalid after snapshot restoration in full system simulation. Summary of the Invention

[0006] In view of the above problems, the present invention is proposed to provide a method for generating and restoring full-system simulation snapshots to overcome or at least partially solve the above problems.

[0007] According to one aspect of the present invention, a method for generating and restoring full-system simulation snapshots is provided, the restoration method comprising: A declarative property reflection and registration mechanism based on X-Macro; Snapshots are generated using a hybrid storage strategy; Dynamic reconstruction of external resources based on SetterHook; From the overall process perspective, object lifecycle management integrates snapshot loading into the standard initialization process.

[0008] Optionally, the X-Macro-based declarative property reflection and registration mechanism specifically includes: Source code definition phase: In the header file of the device model, developers use the ATTR macro to define the list of device state variables; the macro template is ATTR; where structure: device structure name; variable: member variable; type: attribute type; getter_hook / setter_hook: read and write hook functions; Preprocessing stage: Utilizing the C preprocessor's feature of multiple expansions, the compiler performs two different expansions on the same macro list: Runtime phase: The simulation kernel accesses the internal state of any device through a unified interface by consulting the metadata table, without needing to be aware of the specific implementation of the device.

[0009] Optionally, the compiler performing two different expansions of the same macro list specifically includes: First expansion: The DEF_ATTR_FUNC macro expands the list into accessor functions; the system automatically generates type-safe static get and set functions; The second expansion: The DEF_ATTR_INFO macro expands the list into registration logic. In the device initialization function, a series of SKY_attribute_register calls are automatically generated, binding the attribute names with the generated accessor function pointers and registering them in the emulation kernel's metadata table.

[0010] Optionally, the step of generating snapshots using a hybrid storage strategy specifically includes: Step 101: The emulator receives the instruction and begins the snapshot saving dump operation; Step 102: The system creates the Checkpoint directory; Step 103: The simulation kernel begins to traverse all simulation objects; Step 104: For the current object, retrieve the list of object attributes from the metadata table; Step 105: Traverse the attribute list and determine the type of the current attribute; If the type is Integer, String, or Bool, proceed directly to step 110. If it is a Data type, proceed to step 106; According to the principle of configuration separation, it is strictly forbidden to directly save the dynamic resource handles of the host machine in the device model. Instead, the static configuration parameters required to create these resources should be saved as ordinary attributes. Step 106: Perform a threshold check on Data type attributes: Data size > 4KB? Step 107: If the result is Yes, the system will extract the data and write it to a separate .data file in its original binary format; Step 108: The system automatically generates a relative file path, which is used as the value of this attribute, in preparation for writing it into JSON; Step 109: If the result is "No", the system directly converts the binary data into a Hex string; Step 110: Write the path string generated in Step 108 or the Hex string generated in Step 109, along with the basic data type numeric value, into a JSON field; Step 111: Determine if there is another attribute. If so, return to step 105; if the current object's attributes have been traversed, return to step 103 to process the next object. Step 112: Once all simulation objects have been processed, the snapshot generation is complete.

[0011] Optionally, step 102: the system creates a Checkpoint directory specifically includes: a snapshot is a directory container containing a description file (JSON) and a data file (Binary).

[0012] Optionally, the static configuration parameters specifically include: IP address, port, file path, and reload value.

[0013] Optionally, the simulation object specifically includes: CPU, memory, and peripheral controller.

[0014] Optionally, the dynamic reconstruction of external resources based on SetterHook specifically includes: Snapshot loading: During the snapshot recovery phase, the kernel reads the JSON configuration; Property injection: The kernel calls the automatically generated set function to inject static configuration parameters into the device structure; Hook execution and logic reconstruction: If a hook exists, the function is executed immediately; the hook function contains resource request logic, reads the configuration parameters that have just been restored, calls the host system API, and assigns the newly requested handle, which is valid in the current process, to the runtime variable in the device structure.

[0015] Optionally, the overall process of object lifecycle management, which integrates snapshot loading into the standard initialization process, specifically includes: Normal startup process: Register attributes (Init) -> Allocate memory & default values ​​(New) -> Load user script configuration (Config) -> End normally (Finalize); Snapshot backup process: Init->New->Config->SaveCheckpoint->Finalize; Snapshot recovery process: Init->New->Config->LoadCheckpoint->Finalize.

[0016] This invention provides a method for generating and restoring full-system simulation snapshots. The restoration method includes: a declarative attribute reflection and registration mechanism based on X-Macro; snapshot generation using a hybrid storage strategy; dynamic reconstruction of external resources based on SetterHook; and object lifecycle management from an overall process perspective, integrating snapshot loading into the standard initialization process. This invention significantly reduces the amount of code required for device state saving by automatically generating type-safe get / set accessors and registration code through preprocessing macros, and solves the omission problem by declaratively defining the device structure.

[0017] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a method for generating and restoring a full-system simulation snapshot, as provided in an embodiment of the present invention; Figure 2 A flowchart illustrating the snapshot generation and hybrid storage strategy provided in this embodiment of the invention. Detailed Implementation

[0020] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0021] The terms "comprising" and "having," and any variations thereof, in the specification, embodiments, claims, and drawings of this invention are intended to cover non-exclusive inclusion, such as including a series of steps or units.

[0022] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0023] like Figure 1 As shown, a method for generating and restoring full-system simulation snapshots is provided, wherein the restoration method includes: A declarative property reflection and registration mechanism based on X-Macro; Snapshots are generated using a hybrid storage strategy; Dynamic reconstruction of external resources based on SetterHook; From the overall process perspective, object lifecycle management integrates snapshot loading into the standard initialization process.

[0024] This invention proposes a method for generating and restoring full-system simulation snapshots based on attribute reflection mechanism and hybrid serialization strategy. This method constructs an automated attribute reflection system through macro programming technology and utilizes attribute setting hook mechanism to reconstruct external resources.

[0025] The specific technical solution is as follows: 1. A declarative property reflection and registration mechanism based on X-Macro. To solve the problem of code redundancy, this invention uses declarative definitions to replace traditional manual serialization logic. The working process of this mechanism is as follows: Source code definition phase: In the header file of the device model, developers use the ATTR macro to define the list of state variables of the device.

[0026] Macro template is ATTR(structure, variable, name, type, flag, desc, getter_hook, setter_hook).

[0027] Where structure: device structure name; variable: member variable (e.g., dev->regs); type: attribute type; getter_hook / setter_hook: read and write hook functions.

[0028] Preprocessing stage (automated code generation): Utilizing the C preprocessor's feature of multiple expansions, the compiler performs two different expansions on the same macro list: First expansion (Pass 1): The DEF_ATTR_FUNC macro expands the list into accessor functions. The system automatically generates type-safe static get and set functions. For example, for the Data type, it automatically generates memory copy logic including memcpy(&dev->regs,temp.ptr,temp.size); for the Integer type, it automatically generates code to handle byte order and type conversion.

[0029] Pass 2: The DEF_ATTR_INFO macro expands the list into registration logic. In the device initialization function (init), a series of SKY_attribute_register calls are automatically generated, binding the attribute name (string) to the aforementioned accessor function pointer and registering it in the emulation kernel's metadata table.

[0030] Runtime phase: The simulation kernel can access the internal state of any device through a unified interface by consulting the metadata table, without needing to be aware of the specific implementation of the device.

[0031] 2. Data scale-aware hybrid serialization storage (snapshot generation process) To balance performance and readability, this invention employs a hybrid storage strategy to generate snapshots. For example... Figure 2 As shown, the detailed steps for snapshot generation are as follows: Step 101: The emulator receives the instruction and begins the Dump (snapshot saving) operation.

[0032] Step 102: The system creates the Checkpoint directory. The snapshot is no longer a single large file, but a directory container containing a description file (JSON) and a data file (Binary).

[0033] Step 103: The simulation kernel begins to traverse all simulation objects (such as CPU, memory, peripheral controllers).

[0034] Step 104: For the current object, retrieve the list of object attributes from the metadata table.

[0035] Step 105: Traverse the attribute list and determine the current attribute type.

[0036] If the type is a basic type such as Integer, String, or Bool, proceed directly to step 110.

[0037] If it is of type Data, proceed to step 106.

[0038] According to the principle of configuration separation, it is strictly forbidden to directly save the dynamic resource handles of the host machine (such as SocketFD, FILE*) in the device model. Instead, the static configuration parameters (such as IP address, port, file path, and overload value) required to create these resources should be saved as ordinary attributes.

[0039] Step 106: Perform a threshold check on Data type attributes: Data size > 4KB? Step 107: If the result is Yes (big data, such as RAM image), the system will strip it and write it into a separate .data file (such as ram.data) in its original binary format.

[0040] Step 108: The system automatically generates a relative file path (e.g., ". / ram.data") as the value of this attribute, ready to be written to JSON.

[0041] Step 109: If the result is No (small data, such as FIFO queue, register group), the system directly converts the binary data into a Hex string (such as "0xA1B2...").

[0042] Step 110: Write the path string generated in Step 108 or the Hex string generated in Step 109, along with basic data types, into a JSON field. This ensures the lightweight and readable nature of the main configuration file.

[0043] Step 111: Determine if there is another attribute. If so, return to step 105; if the current object's attributes have been traversed, return to step 103 to process the next object.

[0044] Step 112: Once all simulation objects have been processed, the snapshot generation is complete.

[0045] 3. Dynamic reconstruction of external resources based on SetterHook (snapshot recovery process) To recover external volatile resources, this invention utilizes a callback mechanism during the attribute recovery process to achieve logical reconstruction. Its working process is similar to, but reverses, the generation process described above: Snapshot loading: During the snapshot recovery phase, the kernel reads the JSON configuration.

[0046] Attribute injection: The kernel calls the automatically generated set function to inject static configuration parameters (such as IP and port) into the device structure.

[0047] Hook execution (logic reconstruction): If a hook exists, this function is executed immediately. The hook function contains resource allocation logic. It reads the configuration parameters that have just been restored, calls the host system APIs (such as connect(), fopen(), pthread_create()), and assigns the newly acquired, valid handle / FD in the current process to the runtime variable in the device structure.

[0048] Example: When restoring the timer, the snapshot only restores "reload value = 100ms" and "control register = Enable". After the set function of the "control register" is executed, setter_hook is triggered. This hook detects that the Enable bit is 1, and then uses the 100ms reload value to re-call pthread_create to start the host timer thread.

[0049] 4. From the perspective of the overall process, object lifecycle management integrates snapshot loading into the standard initialization process to ensure the consistency of object state.

[0050] Normal startup process: Init (register attributes) -> New (allocate memory & default values) -> Config (load user script configuration) -> Finalize (normal termination).

[0051] Snapshot backup process: Init->New->Config->SaveCheckpoint (triggers getters for all properties, generates snapshots according to steps 101-112)->Finalize.

[0052] Snapshot recovery process: Init->New->Config->LoadCheckpoint (reads the snapshot, triggers SetterHook to rebuild resources)->Finalize.

[0053] This addresses the issues of high redundancy and maintenance difficulties in state saving code during existing simulation model development, and eliminates the risk of state loss due to human error.

[0054] This addresses the issue of external volatile resources (such as socket connections, file handles, and host threads) becoming invalid after snapshot restoration during full-system simulation, enabling logical reconnection of the simulation environment.

[0055] To resolve the conflict between storage efficiency and readability of snapshot files, it is necessary to support high-speed read and write of large memory capacity while also supporting manual reading and modification of register-level configurations, and to retain maximum compatibility.

[0056] Beneficial effects: An automated attribute registration method built using X-Macro: Unlike existing technologies, this invention automatically generates type-safe get / set accessors and registration code through preprocessing macros, significantly reducing the amount of code for storing device state, and solves the omission problem by declaratively implementing device structure definition.

[0057] Threshold-based hybrid serialization storage architecture: This invention dynamically determines the storage strategy based on the data size (e.g., a 4KB threshold). Small data is stored as JSON to facilitate manual debugging and script modification, while large data is stored as Raw Binary to take advantage of the operating system's efficient I / O and support differential processing, significantly improving the read and write speed of GB-level memory snapshots.

[0058] Resource Reconstruction Mechanism Based on Setter Hook: This invention proposes a mechanism of "saving configuration parameters + hook-triggered reconstruction". By triggering a callback immediately after the attribute value is restored, the restored static parameters are used to re-request dynamic resources on the host machine, achieving environment independence of snapshots and logical reconnection. Furthermore, this mechanism improves version compatibility, independent of internal structure definitions and subsequent possible changes.

[0059] The above specific embodiments further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for generating and restoring full-system simulation snapshots, characterized in that, The recovery method includes: A declarative property reflection and registration mechanism based on X-Macro; Snapshots are generated using a hybrid storage strategy; Dynamic reconstruction of external resources based on SetterHook; From the overall process perspective, object lifecycle management integrates snapshot loading into the standard initialization process.

2. The method for generating and restoring a full-system simulation snapshot according to claim 1, characterized in that, The X-Macro-based declarative property reflection and registration mechanism specifically includes: Source code definition phase: In the header file of the device model, developers use the ATTR macro to define the list of device state variables; the macro template is ATTR; where structure: device structure name; variable: member variable; type: attribute type; getter_hook / setter_hook: read and write hook functions; Preprocessing stage: Utilizing the C preprocessor's feature of multiple expansions, the compiler performs two different expansions on the same macro list: Runtime phase: The simulation kernel accesses the internal state of any device through a unified interface by consulting the metadata table, without needing to be aware of the specific implementation of the device.

3. The method for generating and restoring a full-system simulation snapshot according to claim 2, characterized in that, The compiler performs two different expansions of the same macro list, specifically including: First expansion: The DEF_ATTR_FUNC macro expands the list into accessor functions; the system automatically generates type-safe static get and set functions; The second expansion: The DEF_ATTR_INFO macro expands the list into registration logic. In the device initialization function, a series of SKY_attribute_register calls are automatically generated, binding the attribute names with the generated accessor function pointers and registering them in the emulation kernel's metadata table.

4. The method for generating and restoring a full-system simulation snapshot according to claim 1, characterized in that, The specific steps of generating snapshots using a hybrid storage strategy include: Step 101: The emulator receives the instruction and begins the snapshot saving dump operation; Step 102: The system creates the Checkpoint directory; Step 103: The simulation kernel begins to traverse all simulation objects; Step 104: For the current object, retrieve the list of object attributes from the metadata table; Step 105: Traverse the attribute list and determine the type of the current attribute; If the type is Integer, String, or Bool, proceed directly to step 110. If it is a Data type, proceed to step 106; According to the principle of configuration separation, it is strictly forbidden to directly save the dynamic resource handles of the host machine in the device model. Instead, the static configuration parameters required to create these resources should be saved as ordinary attributes. Step 106: Perform a threshold check on Data type attributes: Data size > 4KB? Step 107: If the result is Yes, the system will extract the data and write it to a separate .data file in its original binary format; Step 108: The system automatically generates a relative file path, which is used as the value of this attribute, in preparation for writing it into JSON; Step 109: If the result is "No", the system directly converts the binary data into a Hex string; Step 110: Write the path string generated in Step 108 or the Hex string generated in Step 109, along with the basic data type numeric value, into a JSON field; Step 111: Determine if there is another attribute. If so, return to step 105; if the current object's attributes have been traversed, return to step 103 to process the next object. Step 112: Once all simulation objects have been processed, the snapshot generation is complete.

5. The method for generating and restoring a full-system simulation snapshot according to claim 4, characterized in that, Step 102: The system creates the Checkpoint directory, which specifically includes: A snapshot is a directory container containing a JSON description file and a Binary data file.

6. The method for generating and restoring a full-system simulation snapshot according to claim 4, characterized in that, The static configuration parameters specifically include: IP address, port, file path, and reload value.

7. The method for generating and restoring a full-system simulation snapshot according to claim 4, characterized in that, The simulation objects specifically include: CPU, memory, and peripheral controller.

8. The method for generating and restoring full-system simulation snapshots according to claim 1, characterized in that, The dynamic reconstruction of external resources based on SetterHook specifically includes: Snapshot loading: During the snapshot recovery phase, the kernel reads the JSON configuration; Property injection: The kernel calls the automatically generated set function to inject static configuration parameters into the device structure; Hook execution and logic reconstruction: If a hook exists, the function is executed immediately; the hook function contains resource request logic, reads the configuration parameters that have just been restored, calls the host system API, and assigns the newly requested handle, which is valid in the current process, to the runtime variable in the device structure.

9. The method for generating and restoring a full-system simulation snapshot according to claim 1, characterized in that, The overall process of object lifecycle management, which integrates snapshot loading into the standard initialization process, specifically includes: Normal startup process: Register attributes (Init) -> Allocate memory & default values ​​(New) -> Load user script configuration (Config) -> End normally (Finalize); Snapshot backup process: Init->New->Config->SaveCheckpoint->Finalize; Snapshot recovery process: Init->New->Config->LoadCheckpoint->Finalize.

Images