Peripheral dynamic loading and bus interconnection modeling method based on QEMU proxy API

Abstract

The application discloses a peripheral dynamic loading and bus interconnection modeling method based on QEMUProxyAPI and belongs to the field of hardware modeling.The peripheral dynamic loading and bus interconnection modeling method based on QEMUProxyAPI comprises the following steps: establishing a ProxyAPI interface layer;constructing a device loading and topology management layer;creating and realizing devices in sequence according to a dependency relationship;automatically constructing a system topology and address mapping;realizing master-slave device interconnection;and realizing automatic signal connection.The application solves the problems that the prior art is prone to causing incompatible plug-ins, is difficult to realize module reuse, seriously affects maintenance and transplantation, and lacks rapid iteration capability.The application realizes cross-platform peripheral modeling interface standardization, guarantees that devices are connected on correct buses, enables IRQ / GPIO to be directly bound through names, improves the readability and maintainability of a system, and realizes cross-platform compatibility.

Description

Technical Field

[0001] This invention relates to the field of hardware modeling technology, specifically to a method for dynamic loading of peripherals and bus interconnection modeling based on QEMUProxyAPI. Background Technology

[0002] Currently, QEMU is widely used in the virtualization and verification of embedded systems and operating systems, but its peripheral extension mechanism has significant shortcomings: Static compilation mode: Peripheral models need to be directly compiled into the QEMU core, requiring developers to modify the source code and recompile, resulting in poor extensibility and a long development cycle; Semi-dynamic plug-in mode: Although some devices support plug-in loading, the lack of a unified API specification leads to incompatibility between plug-ins in register mapping, bus connections, and IRQ / GPIO management, making module reuse difficult; Inconsistent configuration: Existing QEMU lacks a unified board-level topology configuration description file, requiring device connection relationships (such as interrupts, GPIO, SPI / I2C buses) to be hard-coded into the source code, severely impacting maintenance and portability; Poor platform reusability: Driver adaptation needs to be implemented repeatedly under different operating systems or hardware platforms; Long debugging and verification cycle: After peripheral model modification, the QEMU core must be recompiled for verification, lacking rapid iteration capabilities.

[0003] Therefore, it does not meet the existing requirements. In response, we propose a method for dynamic loading of peripherals and bus interconnection modeling based on QEMUProxyAPI. Summary of the Invention

[0004] The purpose of this invention is to provide a method for dynamic loading and bus interconnection modeling of peripherals based on QEMUProxyAPI. Peripherals are developed and loaded as independent modules, avoiding the need to recompile QEMU. By providing a unified device API covering operations such as device creation, destruction, MMIO registration and mapping, IRQ / GPIO export and connection, and SPI / I2C bus connection, the invention standardizes the cross-platform peripheral modeling interface. It uses JSON files to describe the board-level hardware topology, automatically parses and constructs device dependencies and connection relationships, and uses a delayed realization mechanism for SPI / I2C master and slave devices to ensure that slave devices are connected to the correct bus. It uses hash tables to achieve signal name-level interconnection, supports named signal mapping, and allows IRQ / GPIO to be directly bound by name, improving system readability and maintainability. It supports dynamic loading interfaces for Linux and Windows platforms, achieving cross-platform compatibility and solving the problems mentioned in the background.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a method for dynamic loading of peripherals and bus interconnection modeling based on QEMUProxyAPI, comprising the following steps:

[0006] S1: Establish a unified ProxyAPI interface layer to define the communication and interaction specifications between the QEMU emulator and peripheral plug-ins;

[0007] S2. Construct a device loading and topology management layer. Use the device loading and topology management layer to parse the topology configuration file and load peripheral modules. Read the board.json file, extract the peripheral module path and device description information, use the dynamic library loading mechanism to load the corresponding peripheral module, and call its initialization function to complete register registration and interface export, forming a list of device objects and dependent topology relationships.

[0008] S3: Create and realize devices in the order of dependencies. According to the topology, device_create and device_realize are executed sequentially from the upper controller to the lower slave device.

[0009] S4: Automatically constructs system topology and address mapping, performs address mapping according to the mmio field in the configuration file, and automatically calls mmio_map to map the register area to the specified address;

[0010] S5: Master-slave device interconnection is achieved through a delayed realization mechanism. After the master device bus is created, the slave device module calls the spi_slave_register or i2c_slave_register interface to register itself, and attaches to the specified bus through the spi_attach_slave or i2c_attach interface.

[0011] S6: Automatic signal connection is achieved based on named signal mapping. By maintaining a hash table of IRQ / GPIO names and indices, the hash tables are IRQ_name_map and GPIO_name_map. During the connection phase, cross-module naming binding is achieved through IRQ_connect and GPIO_connect.

[0012] Preferably, the ProxyAPI interface layer specifically includes:

[0013] The device management interface is used for the creation, instantiation, destruction, and reset management of devices.

[0014] The register and memory mapping management interface is used to register the register area through mmio_register and map it to the system bus address space through mmio_map.

[0015] Interrupt and GPIO management interface, used to export signal ports through IRQ_export_named and GPIO_export_named, and to connect signals between devices through IRQ_connect and GPIO_connect;

[0016] The bus interface management interface is used to interconnect various peripheral buses through the spi_bus_create, spi_attach_slave, i2c_bus_create, and i2c_attach interfaces;

[0017] The debugging and logging mechanism interface is used to provide a unified log output interface to achieve unified recording of device behavior, connection status, and errors.

[0018] Preferably, the device loading and topology management layer specifically includes:

[0019] JSON file parsing: Parse the modules, devices, and connections fields in the configuration file layer to read peripheral module paths, device types, address mappings, role information, and interconnection relationships;

[0020] Dynamic loading of peripheral modules: The corresponding peripheral dynamic library is loaded according to the path through the dynamic linking function dlopen or LoadLibrary;

[0021] Call the initialization function: Automatically execute the initialization interface plugin_device_init_v1 in the peripheral dynamic library exported by the plug-in peripheral model, and complete device register registration, IRQ / GPIO export and bus interface creation;

[0022] Dependency sorting and sequential realization: Devices are loaded in dependency order using a depth-first traversal mechanism, ensuring that controller devices are initialized before slave devices;

[0023] Delayed realization mechanism: The slave device is only connected to the corresponding bus instance after the bus is created, so as to achieve correct master-slave interconnection;

[0024] Preferably, the plug-in peripheral model specifically includes:

[0025] During the device registration phase, mmio_register is called to register the register area, and the initial values ​​of the registers are set in the reset function;

[0026] Export signal ports using IRQ_export_named and GPIO_export_named for automatic matching during board-level connection.

[0027] Peripheral interconnection is achieved through functions such as spi_bus_create and i2c_attach;

[0028] When the master device triggers a transmission, the plug-in layer achieves cross-module data exchange through the spi_transfer and i2c_msg_xfer interfaces.

[0029] Preferably, the configuration file layer specifically includes: a module path, used to define the file locations of all peripheral dynamic libraries; a device list, used to describe the device type, ID, module to which it belongs, register mapping address, and role information; and a connection relationship, used to define the interconnection method of IRQ and GPIO.

[0030] Preferably, the configuration of the device management interface specifically includes:

[0031] Create a bus instance, and call the spi_bus_create and i2c_bus_create interfaces respectively for different bus types. The interface calls the kernel bus initialization function.

[0032] Create a bus object, configure the clock frequency, transmission mode and address width, register the bus instance to the ProxyAPI bus management list and assign a unique identifier.

[0033] The device is associated with the specified bus through the spi_attach_slave and i2c_attach interfaces. After association, bus read and write operations are transparently forwarded through ProxyAPI.

[0034] When the master device initiates a request, the kernel locates the target ProxyDevice through the bus object, and the ProxyAPI forwards the request to the device and returns the data.

[0035] Preferably, the configuration of the register and memory mapping management interface specifically includes:

[0036] Register area registration is completed by calling the mmio_register interface based on the register base address, length, access permissions, and operation callback function.

[0037] After receiving the parameters, ProxyAPI creates an MMIO region descriptor, binds the register base address, length, access permissions, and operation callback function to the corresponding ProxyDevice, and verifies the validity of the register address;

[0038] Address mapping is performed through the mmio_map interface, which calls the QEMU kernel's address_space_map function to map the registered MMIO region to the specified address segment of the system bus.

[0039] After the mapping is complete, when the kernel accesses the device via the bus address, the MMU automatically performs address translation and triggers the callback function associated with ProxyDevice.

[0040] Preferably, the configuration of the interrupt and GPIO management interface specifically includes:

[0041] The device specifies the signal type, port name, direction, and initial state through the IRQ_export_named and GPIO_export_named interfaces;

[0042] Device associations are established through the IRQ_connect and GPIO_connect interfaces. When the connection is interrupted, the interface receives the interrupt source port name and the target device callback function, and binds the two through the kernel interrupt controller interface.

[0043] When a device triggers an interrupt, the ProxyAPI is notified, and the ProxyDevice forwards the signal to the target device's callback function to trigger interrupt handling.

[0044] Preferably, the dependency relationship is implemented through depth-first traversal, specifically including:

[0045] Extract the relationship description between the devices and connections fields in the core dependency board.json;

[0046] After extraction, a triplet data structure containing device ID, device type, and a list of dependent devices is generated, where the dependency list of devices without dependencies is empty;

[0047] Adjacency lists are used as the storage medium to convert the extracted dependencies into a directed graph data structure.

[0048] Using the controller device without dependencies as the root node, the system recursively traverses all its downstream dependent devices to generate a device instantiation sequence sorted by master-slave and upstream-downstream order.

[0049] Based on the instantiation sequence generated by traversal, the management layer executes device_create and device_realize operations, while ensuring the correctness of the initialization order through a differentiated strategy of immediate instantiation and delayed instantiation.

[0050] Preferably, the two hash tables, IRQ_name_map and GPIO_name_map, store the correspondence between signal names and hardware indices. The specific implementation and adaptation logic are as follows:

[0051] Both IRQ_name_map and GPIO_name_map adopt a chained hash structure design. The key of the hash table is the business name of the signal, and the value is the underlying hardware index corresponding to the signal. The number of buckets in the hash table is dynamically configured based on the maximum number of signals supported by the system.

[0052] The DJB hash algorithm is used to perform hash calculation on the signal name, and the result is modulo the number of buckets to obtain the bucket position of the signal in the hash table;

[0053] If a hash collision occurs, the storage is extended backwards using linked list nodes. During retrieval, the target hardware index can be matched by traversing the linked list of the corresponding bucket using the signal name.

[0054] Compared with the prior art, the beneficial effects of the present invention are:

[0055] The peripherals of this invention are developed and loaded as independent modules, avoiding the need to recompile QEMU. By providing a unified device API covering operations such as device creation, destruction, MMIO registration and mapping, IRQ / GPIO export and connection, and SPI / I2C bus connection, it achieves standardized cross-platform peripheral modeling interfaces. By using JSON files to describe board-level hardware topology, it automatically parses and constructs device dependencies and connection relationships. Through the delayed realization mechanism of SPI / I2C master and slave devices, it ensures that slave devices are connected to the correct bus. It uses hash tables to achieve signal name-level interconnection and supports named signal mapping, allowing IRQ / GPIO to be directly bound by name, improving system readability and maintainability. It supports dynamic loading interfaces for Linux and Windows platforms, achieving cross-platform compatibility. Attached Figure Description

[0056] Figure 1 This is a system architecture diagram of the peripheral dynamic loading and bus interconnection modeling method based on QEMUProxyAPI of the present invention;

[0057] Figure 2 This is a flowchart illustrating the device loading process of the QEMUProxyAPI-based peripheral dynamic loading and bus interconnection modeling method of the present invention.

[0058] Figure 3 This is a flowchart of the master-slave connection process of the present invention. Detailed Implementation

[0059] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0060] To address the issues of poor scalability, long development cycles, incompatibility between plugins in register mapping, bus connectivity, and IRQ / GPIO management, hindering module reuse, severely impacting maintenance and portability, and lacking rapid iteration capabilities in existing technologies, please refer to [link to relevant documentation]. Figures 1-2 This embodiment provides the following technical solution:

[0061] The method for dynamic loading of peripherals and bus interconnect modeling based on QEMUProxyAPI includes the following steps:

[0062] S1: Establish a unified ProxyAPI interface layer to define the communication and interaction specifications between the QEMU emulator and peripheral plug-ins;

[0063] S2. Construct a device loading and topology management layer. Use the device loading and topology management layer to parse the topology configuration file and load peripheral modules. Read the board.json file, extract the peripheral module path and device description information, use the dynamic library loading mechanism to load the corresponding peripheral module, and call its initialization function to complete register registration and interface export, forming a list of device objects and dependent topology relationships.

[0064] S3: Create and realize devices in the order of dependencies. According to the topology, device_create and device_realize are executed sequentially from the upper-level controller to the lower-level slave device. During this process, only the master device is realized immediately, while the slave device is attached after the bus is available. This ensures that the system initialization order is correct and avoids uninitialized or circular dependencies.

[0065] S4: Automatically constructs system topology and address mapping, performs address mapping according to the mmio field of the configuration file, automatically calls mmio_map to map the register area to the specified address, forms a complete virtual address space layout, and establishes the interconnection relationship between peripherals in the system;

[0066] S5: Master-slave device interconnection is achieved through a delayed realization mechanism. After the master device bus is created, the slave device module calls the spi_slave_register or i2c_slave_register interface to register itself, and attaches to the specified bus through the spi_attach_slave or i2c_attach interface, ensuring that the master and slave devices establish a communication channel in the correct bus and realizing automated bus connection.

[0067] S6: Automatic signal connection is achieved based on named signal mapping. By maintaining hash tables of IRQ / GPIO names and indices, namely IRQ_name_map and GPIO_name_map, cross-module named binding is achieved through IRQ_connect and GPIO_connect during the connection phase, without the need for manual maintenance of port numbers. This achieves a highly readable and reconfigurable signal interconnection mechanism, reducing errors and redundant configurations.

[0068] The ProxyAPI interface layer specifically includes:

[0069] The ProxyAPI interface layer defines a unified communication interface between QEMU and peripheral plug-ins, responsible for abstracting device lifecycle, register access, signal interconnection, and bus communication logic.

[0070] The device management interface is used for device creation (device_create), instantiation (device_realize), destruction (device_destroy), and reset management.

[0071] The register and memory mapping management interface is used to register the register area through mmio_register and map it to the system bus address space through mmio_map.

[0072] Interrupt and GPIO management interface, used to export signal ports through IRQ_export_named and GPIO_export_named, and to connect signals between devices through IRQ_connect and GPIO_connect;

[0073] The bus interface management interface is used to interconnect various peripheral buses through the spi_bus_create, spi_attach_slave, i2c_bus_create, and i2c_attach interfaces;

[0074] The debugging and logging mechanism interface is used to provide a unified log output interface to achieve unified recording of device behavior, connection status, and errors;

[0075] Based on a unified log output interface, a full-process logging system is built. The device and ProxyAPI output logs through this interface, specifying the levels of debug, information, warning, and error.

[0076] After receiving parameters, the interface automatically adds metadata such as timestamp, device identifier, and module name to form structured log content.

[0077] Logs are output to the console, log files, or remote debugging tools according to system configuration rules. For critical scenarios (such as device_realize instantiation failure, connection interruption exception, bus transmission error), the ProxyAPI automatically triggers logging without requiring additional calls on the device side. Dynamic configuration is also supported, allowing adjustment of log levels and output methods via QEMU command-line parameters or runtime interfaces to balance debugging needs and performance overhead.

[0078] The device calls the newly added periodic_task_register interface of ProxyAPI, passing in the task name, period duration, priority, and execution callback function;

[0079] After receiving the interface, a periodic task descriptor is created, the parameter information is recorded and bound to the ProxyDevice, the period duration is verified (not less than the system's minimum scheduling unit), and the tasks are classified and sorted according to priority to prepare for scheduling and execution.

[0080] The task descriptor contains core information such as status identifier and next execution timestamp, and is managed uniformly by ProxyAPI. For tasks with high precision requirements, the interface supports specifying a time base to adapt to the real-time requirements of different devices.

[0081] When the ProxyAPI is initialized, it registers a periodic scheduler with the QEMU Main Event Loop. This scheduler polls all registered periodic tasks at fixed time intervals (e.g., 1ms).

[0082] The core logic of polling is to compare the next execution timestamp of the task with the current system time. When the timestamp is less than or equal to the current time, the task execution callback function is triggered immediately. After the execution is completed, the next execution timestamp is updated according to the periodic duration.

[0083] If the task execution time exceeds the set threshold, the system will automatically output a warning log and mark the task as timed out;

[0084] For high-priority tasks such as real-time data processing, the scheduler adopts a preemptive strategy to execute them first. It relies on the mature scheduling capabilities of the kernel and uses the ProxyAPI to encapsulate and modularize task management, avoiding the complexity of devices directly operating the kernel interface.

[0085] The full lifecycle management of tasks is achieved through the periodic_task_modify (modify the period), periodic_task_pause (pause), periodic_task_resume (resume), and periodic_task_unregister (unregister) interfaces. After data collection is completed, resources are released using periodic_task_unregister. The core of the interface is to synchronously update the task descriptor status and time parameters to the scheduler.

[0086] When the device's lifecycle ends, the device_destroy interface is called to execute the resource reclamation, state cleanup, and object deletion process: first, hardware resources and memory are released, the ProxyDevice is removed from the ProxyAPI device list, and finally, object_unref is called to release kernel object references to avoid memory leaks; if the device is associated with a periodic task, the task will be automatically deregistered to ensure that resources are completely released.

[0087] The ProxyAPI interface layer, based on standardized APIs, completes the entire process management of devices from creation, interconnection, operation monitoring to periodic task scheduling. Each step is interconnected, with ProxyDevice as the core link. It breaks the coupling between devices and the kernel, supports modular peripheral modeling, and ensures the debuggability and stability of the system through logging and dynamic control mechanisms, becoming a key support for the QEMU modular architecture.

[0088] The ProxyAPI interface layer within QEMU handles interface dispatch and callbacks by registering proxy objects (ProxyDevice). During runtime, devices can directly interact with the emulation kernel via the API, enabling modular peripheral modeling.

[0089] Device loading and topology management layer, specifically including:

[0090] The device loading and topology management layer is implemented by the proxy_board_loader.c module, which is used to parse the board-level topology configuration file (board.json) and automatically complete the loading of pluggable peripheral modules, dependency resolution, and device instantiation.

[0091] JSON file parsing: Parse the modules, devices, and connections fields in the configuration file layer to read peripheral module paths, device types, address mappings, role information, and interconnection relationships;

[0092] Dynamic loading of peripheral modules: The corresponding peripheral dynamic library is loaded according to the path through the dynamic linking function dlopen or LoadLibrary;

[0093] Call the initialization function: Automatically execute the initialization interface plugin_device_init_v1 in the peripheral dynamic library exported by the plug-in peripheral model, and complete device register registration, IRQ / GPIO export and bus interface creation;

[0094] Dependency sorting and sequential realization: Devices are loaded in dependency order through depth-first traversal (DFS) mechanism, so that controller devices (such as spimaster, i2ccontroller) are initialized before slave devices;

[0095] Delayed realization mechanism: The slave device is only connected to the corresponding bus instance after the bus is created, so as to achieve correct master-slave interconnection;

[0096] The device loading and topology management layer outputs a complete virtual system topology structure, which serves as the basis for QEMU simulation operation.

[0097] The plug-in peripheral model specifically includes:

[0098] The pluggable peripheral model exists in the form of dynamic libraries (such as spi_master.so and spi_slave.so). Each module contains device structure definition, register read / write logic, state machine implementation, and interrupt triggering mechanism.

[0099] The pluggable peripheral model performs the following operations through the ProxyAPI interface layer:

[0100] During the device registration phase, mmio_register is called to register the register area, and the initial values ​​of the registers are set in the reset function;

[0101] Export signal ports using IRQ_export_named and GPIO_export_named for automatic matching during board-level connection.

[0102] Peripheral interconnection is achieved through functions such as spi_bus_create and i2c_attach;

[0103] When the master device triggers a transmission, the plug-in layer achieves cross-module data exchange through the spi_transfer and i2c_msg_xfer interfaces.

[0104] The plug-in peripheral model design makes the peripheral logic independent of the QEMU kernel, and can be updated or replaced individually, achieving a high degree of reusability in peripheral modeling.

[0105] The configuration file layer specifically includes: module paths, which define the file locations of all peripheral dynamic libraries; a device list, which describes the device type, ID, module, register mapping address, and role information; and connection relationships, which define the interconnection methods of IRQ and GPIO. The configuration file is parsed by the loading layer when the system starts up, and device object instances are generated through structured mapping. Each connection relationship can be bound by signal name, achieving high readability and flexible configuration management.

[0106] The configuration of the device management interface includes:

[0107] Create a bus instance, and call the spi_bus_create and i2c_bus_create interfaces respectively for different bus types. The interface calls the kernel bus initialization function.

[0108] Create a bus object, configure the clock frequency, transmission mode and address width, register the bus instance to the ProxyAPI bus management list and assign a unique identifier.

[0109] The device is associated with the specified bus through the spi_attach_slave and i2c_attach interfaces. After association, bus read and write operations are transparently forwarded through ProxyAPI.

[0110] When the master device initiates a request, the kernel locates the target ProxyDevice through the bus object, and the ProxyAPI forwards the request to the device and returns the data, realizing multi-device collaboration. The device types are proxy-sysbus-device and proxy-spi-slave.

[0111] The configuration of the register and memory mapping management interface specifically includes:

[0112] Register area registration is completed by calling the mmio_register interface based on the register base address, length, access permissions, and operation callback function.

[0113] After receiving the parameters, ProxyAPI creates an MMIO region descriptor, binds the register base address, length, access permissions, and operation callback function to the corresponding ProxyDevice, and verifies the validity of the register address to avoid address conflicts.

[0114] Address mapping is performed through the mmio_map interface, which calls the QEMU kernel's address_space_map function to map the registered MMIO region to the specified address segment of the system bus.

[0115] After the mapping is completed, when the kernel accesses the device through the bus address, the MMU automatically completes the address translation and triggers the callback function associated with ProxyDevice, realizing a closed-loop interaction of kernel bus access, ProxyAPI forwarding and device register response.

[0116] The configuration of interrupt and GPIO management interfaces includes:

[0117] The device specifies the signal type, port name, direction and initial state through the IRQ_export_named and GPIO_export_named interfaces. The ProxyAPI creates a signal descriptor for each exported port, associates it with the ProxyDevice, and registers the port information with the kernel signal management center. The naming mechanism ensures the uniqueness of the port.

[0118] Device associations are established through the IRQ_connect and GPIO_connect interfaces. When the connection is interrupted, the interface receives the interrupt source port name and the target device callback function, and binds the two through the kernel interrupt controller interface.

[0119] When the device triggers an interrupt, the ProxyAPI is notified, and the ProxyDevice forwards the signal to the target device callback function to trigger interrupt handling, thus realizing the signal relay for input data reading and output status control.

[0120] Dependencies are implemented using depth-first traversal, specifically including:

[0121] Extract the relationship description between the devices and connections fields in the core dependency board.json;

[0122] After extraction, a triplet data structure containing device ID, device type, and a list of dependent devices is generated, where the dependency list of devices without dependencies is empty;

[0123] Adjacency lists are used as the storage medium to convert the extracted dependencies into a directed graph data structure.

[0124] Using the controller device without dependencies as the root node, the system recursively traverses all its downstream dependent devices to generate a device instantiation sequence sorted by master-slave and upstream-downstream order.

[0125] Based on the instantiation sequence generated by traversal, the management layer executes device_create and device_realize operations, while ensuring the correctness of the initialization order through a differentiated strategy of immediate instantiation and delayed instantiation;

[0126] In this process, the instantiation of all slave devices lags behind that of their dependent controller devices, completely avoiding the problem of bus connection failure caused by slave device initialization in traditional manual coding, and ensuring the absolute correctness of the initialization order under complex bus topologies.

[0127] The IRQ_name_map and GPIO_name_map hash tables store the mapping between signal names and hardware indices. The specific implementation and adaptation logic are as follows:

[0128] Both IRQ_name_map and GPIO_name_map adopt a chained hash structure design. The key of the hash table is the business name of the signal, and the value is the underlying hardware index corresponding to the signal. The number of buckets in the hash table is dynamically configured based on the maximum number of signals supported by the system, with a default of 31 buckets (a prime number of buckets can reduce the probability of hash collisions).

[0129] The DJB hash algorithm is used to perform hash calculation on the signal name, and the result is modulo the number of buckets to obtain the bucket position of the signal in the hash table;

[0130] If a hash collision occurs, the storage is extended backward through linked list nodes. During retrieval, the target hardware index can be matched by traversing the linked list of the corresponding bucket by the signal name. The retrieval time complexity of a single signal is stable at O(1), and O(k) in the collision scenario, where k is the number of collision nodes. In practical applications, the value of k approaches 1.

[0131] Hash tables support dynamic updates, which are achieved through dedicated mapping maintenance interfaces, including the add interface (IRQ_map_add / GPIO_map_add), which is used to add signal names and hardware index mappings to the hash table. When calling the add interface, it is necessary to first check whether the signal name already exists to avoid conflicts caused by duplicate mappings.

[0132] The modify interface (IRQ_map_modify / GPIO_map_modify) is used to update the hardware index corresponding to the existing signal name, and supports real-time adjustment of the mapping relationship during system operation without restarting the simulation system;

[0133] The delete interface (IRQ_map_delete / GPIO_map_delete) is used to delete invalid signal mapping entries and release hash table memory resources.

[0134] All the aforementioned interfaces have parameter validity verification capabilities, returning explicit error codes for illegal inputs such as empty signal names or out-of-range hardware indexes, ensuring the integrity and accuracy of the hash table data. When the hardware topology changes, adaptation can be completed in only two ways: If the system is not running, developers can directly modify the signal mapping description in the connections field of the board-level configuration file board.json. When the device loading and topology management layer parses the configuration file in step 2, it will automatically call the add interface to write the updated signal names and hardware index mappings into the hash table; If the system is running, a mapping update command can be sent through the QEMU monitoring interaction interface. The command is forwarded through the ProxyAPI interface layer and triggers the modify interface to execute, updating the corresponding entries in IRQ_name_map in real time. The entire adaptation process does not require modification of peripheral plugin code or recompilation of the QEMU kernel and peripheral dynamic libraries. It can be completed solely through configuration adjustments or runtime commands, completely solving the pain point of traditional modeling methods where hardware topology changes require full modification of related code. The adaptation time is reduced from several hours in traditional methods to minutes, significantly improving the maintainability and responsiveness of the virtual system.

[0135] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "include," "contain," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0136] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention.

Claims

1. A method for dynamic loading of peripherals and bus interconnection modeling based on QEMUProxyAPI, characterized in that, Includes the following steps: S1: Establish a unified ProxyAPI interface layer to define the communication and interaction specifications between the QEMU emulator and peripheral plug-ins; S2. Construct a device loading and topology management layer. Use the device loading and topology management layer to parse the topology configuration file and load peripheral modules. Read the board.json file, extract the peripheral module path and device description information, use the dynamic library loading mechanism to load the corresponding peripheral module, and call its initialization function to complete register registration and interface export, forming a list of device objects and dependent topology relationships. S3: Create and realize devices in the order of dependencies. According to the topology, device_create and device_realize are executed sequentially from the upper controller to the lower slave device. S4: Automatically constructs system topology and address mapping, performs address mapping according to the mmio field of the configuration file, automatically calls mmio_map to map the register area to the specified address, forms a complete virtual address space layout, and establishes the interconnection relationship between peripherals in the system; S5: Master-slave device interconnection is achieved through a delayed realization mechanism. After the master device bus is created, the slave device module calls the spi_slave_register or i2c_slave_register interface to register itself, and attaches to the specified bus through the spi_attach_slave or i2c_attach interface. S6: Automatic signal connection is achieved based on named signal mapping. By maintaining a hash table of IRQ / GPIO names and indices, the hash tables are IRQ_name_map and GPIO_name_map. During the connection phase, cross-module naming binding is achieved through IRQ_connect and GPIO_connect.

2. The peripheral dynamic loading and bus interconnection modeling method based on QEMUProxyAPI according to claim 1, characterized in that, The ProxyAPI interface layer specifically includes: The device management interface is used for the creation, instantiation, destruction, and reset management of devices. The register and memory mapping management interface is used to register the register area through mmio_register and map it to the system bus address space through mmio_map. Interrupt and GPIO management interface, used to export signal ports through IRQ_export_named and GPIO_export_named, and to connect signals between devices through IRQ_connect and GPIO_connect; The bus interface management interface is used to interconnect various peripheral buses through the spi_bus_create, spi_attach_slave, i2c_bus_create, and i2c_attach interfaces; The debugging and logging mechanism interface is used to provide a unified log output interface to achieve unified recording of device behavior, connection status, and errors.

3. The method for dynamic loading of peripherals and bus interconnection modeling based on QEMUProxyAPI according to claim 1, characterized in that, The device loading and topology management layer specifically includes: JSON file parsing: Parse the modules, devices, and connections fields in the configuration file layer to read peripheral module paths, device types, address mappings, role information, and interconnection relationships; Dynamic loading of peripheral modules: The corresponding peripheral dynamic library is loaded according to the path through the dynamic linking function dlopen or LoadLibrary; Call the initialization function: Automatically execute the initialization interface plugin_device_init_v1 in the peripheral dynamic library exported by the plug-in peripheral model, and complete device register registration, IRQ / GPIO export and bus interface creation; Dependency sorting and sequential realization: Devices are loaded in dependency order using a depth-first traversal mechanism, ensuring that controller devices are initialized before slave devices; Delayed realization mechanism: After the bus is created, the slave device is then connected to the corresponding bus instance to achieve correct master-slave interconnection.

4. The peripheral dynamic loading and bus interconnection modeling method based on QEMUProxyAPI according to claim 3, characterized in that, The plug-in peripheral model used in the device loading and topology management layer specifically includes: During the device registration phase, mmio_register is called to register the register area, and the initial values ​​of the registers are set in the reset function; Export signal ports using IRQ_export_named and GPIO_export_named for automatic matching during board-level connection. Multiple peripheral bus interconnections are achieved through the spi_bus_create, spi_attach_slave, i2c_bus_create, and i2c_attach interfaces; When the master device triggers a transmission, the plug-in layer achieves cross-module data exchange through the spi_transfer and i2c_msg_xfer interfaces.

5. The peripheral dynamic loading and bus interconnection modeling method based on QEMUProxyAPI according to claim 3, characterized in that, The configuration file layer specifically includes: module path, used to define the file location of all peripheral dynamic libraries; device list, used to describe device type, ID, module, register mapping address, and role information; and connection relationship, used to define the interconnection method of IRQ and GPIO.

6. The peripheral dynamic loading and bus interconnection modeling method based on QEMUProxyAPI according to claim 2, characterized in that, The configuration process for the device management interface in the ProxyAPI interface layer specifically includes: Create a bus instance, and call the spi_bus_create and i2c_bus_create interfaces respectively for different bus types. The interface calls the kernel bus initialization function. Create a bus object, configure the clock frequency, transmission mode and address width, register the bus instance to the ProxyAPI bus management list and assign a unique identifier; The device is associated with the specified bus through the spi_attach_slave and i2c_attach interfaces. After association, bus read and write operations are transparently forwarded through ProxyAPI. When the master device initiates a request, the kernel locates the target ProxyDevice through the bus object, and the ProxyAPI forwards the request to the device and returns the data.

7. The peripheral dynamic loading and bus interconnection modeling method based on QEMUProxyAPI according to claim 5, characterized in that, The configuration of the register and memory mapping management interface specifically includes: Register area registration is completed by calling the mmio_register interface based on the register base address, length, access permissions, and operation callback function. After receiving the parameters, ProxyAPI creates an MMIO region descriptor, binds the register base address, length, access permissions, and operation callback function to the corresponding ProxyDevice, and verifies the validity of the register address; Address mapping is performed through the mmio_map interface, which calls the QEMU kernel's address_space_map function to map the registered MMIO region to the specified address segment of the system bus. After the mapping is complete, when the kernel accesses the device via the bus address, the MMU automatically performs address translation and triggers the callback function associated with ProxyDevice.

8. The method for dynamic loading of peripherals and bus interconnection modeling based on QEMUProxyAPI according to claim 2, characterized in that, The configuration of the interrupt and GPIO management interface in the ProxyAPI interface layer specifically includes: The device specifies the signal type, port name, direction, and initial state through the IRQ_export_named and GPIO_export_named interfaces; Device associations are established through the IRQ_connect and GPIO_connect interfaces. When the connection is interrupted, the interface receives the interrupt source port name and the target device callback function, and binds the two through the kernel interrupt controller interface. When a device triggers an interrupt, the ProxyAPI is notified, and the ProxyDevice forwards the signal to the target device callback function to trigger interrupt handling.

9. The peripheral dynamic loading and bus interconnection modeling method based on QEMUProxyAPI according to claim 1, characterized in that, The dependencies are implemented using a depth-first traversal, specifically including: Extract the relationship description between the devices and connections fields in the core dependency board.json; After extraction, a triplet data structure containing device ID, device type, and a list of dependent devices is generated, where the dependency list of devices without dependencies is empty; Adjacency lists are used as the storage medium to convert the extracted dependencies into a directed graph data structure. Using the controller device without dependencies as the root node, the system recursively traverses all its downstream dependent devices to generate a device instantiation sequence sorted by master-slave and upstream-downstream order. Based on the instantiation sequence generated by traversal, the management layer executes device_create and device_realize operations, while ensuring the correctness of the initialization order through a differentiated strategy of immediate instantiation and delayed instantiation.

10. The method for dynamic loading of peripherals and bus interconnection modeling based on QEMUProxyAPI according to claim 1, characterized in that, The two hash tables, IRQ_name_map and GPIO_name_map, store the correspondence between signal names and hardware indices. The specific implementation and adaptation logic are as follows: Both IRQ_name_map and GPIO_name_map adopt a chained hash structure design. The key of the hash table is the business name of the signal, and the value is the underlying hardware index corresponding to the signal. The number of buckets in the hash table is dynamically configured based on the maximum number of signals supported by the system. The DJB hash algorithm is used to perform hash calculation on the signal name, and the result is modulo the number of buckets to obtain the bucket position of the signal in the hash table; If a hash collision occurs, the storage is extended backwards using linked list nodes. During retrieval, the target hardware index can be matched by traversing the linked list of the corresponding bucket using the signal name.

Images