Drive configuration method, apparatus, device, and storage medium

Abstract

The application provides a driving configuration method and device, equipment and a storage medium, and relates to the technical field of chips. The method comprises the following steps: after a driver is loaded, type information is determined, the type information being used for indicating a hardware type and a running platform of a processor; according to the hardware type and the running platform indicated by the type information, an adapted hardware abstraction layer and a configuration parameter layer are determined, the hardware abstraction layer being used for encapsulating a function pointer set of a hardware operation interface of the processor, and the configuration parameter layer being used for storing a configuration parameter set required by the driver running; and a dynamic association between the hardware abstraction layer and the configuration parameter layer is established, so that the driver uses the hardware abstraction layer to perform a hardware operation and uses the configuration parameter layer to perform resource configuration. The above method improves the development efficiency of the driver.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to a driver configuration method, apparatus, device, and storage medium. Background Technology

[0002] In the field of chip technology, the development of graphics processing units (GPUs) involves multiple stages, such as hardware simulation and mass production hardware. Different operating platforms have different requirements for driver configuration.

[0003] In related technologies, the hardware type of the GPU is first determined, and then the corresponding Hardware Abstraction Layer (HAL) is determined based on the hardware type. The HAL encapsulates the set of function pointers for the hardware operation interface and the set of configuration parameters required for driver operation, which are used to perform hardware operations and configure resources.

[0004] However, when GPUs run on different platforms, even if the hardware type is the same, different hardware abstraction layer instances need to be maintained or the hardware abstraction layer code needs to be modified. This results in low code reusability and an inability to flexibly adapt to the differentiated configuration requirements of different running platforms, thereby reducing the development efficiency of drivers. Summary of the Invention

[0005] This application provides a driver configuration method, apparatus, device, and storage medium. The technical solutions provided by this application are as follows.

[0006] According to one aspect of the embodiments of this application, a driver configuration method is provided, the method comprising: After the driver is loaded, the type information is determined, which indicates the processor's hardware type and operating platform; Based on the hardware type and operating platform indicated by the type information, an appropriate hardware abstraction layer and configuration parameter layer are determined. The hardware abstraction layer is used to encapsulate the set of function pointers of the processor's hardware operation interface, and the configuration parameter layer is used to store the set of configuration parameters required for the driver to run. A dynamic association is established between the hardware abstraction layer and the configuration parameter layer so that the driver uses the hardware abstraction layer to perform hardware operations and uses the configuration parameter layer to configure resources.

[0007] According to one aspect of the embodiments of this application, a drive configuration device is provided, the device comprising: The detection module is used to determine type information after the driver is loaded, the type information being used to indicate the processor's hardware type and operating platform; The matching module is used to determine the appropriate hardware abstraction layer and configuration parameter layer based on the hardware type and operating platform indicated by the type information. The hardware abstraction layer is used to encapsulate the set of function pointers of the processor's hardware operation interface, and the configuration parameter layer is used to store the set of configuration parameters required for the driver to run. The association module is used to establish a dynamic association between the hardware abstraction layer and the configuration parameter layer, so that the driver uses the hardware abstraction layer to perform hardware operations and uses the configuration parameter layer to perform resource configuration.

[0008] According to one aspect of the embodiments of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the above-described driver configuration method.

[0009] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, the computer program being loaded and executed by a processor to implement the above-described driver configuration method.

[0010] According to one aspect of the embodiments of this application, a chip is provided, the chip including programmable logic circuits and / or program instructions, which, when the chip is running, are used to implement the above-described driver configuration method.

[0011] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program, the computer program being loaded and executed by a processor to implement the above-described driver configuration method.

[0012] The technical solution provided in this application can bring the following beneficial effects: By first determining the hardware type and operating platform type information used to indicate the processor, then matching the corresponding Hardware Abstraction Layer (HAL) and Configuration Parameter Layer (MAP) based on this information, and finally establishing a dynamic association between the two, the driver can invoke the HAL to perform hardware operations and read the MAP for resource configuration. On one hand, the dual-dimensional matching mechanism based on hardware type and operating platform can accurately adapt to the driver configuration requirements of different hardware types and operating platforms, improving the targeting of driver configuration. On the other hand, the decoupling of the HAL and MAP reduces the amount of code modification required for cross-platform runtime and eliminates the need to maintain multiple HAL instances for different operating platforms, improving code reusability. In summary, the technical solution provided in this application improves driver development efficiency. Attached Figure Description

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

[0014] Figure 1 This is a flowchart of a driver configuration method provided in one possible implementation of this application; Figure 2 This is a schematic diagram of the separation architecture and two-dimensional mapping provided in one possible implementation of this application; Figure 3 This is a flowchart of driver initialization provided in one possible implementation of this application; Figure 4 This is a flowchart of updating configuration parameters during the driver runtime phase provided in one possible implementation of this application; Figure 5 This is a schematic diagram of virtualization isolation provided in one possible implementation of this application; Figure 6 This is an architecture diagram of the driver configuration system provided in one possible implementation of this application; Figure 7 This is a structural block diagram of the drive configuration device provided in one possible implementation of this application; Figure 8 This is a structural block diagram of a computer device provided in one possible implementation of this application. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0016] Before introducing the technical solution proposed in this application, the relevant technical background and related technologies will be briefly described below.

[0017] This application relates to the field of chip design, and in particular to a driver configuration technology applicable to driver configuration scenarios across different hardware types and operating platforms during multi-stage chip development.

[0018] During chip development, for different hardware types (such as GPU chips with different architectures, which can be identified by Peripheral Component Interconnect Identifier (PCI ID)) and different operating platforms (including Virtual Prototyping (VP), Emulation (EMU), Field Programmable Gate Array (FPGA) prototyping (implemented based on FPGA), mass production hardware, and guest and host scenarios in virtualized environments), it is necessary to implement driver-hardware interaction and resource configuration. For example, in related technologies, the following steps are typically employed: First, the processor's hardware type is determined, and then the corresponding Hardware Abstraction Layer (HAL) is identified based on that hardware type. The HAL encapsulates two parts: first, a set of function pointers for hardware operation interfaces, used to perform hardware operations on the processor (such as register read / write and video memory allocation); and second, a set of configuration parameters required for driver operation (such as video memory base address, interrupt number configuration, and register mapping rules), used to complete the driver's resource configuration. By directly calling the function pointers in the HAL to execute hardware operations and reading the stored configuration parameters, resource configuration is completed, enabling the driver to run on different hardware types and different operating platforms.

[0019] However, in related technologies, the following problems exist in scenarios involving multi-stage chip development and driver configuration across different operating platforms: 1. Limited matching dimensions. The hardware abstraction layer is matched only by hardware type, without distinguishing between different operating platforms. The configuration parameters (graphics memory base address, interrupt number, etc.) of the same chip vary greatly at different stages such as virtual prototype, hardware simulation, and mass production hardware, or in virtualized guest / host scenarios. This leads to the need to maintain multiple hardware abstraction layer instances, making it impossible to flexibly adapt to requirements.

[0020] 2. High code coupling. The function pointers and configuration parameters of the hardware operation interface are encapsulated in the same hardware abstraction layer structure. When adjusting the configuration parameters or changing the running platform, the hardware abstraction layer code needs to be modified synchronously or different versions need to be maintained. This results in low driver code reusability and requires a lot of repetitive development work for cross-platform portability, which directly reduces driver development efficiency and cross-platform portability.

[0021] In summary, the single-dimensional matching mechanism and the coupled architecture of hardware operation and configuration parameters in related technologies have problems such as low code reusability, high development cost, and poor cross-platform portability, which in turn reduce the development efficiency of drivers.

[0022] To address the aforementioned problems, this application provides a driver configuration method. For example, please refer to... Figure 1 , Figure 1 This is a flowchart of a driver configuration method provided in one possible implementation of this application. The driver configuration method may include at least one of the following steps 110 to 130.

[0023] Step 110: After the driver is loaded, determine the type information, which is used to indicate the processor's hardware type and operating platform.

[0024] In this embodiment, type information is used to indicate the processor's hardware type and operating platform. Exemplarily, the determination of type information employs a two-dimensional matching mechanism: the first dimension matches the hardware type, identifying the processor's inherent hardware attributes; the second dimension matches the operating platform, identifying the processor's current operating environment attributes. These two dimensions together constitute a complete environment description, providing input for subsequent driver configuration.

[0025] On the one hand, hardware type is used to identify processor chips with different architectures and performance levels. For example, GPUs can be identified by their PCI ID, and are categorized into entry-level, mid-range, and high-performance types. For instance, the high-performance type refers to a processor with a complete set of features, supporting advanced features such as firmware management, intelligent management controllers, and interrupt handling.

[0026] In this embodiment, the runtime platform is categorized by the processor's current operating environment, used to distinguish the runtime platforms of the processor in different development stages and deployment scenarios. For example, the runtime platform may include, but is not limited to: mass production hardware platforms, simulation platforms, prototype verification platforms (such as high-performance ASIC Prototyping Systems (HAPS) based on FPGA), guest platforms in virtualized environments, and host platforms in virtualized environments. Different runtime platforms have significantly different timing characteristics and resource configuration rules. For instance, a specific system-on-a-chip simulation platform is used for driver verification and performance testing before hardware mass production, and its timing characteristics differ from those of mass-produced hardware.

[0027] In some embodiments, multi-dimensional detection, including hardware type detection and runtime platform detection, can be performed after driver loading to determine type information. For example, after driver loading is complete, an initialization process is triggered, performing hardware type detection and runtime platform detection respectively. Specifically, by reading the processor's device identifier (such as PCI ID) and matching the read identifier with a predefined hardware type table, the hardware model of the current processor is determined, completing the first dimension detection (i.e., hardware type detection); by reading system firmware information, detecting emulator feature registers, and querying system-on-a-chip identifiers, the specific runtime platform of the current operating environment is identified, completing the second dimension detection (i.e., runtime platform detection), ultimately obtaining type information indicating the processor's hardware type and the runtime platform.

[0028] In some embodiments, type information is determined by a platform detection module. For example, the platform detection module is a functional module integrated into the driver initialization process, used to perform the aforementioned two-dimensional detection: this module calls the device enumeration interface provided by the operating system to read the device identifier and complete hardware type detection; simultaneously, it accesses system firmware, feature registers, etc., to obtain platform environment information and complete running platform detection, ultimately outputting information indicating the processor's hardware type and the running platform's type, providing input for subsequent matching of the corresponding Hardware Abstraction Layer and Configuration Parameter Layer (CPL). It is worth noting that the implementation of the platform detection module is not limited to the above-described software module form; it can also be implemented through hardware circuits or a combination of hardware and software. Those skilled in the art can choose according to actual needs, and this application does not limit this approach.

[0029] Step 120: Based on the hardware type and operating platform indicated by the type information, determine the appropriate hardware abstraction layer and configuration parameter layer. The hardware abstraction layer is used to encapsulate the set of function pointers of the processor's hardware operation interface, and the configuration parameter layer is used to store the set of configuration parameters required for driver operation.

[0030] In this embodiment, the hardware abstraction layer (HAL) is an independent data structure instance used to encapsulate the processor's hardware operation interface set. Internally, it stores the call entry points for various hardware operation methods in the form of function pointers, including but not limited to register read / write functions, video memory allocation functions, interrupt enable functions, power management functions, and clock control functions. The HAL is organized by hardware type: hardware of the same type (such as GPUs of the same generation) has the same operating logic and can therefore be abstracted into a single HAL instance; different generations or types of processors (such as integrated GPUs and discrete GPUs) correspond to different HAL instances. The HAL does not contain configuration parameters; it only provides standard hardware operation interfaces, implementing the logical definition of "how to access the hardware," and is completely decoupled from parameter information such as "what the hardware configuration parameters are."

[0031] In this embodiment, the configuration parameter layer is an independent data structure instance used to store the set of configuration parameters required for driver operation, covering the core configuration requirements for driver initialization. Exemplarily, this may include, but is not limited to: memory layout parameters (video memory size, address mapping range, memory channel configuration, etc.), interrupt mapping parameters (interrupt number allocation, interrupt triggering method, etc.), power mode parameters (power consumption threshold, frequency adjustment strategy, sleep / wake mechanism, etc.), feature-level parameters (enabling / disabling specific hardware features, such as ray tracing, variable rate shading), and buffer size parameters (capacity configuration of command buffer and readback buffer). The configuration parameter layer supports dynamic modification at runtime; parameter values ​​can be loaded, reloaded, or adjusted during driver operation without unloading or restarting the driver.

[0032] In this embodiment, the hardware abstraction layer and the configuration parameter layer are separate architectures, meaning they are independent data structures without any encapsulation dependency. Specifically, the hardware abstraction layer only contains function pointers to hardware operation interfaces and does not involve any configuration parameters; the configuration parameter layer only stores a set of configuration parameters and does not involve any hardware operation logic. The two can be dynamically associated through a preset mapping relationship, rather than statically bound. This means that the same hardware abstraction layer can be paired with different instances of the configuration parameter layer to adapt the same set of hardware operation logic to the configuration requirements of different operating platforms. This separate architecture solves the problems of high cross-platform adaptation costs and low code reusability caused by the coupling of hardware operations and configuration parameters.

[0033] In this embodiment, the adapted hardware abstraction layer and configuration parameter layer are determined by the hardware type and operating platform indicated by the type information. The hardware type and operating platform indicated by the type information can serve as a two-dimensional index to match the corresponding hardware abstraction layer instance and configuration parameter layer instance from the mapping rules. The adaptation determination method can take various implementation forms and is not limited to a certain fixed logic. Common implementation methods may include, but are not limited to, the following types: 1. Mapping table matching implementation: A mapping table indexed by combinations of hardware type and operating platform is pre-built. The table stores the identifiers or pointers of hardware abstraction layer instances and configuration parameter layer instances corresponding to different combinations. The adapted hardware abstraction layer and configuration parameter layer can be directly obtained by querying the table.

[0034] 2. Dynamic rule matching implementation: Preset matching rules for combinations of hardware type and running platform. The rules can include condition judgment logic (such as matching a dedicated hardware abstraction layer when the hardware type is high-performance and the running platform is a simulation platform). The corresponding hardware abstraction layer and configuration parameter layer are adapted through dynamic rules. This method supports flexible rule expansion and can dynamically adjust the matching logic without modifying the overall architecture.

[0035] 3. Hierarchical index matching implementation: First, a first-level index is performed based on the hardware type to filter out the set of hardware abstraction layer instances and configuration parameter layer sets corresponding to the hardware type. Then, a second-level index is performed based on the running platform in the filtered set to finally determine the suitable instance. This method has a clear hierarchy and is suitable for scenarios with a large number of hardware types or running platforms, which can reduce the complexity of matching.

[0036] 4. Preset priority matching implementation: Preset adaptation priorities for different hardware type-running platform combinations. When the type information matches multiple possible hardware abstraction layer or configuration parameter layer instances, the instance with the highest priority is selected as the adaptation result according to the preset priority. This method can set priority matching logic for special scenarios to ensure the adaptation requirements of specific scenarios.

[0037] All of the above implementation methods can complete the adaptation and matching between the hardware abstraction layer and the configuration parameter layer based on the type information of two dimensions (hardware type dimension and operating platform dimension). Those skilled in the art can select or combine different implementation methods according to the actual scenario requirements, or adopt other adaptation logic, all of which are within the protection scope of this application.

[0038] Step 130: Establish a dynamic association between the hardware abstraction layer and the configuration parameter layer so that the driver uses the hardware abstraction layer to perform hardware operations and uses the configuration parameter layer to configure resources.

[0039] In this embodiment, the dynamic association between the hardware abstraction layer and the configuration parameter layer refers to the temporary association established between them at runtime through reference pointers, handles, or global context binding, rather than code-level coupling during the static compilation stage. Specifically, the hardware abstraction layer can dynamically obtain instance references of the configuration parameter layer at runtime. When it needs to read configuration parameters (such as reading the base address of the video memory before performing a video memory allocation operation, or reading the interrupt number configuration before triggering an interrupt), it accesses the corresponding parameter value of the configuration parameter layer through the association channel. The configuration parameter layer can also dynamically perceive the type of the currently associated hardware abstraction layer at runtime to ensure that the parameters match the hardware operation logic. This dynamic association does not affect the independent storage structure of the two. The establishment, modification, or dissolution of the association does not require modification of the code of the hardware abstraction layer or the configuration parameter layer itself; only the binding relationship between the two needs to be adjusted to achieve suitable matching of different combinations.

[0040] In some embodiments, a dynamic association between the Hardware Abstraction Layer (HAL) and the Configuration Parameter Layer (MAP) can be established during the driver initialization phase. After the driver loads and obtains the appropriate HAL and MAP instances through two-dimensional matching, the instance pointer of the MAP can be registered in the driver's global context structure during the execution flow of the initialization entry function (such as DriverEntry). Simultaneously, the instance pointer of the HAL is also written into this context, creating a binding relationship between the two within the context. All subsequent hardware operations of the driver will access the corresponding HAL and MAP through this context, completing the association establishment during the initialization phase.

[0041] In some embodiments, a dynamic association between the hardware abstraction layer and the configuration parameter layer can be established during the driver runtime phase. After the driver has completed initialization and is working normally, if a change in the runtime environment (such as switching virtualization environments or runtime platforms) or a configuration update requirement (such as dynamically adjusting the video memory allocation strategy) is detected, the association between the original hardware abstraction layer and the original configuration parameter layer can be dynamically terminated. A new configuration parameter layer instance can be re-matched and a new association can be established with the existing hardware abstraction layer, or a new hardware abstraction layer instance can be re-matched and an association can be established with the original configuration parameter layer. The association switching can be completed without restarting the driver, which is suitable for runtime dynamic adaptation scenarios.

[0042] For example, in addition to the stages described above, dynamic association can also cover the following application scenarios: 1. When upgrading drivers or updating patches, there is no need to restart the system. The driver update can be completed simply by re-matching the updated hardware abstraction layer or configuration parameter layer and establishing a new dynamic association, thus ensuring business continuity.

[0043] 2. Multi-instance parallel scenario: When the same processor needs to run multiple driver instances simultaneously (such as the same GPU serving multiple clients in a virtualization scenario), different hardware abstraction layers and configuration parameter layers can be dynamically associated for each instance to achieve independent configuration and operation of multiple instances.

[0044] 3. Fault recovery scenario: When abnormal configuration parameters or hardware abstraction layer errors occur during driver operation, the association can be dynamically rebuilt, or the corresponding configuration parameter layer and hardware abstraction layer can be re-adapted according to the hardware type and operating platform indicated by the type information to quickly restore driver function and improve system stability.

[0045] Through the aforementioned dynamic association mechanism, the dual-dimensional matching mechanism and separation architecture proposed in this application can flexibly take effect in different scenarios throughout the entire lifecycle of the driver, realizing the decoupling and adaptation of hardware operation logic and configuration parameters, covering various driver operation scenarios such as multi-stage development, cross-platform, and virtualization.

[0046] The driver configuration method provided in this application first determines the hardware type and operating platform type information indicating the processor, then matches the corresponding hardware abstraction layer and configuration parameter layer based on the hardware type and operating platform indicated by the type information, and finally establishes a dynamic association between the two, so that the driver calls the hardware abstraction layer to perform hardware operations and reads the configuration parameter layer for resource configuration. On the one hand, the dual-dimensional matching mechanism based on hardware type and operating platform can accurately adapt to the driver configuration requirements of different hardware and operating environments, improving the pertinence of driver configuration; on the other hand, the decoupling of the hardware abstraction layer and configuration parameter layer can reduce the amount of code modification during cross-platform runtime, and eliminates the need to maintain multiple hardware abstraction layer instances for different operating environments, improving code reusability. In summary, the driver configuration method provided in this application improves driver development efficiency.

[0047] In some embodiments, determining the appropriate hardware abstraction layer and configuration parameter layer based on the hardware type and operating platform indicated by the type information includes: determining the hardware abstraction layer and configuration parameter layer based on a mapping table and the hardware type and operating platform indicated by the type information. The mapping table defines the correspondence between the type information and the hardware abstraction layer and configuration parameter layer.

[0048] In this embodiment, the mapping table is a data structure used to store the mapping relationship between the two-dimensional combination of (hardware type, operating platform) and the corresponding hardware abstraction layer instance and configuration parameter layer instance, thereby implementing the aforementioned two-dimensional matching mechanism. For example, the implementation form of the mapping table can be selected according to the actual scenario requirements; common forms may include, but are not limited to: 1. Two-Dimensional Co-adaptive Mapping Table: A binary index of (hardware type, operating platform) serves as the composite key. Each composite key corresponds to a fixed set of hardware abstraction layer instance pointers and configuration parameter layer instance pointers. That is, both the hardware abstraction layer and the configuration parameter layer are simultaneously determined by this binary index. For example, (high-performance GPU, specific system-on-a-chip simulation platform) corresponds to a dedicated hardware abstraction layer A and a dedicated configuration parameter layer B; (high-performance GPU, mass-production hardware platform) corresponds to the same hardware abstraction layer A and a mass-production configuration parameter layer C.

[0049] 2. Two-dimensional mapping tables: These tables correspond to separate sub-tables for hardware type-hardware abstraction layer and runtime platform-configuration parameter layer. The mapping relationships are stored independently in these two sub-tables. The hardware abstraction layer is determined solely by the hardware type, and the configuration parameter layer is determined solely by the runtime platform. For example, the hardware type "high-performance GPU" corresponds to hardware abstraction layer A, the runtime platform "simulation platform" corresponds to configuration parameter layer B, and the runtime platform "mass production platform" corresponds to configuration parameter layer C. This approach simplifies the implementation logic and is suitable for scenarios where hardware operation logic and platform configuration are completely decoupled.

[0050] 3. Hybrid Adaptive Mapping Table: It uses a two-dimensional composite key as the main index, while also being compatible with single-dimensional fallback logic. That is, it prioritizes matching the dedicated instance corresponding to the two-dimensional composite key. If no match is found, it falls back to the default hardware abstraction layer and the default configuration parameter layer according to hardware type and running platform, respectively.

[0051] All implementations of the above mapping relationship tables fall within the protection scope of this application. Those skilled in the art can select or combine them according to actual adaptation needs, and this application does not limit them in this regard.

[0052] In some embodiments, a two-dimensional mapping module can be used to maintain the mapping relationship table. For example, the two-dimensional mapping module is a functional module integrated into the driver execution flow, used to query and manage the aforementioned mapping relationship table. Its core working mechanism is as follows: receiving the hardware type and operating platform type information output from step 110, performing a query operation according to the index rules of the mapping relationship table, and outputting the appropriate hardware abstraction layer instance pointer and configuration parameter layer instance pointer. For example, the functions of the two-dimensional mapping module may include, but are not limited to: 1. Mapping Query Function: Based on the input type information, match the corresponding entries in the mapping relationship table and return the adapted hardware abstraction layer instance and configuration parameter layer instance.

[0053] 2. Backtracking Matching Function: When the input (hardware type, operating platform) index has no exact match, the system returns the appropriate hardware abstraction layer instance and / or configuration parameter layer instance according to the preset backtracking rules (e.g., first match the default configuration of the single-dimensional hardware type, then match the default configuration of the single-dimensional operating platform) to avoid driver initialization failure due to no match.

[0054] 3. Legality verification function: Perform legality verification on the matched hardware abstraction layer instance and configuration parameter layer instance (such as verifying that the instance pointer is not null and that the instance version is compatible with the current driver version). The result is output only after the verification is passed, which improves the reliability of matching.

[0055] It is worth noting that the implementation of the two-dimensional mapping module is not limited to software functional modules, but can also be implemented through hardware circuits (such as lookup table circuits) or a combination of hardware and software. Its specific implementation logic can be adjusted according to the storage format of the mapping relationship table and the query requirements. Those skilled in the art can choose according to the actual scenario, and this application does not limit it.

[0056] By clearly defining the correspondence between storage type information (hardware type + operating platform) and the hardware abstraction layer and configuration parameter layer through a mapping table, the two-dimensional matching logic is transformed into a queryable static data structure, eliminating the need to encode multiple sets of conditional judgment logic in the code. On the one hand, this reduces the complexity of the matching logic and improves the query efficiency from type information to the adapted instance; on the other hand, the independent maintenance feature of the mapping table means that when adding a matching instance for a new hardware type or operating platform, only the mapping table entries need to be updated, without modifying the driver core matching code, further reducing the maintenance cost of cross-platform adaptation.

[0057] For example, please refer to Figure 2 , Figure 2 This is a schematic diagram of the separated architecture and two-dimensional mapping provided in one possible implementation of this application. Specifically: Hardware Abstraction Layer 210: Responsible for encapsulating a set of function pointers for hardware operation interfaces for specific hardware types, providing standardized calling capabilities to the upper layers.

[0058] Configuration parameter layer 220: Responsible for storing, managing and running the set of configuration parameters related to the platform (such as simulation platform, mass production platform, embedded system, etc.), and providing platform-related configuration parameters to the upper level.

[0059] Two-dimensional mapping module 230: As the core scheduling unit, it receives type information indicating hardware type and operating platform, and dynamically queries and associates the corresponding hardware abstraction layer instance and configuration parameter layer instance according to the mapping relationship table.

[0060] The bidirectional arrows in the diagram, "dynamic association," represent the dynamic binding relationship established between the hardware abstraction layer and the configuration parameter layer through the two-dimensional mapping module. That is, the two are not statically coupled, but are matched and associated in real time by the two-dimensional mapping module based on the type information input at runtime, thus forming a separate architecture between the hardware abstraction layer and the configuration parameter layer.

[0061] It is worth noting that, Figure 2 This is merely an illustrative example used to illustrate the core idea of ​​this application: "achieving two-dimensional adaptation of type information to the hardware abstraction layer and configuration parameter layer through a mapping relationship table." It does not limit the names, structures, interaction methods, or physical deployment forms of modules in an actual system. For example, the mapping module can be merged with the hardware abstraction layer or configuration parameter layer into a single component, or further split into multiple sub-modules; interaction can employ various methods such as function calls, message queues, event registration, and configuration injection; the mapping relationship table can be stored in various storage units such as memory, files, databases, read-only memory (ROM), and distributed configuration centers.

[0062] The scope of protection of this application covers all technical solutions based on "mapping relationship table + type information → output adaptation hardware abstraction layer and configuration parameter layer instance", regardless of their specific structure, naming and deployment form.

[0063] In some embodiments, the mapping table includes a first mapping relationship and a second mapping relationship. The first mapping relationship is the mapping between hardware type and hardware abstraction layer, and the second mapping relationship is the mapping between runtime platform and configuration parameter layer.

[0064] Based on the hardware type and operating platform indicated by the mapping table and type information, determine the hardware abstraction layer and configuration parameter layer, including: querying the first mapping relationship based on the hardware type to determine the hardware abstraction layer; and querying the second mapping relationship based on the operating platform to determine the configuration parameter layer.

[0065] In some embodiments, the hardware type and operating platform indicated in the type information have independent mapping relationships with the hardware abstraction layer and the configuration parameter layer, respectively. This type of independent mapping is suitable for standard combination scenarios where hardware operation logic and platform configuration are completely decoupled. That is, the hardware operation interface of the same hardware type is fixed and is not affected by the operating platform. Only the configuration parameters need to be adjusted according to different operating platforms to meet the adaptation requirements. There is no need to maintain multiple sets of hardware abstraction layers for the same hardware type on different operating platforms, nor is there a need to maintain multiple sets of configuration parameter layers for different hardware types on the same operating platform. For example, the hardware operation logic of an entry-level GPU remains consistent in the virtual prototyping stage, hardware simulation stage, and mass production hardware stage. Only the configuration parameters such as memory size and interrupt number need to be adjusted for different operating platforms, which is suitable for this type of independent mapping.

[0066] In this embodiment, the first mapping relationship is a mapping relationship between hardware type and hardware abstraction layer, used to define the set of operation interfaces corresponding to processors of different hardware models. For example, the first mapping relationship can be stored in key-value pair form, where the key is the hardware type identifier (e.g., entry-level GPU, mid-range GPU, high-performance GPU), and the value is a pointer to a hardware abstraction layer instance corresponding to the hardware type. Only one hardware abstraction layer instance corresponds to the same hardware type, ensuring consistent operation logic for the same hardware model and avoiding redundant implementation. For example, hardware type "high-performance GPU" corresponds to hardware abstraction layer instance A, and hardware type "entry-level GPU" corresponds to hardware abstraction layer instance B. When querying, only the hardware type needs to be entered to directly return the corresponding hardware abstraction layer instance. It is worth noting that in this embodiment, different hardware types correspond to different hardware abstraction layer instances to achieve isolation of operation logic for different hardware architectures; while for the same hardware type, the same hardware abstraction layer instance can be shared under different operating platforms, eliminating the need to repeatedly develop hardware operation logic for different operating platforms. Furthermore, the hardware abstraction layer can dynamically adjust its function set according to the characteristics of the operating platform. For example, when switching operating platforms within the same hardware abstraction layer, the driver can automatically disable some operation interfaces (such as video processing unit (VPU) related function interfaces), retaining only basic graphics processing functions to adapt to the hardware characteristics limitations of the operating platform. This mechanism ensures the consistency of operational logic for the same hardware type while also taking into account the differences in characteristics between different operating platforms, and does not change the correspondence between "hardware type → hardware abstraction layer" in the first mapping relationship.

[0067] In this embodiment, the second mapping relationship is a mapping relationship between the runtime platform and the configuration parameter layer, used to define the set of configuration parameters corresponding to different runtime platforms. For example, the second mapping relationship can also be stored in key-value pair format, where the key is the runtime platform identifier (e.g., mass production hardware platform, HAPS prototype platform, virtualization guest platform), and the value is a pointer to the configuration parameter layer instance of the corresponding runtime platform. Only one configuration parameter layer instance corresponds to the same runtime platform, ensuring that the configuration rules for the same runtime platform are consistent and avoiding duplicate definition of configurations for different hardware types under the same platform. For example, the runtime platform "HAPS prototype platform" corresponds to configuration parameter layer instance A, and the runtime platform "mass production hardware platform" corresponds to configuration parameter layer instance B. When querying, only the runtime platform needs to be entered to directly return the corresponding configuration parameter layer.

[0068] In some embodiments, the hardware abstraction layer (HAL) can be determined by first querying a first mapping relationship based on the hardware type; then, the configuration parameter layer can be determined by querying a second mapping relationship based on the operating platform. Specifically, after receiving the type information, the two-dimensional mapping module first extracts the hardware type, traverses the key-value pairs of the first mapping relationship, matches the corresponding HAL instance pointer, and temporarily stores it; then, it extracts the operating platform field from the type information, traverses the key-value pairs of the second mapping relationship, matches the corresponding configuration parameter layer instance pointer; finally, it outputs the queried instance pointer as the adaptation result to complete the dynamic association between the HAL and the configuration parameter layer.

[0069] By splitting the mapping table into a first mapping relationship between hardware type and hardware abstraction layer and a second mapping relationship between runtime platform and configuration parameter layer, independent mapping between hardware type, runtime platform and adaptation instance is achieved. This ensures that the hardware abstraction layer is determined only by the hardware type and the configuration parameter layer is determined only by the runtime platform. For the same hardware type, there is no need to maintain multiple sets of hardware abstraction layers due to platform differences, and for the same runtime platform, there is no need to maintain multiple sets of configuration parameter layers due to hardware type differences. This further reduces the redundancy of adaptation instances, simplifies the maintenance logic of the mapping table, and improves the matching efficiency in standard combination scenarios.

[0070] In some embodiments, the mapping table includes a third mapping relationship, which is a mapping relationship between a combination of hardware type and operating platform and a combination of hardware abstraction layer and configuration parameter layer.

[0071] Based on the hardware type and operating platform indicated by the mapping table and type information, determine the hardware abstraction layer and configuration parameter layer, including: determining the combination of hardware type and operating platform; and querying the third mapping relationship based on the combination of hardware type and operating platform to determine the combination of hardware abstraction layer and configuration parameter layer.

[0072] In some embodiments, the aforementioned third mapping relationship is applicable to special combination scenarios, namely, when the same hardware type needs to adjust configuration parameters and adapt to dedicated hardware operation logic on different operating platforms, or when different hardware types on the same operating platform need to be matched with dedicated configuration parameters. Conventional independent mapping cannot cover such special needs, and a two-dimensional combination is required to directly match the dedicated hardware abstraction layer and configuration parameter layer combination to ensure the correctness of driver adaptation in special scenarios. For example, when a high-performance GPU runs on a specific system-on-a-chip simulation platform, it not only needs to adapt to the simulation platform's unique configuration parameters such as memory base address and interrupt number, but also needs to adapt to the simulation platform's dedicated register read / write logic, timing control logic, and other hardware operation interfaces. This belongs to such a special combination scenario, and the third mapping relationship is required to achieve accurate matching.

[0073] In this embodiment, the third mapping relationship is the mapping relationship between the combination of hardware type and operating platform and the combination of hardware abstraction layer and configuration parameter layer, used to define the dedicated adaptation instance corresponding to the special combination. For example, the third mapping relationship can be stored in the form of composite key-value pairs, where the composite key is a tuple of (hardware type identifier, operating platform identifier) ​​and the value is a tuple of (hardware abstraction layer instance pointer, configuration parameter layer instance pointer); only special combinations are recorded in the third mapping relationship, and regular standard combinations do not need to be recorded. Furthermore, it can coexist with the aforementioned first and second mapping relationships to form a hierarchical matching logic of "special combinations are preferentially matched with the third mapping relationship, and if no match is found, it falls back to the independent mapping (first mapping relationship and second mapping relationship)". For example, the composite key (high-performance GPU, specific system-on-a-chip simulation platform) corresponds to the value (dedicated hardware abstraction layer A, dedicated configuration parameter layer A), meaning that when querying, entering the composite key (high-performance GPU, specific system-on-a-chip simulation platform) will directly return the combination of dedicated hardware abstraction layer A and dedicated configuration parameter layer A.

[0074] In some embodiments, the combination of hardware type and operating platform is used to query a third mapping relationship to directly determine the combination of the hardware abstraction layer and the configuration parameter layer. Specifically, after receiving the type information, the two-dimensional mapping module first obtains the composite key (hardware type, operating platform), traverses the composite key list of the third mapping relationship, and if a matching entry is found, directly extracts the hardware abstraction layer instance pointer and configuration parameter layer instance pointer stored in the entry as the adaptation result output, completing the combination determination of the two in one go, without needing to query independent mapping relationships separately. The above process can ensure adaptation consistency in special scenarios.

[0075] By establishing a direct mapping between the combination of hardware type and operating platform and the combination of hardware abstraction layer and configuration parameter layer through a third mapping relationship, special adaptation scenarios that require dedicated hardware operation logic and dedicated configuration parameters can be accurately covered. This solves the problem that independent mapping cannot adapt to complex requirements such as "adjusting operation logic when the same hardware is used across platforms" and "using dedicated configuration when the same platform is used across hardware". At the same time, the use of combination key direct matching avoids the redundant process of multiple independent queries and improves the matching accuracy and efficiency in special scenarios.

[0076] In some embodiments, after determining the adapted hardware abstraction layer and configuration parameter layer based on the hardware type and operating platform indicated by the type information, the method further includes: determining a target configuration parameter set from multiple configuration sources according to priority rules, wherein the target configuration parameter set is a set of configuration parameters that ultimately take effect during the driver initialization phase; and updating the configuration parameter layer based on the target configuration parameter set.

[0077] In this embodiment, the target configuration parameter set is the set of configuration parameters that ultimately take effect during the driver initialization phase. It is used to ultimately write the configuration parameter layer, providing a definite configuration input for driver operation. For example, the above process can be applied to the driver initialization phase. That is, after the two-dimensional mapping module completes the initial configuration parameter layer matching, the configuration arbitration module can integrate multiple configuration sources and update the configuration parameter layer, ensuring that the driver uses the arbitrated configuration parameters after startup, avoiding operational anomalies caused by configuration parameter changes after initialization. The target configuration parameter set integrates configuration parameters from different configuration sources, solving the problem that a single configuration source cannot cover the configuration requirements of multiple scenarios. It retains the default basic configuration provided by the mapping table (i.e., the configuration parameter layer determined in step 120) and can also integrate customized configurations from different configuration sources, improving configuration flexibility.

[0078] It should be noted that the mechanism of updating configuration parameters in the configuration parameter layer according to priority rules is applicable not only to the driver initialization phase, but also to the driver running phase. It is used to dynamically adjust configuration parameters during driver operation (such as adjusting power policy parameters according to system load during runtime, enabling / disabling specific hardware features according to business needs, etc.). The configuration update implementation method in this running phase will be described in the following embodiments, and will not be repeated here.

[0079] In this embodiment, the priority rule is a configuration source priority sorting logic used to determine the effective priority of different configuration parameters among multiple configuration sources. For example, when multiple configuration sources have conflicting definitions for the same configuration parameter, the configuration parameter of the higher-priority configuration source can override the configuration parameter of the lower-priority configuration source.

[0080] In some embodiments, the above process can be executed through a configuration arbitration module, which is a functional module integrated into the driver's runtime process. During the driver initialization phase, the configuration arbitration module, after the two-dimensional mapping module determines the configuration parameter layer based on the mapping table, completes the arbitration integration of multiple configuration sources based on priority rules: first, it reads the configuration parameters from multiple configuration sources and arbitrates the configuration parameters according to priority rules to generate the final target configuration parameter set; then, it writes the target configuration parameter set into the aforementioned configuration parameter layer, completing the update of the configuration parameter layer, so that the final effective configuration of the configuration parameter layer simultaneously covers multiple sources of requirements, including default configuration, system configuration, and user-customized configuration. It is worth noting that the implementation form of the configuration arbitration module is not limited to a software functional module; it can also be implemented through hardware circuits or a combination of hardware and software, and this application does not limit this.

[0081] In one possible implementation, the process of the two-dimensional mapping module determining the configuration parameter layer is as follows: based on the mapping relationship table, the module matches and obtains the corresponding initial configuration parameter set from the configuration parameter array (such as the configuration parameters obtained by matching through the first mapping relationship, the second mapping relationship, or the third mapping relationship as described above). For example, this initial configuration parameter set can participate in the subsequent arbitration process as one of the multiple configuration sources. The configuration arbitration module collects the initial configuration parameter set together with the configuration parameters of other configuration sources and arbitrates the same configuration item according to the priority rules to generate the final target configuration parameter set. Then, the target configuration parameter set is written into the corresponding configuration parameter layer data structure as the final configuration parameter layer content, thus completing the determination of the configuration parameter layer. It should be noted that the "updating configuration parameter layer" proposed in this embodiment is not limited to modifying the existing configuration parameter layer data structure. It can also be that the final target configuration parameter set is determined first, and then uniformly written into or initialized into the configuration parameter layer data structure. This application does not limit the specific implementation method of the collaboration timing and data flow between the two-dimensional mapping module and the configuration arbitration module. As long as the configuration parameter set finally written into the configuration parameter layer is determined through matching by the two-dimensional mapping module and / or arbitration by the configuration arbitration module, it falls within the protection scope of this application.

[0082] By introducing the aforementioned arbitration mechanism during the initialization phase—that is, arbitrating from multiple configuration sources to determine the final effective set of target configuration parameters and updating the configuration parameter layer—the problem that a single configuration source cannot meet the needs of multiple scenarios is solved. It retains the default basic configuration provided by the mapping table while integrating customized configurations from multiple configuration sources, improving the flexibility and scenario adaptability of driver configuration, while avoiding parameter conflicts from multiple configuration sources and ensuring the consistency and correctness of configuration during the initialization phase.

[0083] For example, please refer to Figure 3 , Figure 3 This is a flowchart of driver initialization provided in one possible implementation of this application. Figure 3 The application scenario for the driver initialization process shown is: a high-performance GPU that needs to run on a specific system-on-a-chip (SoC) emulation platform. Running the driver on this specific SoC requires dedicated timing adaptation. For example, Figure 3 The driver initialization process shown may include at least one of the following steps 31 to 40.

[0084] Step 31, Driver Loading. The operating system loads the GPU kernel driver, calls the driver initialization entry function, and triggers the driver initialization process.

[0085] Step 32: Determine the type information. The platform detection module performs a two-dimensional detection: 1. Hardware type detection: The platform detection module reads the GPU's device identifier through the device enumeration interface provided by the operating system. The device identifier is used to identify the GPU's hardware model, such as entry-level, mid-range, high-performance, etc. The read identifier is matched with the hardware type table to determine that the hardware type is high-performance. 2. Running platform detection: The platform detection module identifies the current running platform as a specific system-on-a-chip (SoC) emulation platform by reading system firmware information, detecting emulator feature registers, and querying SoC identifiers. Finally, type information indicating "high-performance GPU + specific SoC emulation platform" is obtained.

[0086] Step 33: Query the mapping table. After receiving the type information output in step 32, the two-dimensional mapping module first queries the mapping table to retrieve the hardware type-operating platform combination list, providing a basis for subsequent judgment on whether it is a special combination.

[0087] Step 34: Determine if it is a special combination. The two-dimensional mapping module executes the special combination determination logic, that is, it determines whether the current combination of "high-performance type GPU + specific system-on-a-chip simulation platform" is a predefined special combination. If it is a special combination, proceed to step 35; otherwise, proceed to step 36.

[0088] Step 35: Query the third mapping relationship. Directly query the third mapping relationship based on the combination of "high-performance type GPU + specific system-on-a-chip simulation platform" to match the combination of a dedicated hardware abstraction layer instance (register read / write and timing control logic adapted to the simulation platform's dedicated timing) and a dedicated configuration parameter layer instance (memory base address, interrupt number, and other parameters adapted to the simulation platform).

[0089] Step 36: Query the first mapping relationship and the second mapping relationship. Specifically, query the first mapping relationship by hardware type "high-performance type GPU" to determine the corresponding hardware abstraction layer instance, and query the second mapping relationship by running platform "specific system-on-a-chip simulation platform" to determine the corresponding simulation platform configuration parameter layer instance.

[0090] Step 37: Determine the Hardware Abstraction Layer and Configuration Parameter Layer. Based on the query results of Steps 34 and 35, determine the Hardware Abstraction Layer instance and Configuration Parameter Layer instance adapted to the current scenario.

[0091] Step 38: Perform priority arbitration. The configuration arbitration module collects configuration parameters from multiple configuration sources and arbitrates them according to priority rules to obtain the target configuration parameter set. It is worth noting that the specific priority rules and details of the multiple configuration sources will be explained in detail in later embodiments, and will not be repeated here.

[0092] Step 39: Update the configuration parameter layer. Write the target configuration parameter set generated in step 37 into the configuration parameter layer determined in step 36 to complete the update of the configuration parameter layer.

[0093] Step 40: Establish dynamic association. The updated configuration parameter layer and the determined hardware abstraction layer are dynamically associated through the driver global context. Specifically, the driver initialization module uses the determined hardware abstraction layer to perform hardware operations and uses the determined configuration parameter layer to configure resources, thus completing driver initialization.

[0094] It is worth noting that steps 31 to 40 above are only illustrative processes. The execution order of each step can be adjusted according to the actual architecture (for example, priority arbitration can be executed before or after determining the configuration parameter layer). Some steps can be merged or split. The initialization process in different scenarios can selectively execute some steps. The above examples do not constitute a limitation on the technical solution of this application.

[0095] In some embodiments, the multiple configuration sources include at least two of the following: runtime dynamic configuration, registry configuration, type default configuration, and global default configuration.

[0096] The priority rules are as follows: runtime dynamic configuration has a higher priority than registry configuration, registry configuration has a higher priority than type default configuration, and type default configuration has a higher priority than global default configuration.

[0097] In this embodiment, the global default configuration is a set of general configuration parameters built into the driver. It is applicable to scenarios where a specific hardware type or operating platform is not matched. It is the lowest priority configuration source, ensuring that the driver has basic configuration available in any unknown scenario, and avoiding driver startup failure due to lack of configuration.

[0098] The default configuration for a type is an initial set of configuration parameters specific to the current hardware type and operating platform combination. It is a default, dedicated configuration adapted to the current scenario and can be determined by the aforementioned two-dimensional matching mechanism. It serves as the basic input for configuration arbitration in subsequent processes. For example, this default configuration can originate from the configuration parameter array, obtained based on the matching relationship between the hardware type and the operating platform, such as the initial configuration parameters matched through the first, second, or third mapping relationship.

[0099] Registry configuration is a set of configuration parameters stored in the operating system registry or system configuration file. It supports persistent modification of configurations by users or system administrators, has higher priority than the default configuration, can override the default dedicated configuration, and meets user customization needs.

[0100] Runtime dynamic configuration is a set of configuration parameters that are dynamically passed in during driver operation through the Application Programming Interface (API), command-line tools, or runtime debugging interface. It has the highest priority and supports real-time adjustment of configuration parameters without driver restart, thus meeting the needs of runtime dynamic adjustment.

[0101] The priority order among the above configuration sources is as follows: the global default configuration, as the basic configuration, has the lowest priority; the type default configuration is an adaptation configuration for the current hardware type and operating platform, with higher compatibility than the global default configuration, and therefore has a higher priority; the registry configuration is a persistent customized configuration actively set by the user, which can override corresponding items in the type default configuration for some configuration parameters, but does not need to completely replace all the contents of the type default configuration. It is used to ensure that the user's customization intentions take effect while retaining the basic adaptation capabilities determined by the mapping mechanism; the runtime dynamic configuration is a temporary adjustment configuration passed in in real time, with the highest priority, used to ensure the flexibility of dynamic adjustment at runtime. The above sorting logic ensures both the stability of the default adaptation determined by the mapping mechanism and takes into account the needs of customization and dynamic adjustment.

[0102] In some embodiments, the configuration source may also include system firmware configuration (such as Advanced Configuration and Power Management Interface (ACPI)), firmware version configuration, hot-plug event configuration, etc. The priority rules can also be adjusted according to the actual scenario requirements. For example, the priority of system firmware configuration can be set to be higher than the type default configuration and lower than the registry configuration, or the priority of hot-plug event configuration can be set to be higher than the runtime dynamic configuration. As long as the priority rules follow the core logic of "customized configuration overriding default configuration", no matter how the specific configuration source type or priority order is adjusted, it falls within the protection scope of this application.

[0103] By defining multi-level configuration sources and corresponding priority rules, while retaining the set of configuration parameters determined by the two-dimensional mapping mechanism, customized configuration sources such as registry configuration and runtime dynamic configuration are introduced. This avoids the limitations of a single configuration source and prevents parameter conflicts between multiple configuration sources through priority rules. It covers multi-scenario driver configuration requirements from global default configuration, type default configuration, registry configuration to runtime dynamic configuration, further improving the flexibility, scenario adaptability and user customizability of driver configuration.

[0104] In some embodiments, the target configuration parameter set is determined from multiple configuration sources according to a priority rule, including: For each configuration item in the registry, multiple configuration sources are searched sequentially in descending order of priority. If the current configuration source contains the configuration item, the value of the configuration item in the current configuration source is used as the target value of the configuration item. If the current configuration source does not contain the configuration item, the search continues to the next configuration source. Based on the target values ​​of multiple configuration items, the target configuration parameter set is determined.

[0105] In this embodiment, the registry serves as a list of configurable parameters for the driver, representing a collection of all adjustable configuration parameters supported by the driver. It defines the scope of configuration arbitration and prevents the introduction of invalid configuration parameters. Specifically, the registry only defines the metadata of the configuration parameters, including but not limited to configuration item names (such as video memory allocation size, interrupt number, power policy level), parameter types (such as integer, boolean, enumeration), value ranges, and default values. It does not contain the specific parameter values, which are determined by the subsequent multi-configuration source lookup process.

[0106] In this embodiment, the configuration item is the smallest configuration unit in the registry. Each configuration item corresponds to a configurable feature in driver operation. For example, the configuration item "vram_size" corresponds to the video memory allocation size, "irq_num" corresponds to the interrupt number, and "power_policy" corresponds to the power policy level. Each configuration item uses a unified naming and definition in all configuration sources to ensure that parameters between different configuration sources are aligned and arbitrated.

[0107] The process of determining the aforementioned target configuration parameter set may include, but is not limited to: First, the configuration arbitration module loads the driver registry to obtain a complete list of configuration items for the current scenario. Then, following the priority order of "runtime dynamic configuration > registry configuration > type default configuration > global default configuration," it performs a lookup and matching process for each configuration item one by one. That is, it starts querying from the highest priority runtime dynamic configuration source. If the definition of the current configuration item exists in this source, the value of that configuration item is directly recorded as the target value, and lower priority configuration sources are not queried. If the configuration item does not exist in the runtime dynamic configuration source, it continues to query the next priority registry configuration source. If it exists, the target value is recorded; if it does not exist, it continues to query the type default configuration source, and so on, until the lowest priority global default configuration is found. Since the global default configuration contains the definitions of all configuration items, each configuration item can eventually match its corresponding target value. After the target values ​​of all configuration items are determined, the target values ​​of all configuration items are integrated into the final target configuration parameter set. The above process adopts the logic of "item-by-item search and high-priority first hit", which eliminates the need to compare all configuration items from different configuration sources, reduces the complexity of the arbitration process, and further improves the efficiency of determining the target configuration parameter set.

[0108] By determining the target configuration parameter set based on a priority lookup mechanism, only conflicting configuration items are overridden with high priority, while non-conflicting configuration items retain their original definitions. This avoids the failure of the default configuration capability determined by the mapping mechanism due to full replacement, while also fulfilling the coverage requirements of customized configurations. At the same time, it reduces the computational complexity of integrating multiple configuration sources and improves the efficiency and accuracy of configuration parameter arbitration.

[0109] In some embodiments, the target configuration parameter set includes multiple configuration items. Updating the configuration parameter layer based on the target configuration parameter set includes: for each configuration item in the target configuration parameter set, if a configuration item exists in the configuration parameter layer, overwriting the value of the configuration item in the configuration parameter layer with the value of the configuration item in the target configuration parameter set.

[0110] In this embodiment of the application, the target configuration parameter set and the configuration items of the configuration parameter layer have a completely aligned correspondence: each configuration item in the target configuration parameter set is generated based on the registry, and the configuration item structure contained in the configuration parameter layer during initialization is completely consistent with the definition of the registry. Therefore, the configuration item name, type, and quantity in the target configuration parameter set correspond one-to-one with the configuration items in the configuration parameter layer, and there are no unmatched configuration items, which ensures the accuracy of the update process.

[0111] The specific process for updating the configuration parameter layer described above may include, but is not limited to: after determining the target configuration parameter set, the configuration arbitration module iterates through each configuration item in the target configuration parameter set; for the currently iterated configuration item, it searches for a configuration item with the same name in the configuration parameter layer; then, it replaces the original value of that configuration item in the configuration parameter layer with the target value of the corresponding configuration item in the target configuration parameter set, completing the update of a single configuration item; after all configuration items have been iterated and updated, the configuration parameter layer contains the final effective target configuration parameter set, completing the entire update process. This update process is an implementation method of "determining the final configuration first, then writing it uniformly," which eliminates the need to modify the data in the configuration parameter layer in real time during the arbitration process, reducing the complexity of data flow and avoiding intermediate states where some configurations are effective while others are not during the update process.

[0112] By aligning the target configuration parameter set with the configuration items in the configuration parameter layer and updating them item by item, precise item-by-item updates of the configuration parameter layer are achieved. This ensures that the final effective configuration parameters determined by priority arbitration are fully synchronized to the configuration parameter layer, while avoiding intermediate states of inconsistency during the update process. Furthermore, the decoupling of this update process from the arbitration process avoids frequent modifications to the configuration parameter layer's data structure, improving the stability and maintainability of the configuration parameter layer.

[0113] In some embodiments, the method further includes: During driver operation, configuration change events are detected. Configuration change events are used to indicate that the value of at least one configuration item has changed. When a configuration change event is detected, for the at least one configuration item that has changed, the latest valid value of at least one configuration item is determined from multiple configuration sources according to priority rules. The configuration parameter layer is updated according to the latest valid value.

[0114] In this embodiment, the configuration change event is an event triggered during the driver runtime phase to indicate that configuration parameters need to be adjusted. Its triggering sources include, but are not limited to: users modifying registry configurations via command-line tools or graphical interface tools; applications passing runtime dynamic configurations through the driver API; system hot-plug events triggering runtime platform configuration changes; and system power policy switching triggering configuration adjustments. The configuration change event only carries the identifier of the changed configuration item and the change source information, triggering the configuration update process without restarting the driver, making it suitable for real-time configuration adjustment scenarios during driver runtime.

[0115] In one aspect of this embodiment, during the driver operation phase, the configuration arbitration module can continuously monitor configuration change events. When an event is detected, it first extracts the identifier of at least one configuration item that has changed in the event. Then, for each changed configuration item, according to the aforementioned priority rule (i.e., runtime dynamic configuration > registry configuration > type default configuration > global default configuration), it re-queries the latest valid value of the configuration item from multiple configuration sources. Since the change may only involve some configuration items, this query process only needs to perform a local search on the configuration items related to the change, without needing to re-arbitrate all configuration items. After determining the latest valid value of each changed configuration item, only the corresponding configuration item in the configuration parameter layer is updated numerically, while the configuration items that have not changed remain unchanged. In the above process, the modification of configuration parameters only involves the numerical update of the configuration parameter layer, without adjusting the already determined hardware abstraction layer, and without re-executing the matching process of the two-dimensional mapping module. At the same time, it supports individual modification of single or partial configuration items without requiring a global update of the configuration parameter layer.

[0116] It is worth noting that the configuration update process in the above-mentioned running phase has the same priority rules, configuration source definition, and correspondence between configuration items and configuration parameter layers as the arbitration logic in the initialization phase, ensuring the consistency of configuration updates. At the same time, the detection method, trigger source, and update granularity of configuration change events can be adjusted according to the actual scenario. For example, changes can be detected by polling configuration sources, or batch updates of configuration items can be supported. As long as the implementation of determining the latest valid value of the changed configuration item and updating the configuration parameter layer based on configuration change events and priority rules in the driver running phase falls within the protection scope of this application.

[0117] By introducing a local configuration update mechanism based on configuration change events during the driver runtime phase, dynamic adjustments to configuration parameters are achieved without requiring a driver restart, thus improving responsiveness to runtime scenario changes. Furthermore, this process only updates the configuration parameter layer, without involving adjustments to the hardware abstraction layer, and supports local modifications to at least one configuration item. This avoids redundant operations such as re-matching mapping relationships or updating all configuration parameters in the configuration parameter layer, reducing the performance overhead of runtime configuration adjustments and further enhancing the flexibility and efficiency of driver configuration.

[0118] In some embodiments, detecting a configuration change event includes: monitoring a registry callback function, and determining that a configuration change event has occurred in response to the registry callback function being triggered; and / or polling the modification timestamp of the configuration file, and determining that a configuration change event has occurred in response to a change in the modification timestamp.

[0119] In this embodiment, the registry callback function is a kernel-level or user-level callback mechanism provided by the operating system for monitoring changes to registry configuration items. When driver-related configuration items in the registry are modified, added, or deleted, the operating system automatically triggers this callback function, carrying the changed configuration item information. The modification timestamp of the configuration file is system metadata for a dedicated configuration file storing registry configurations. It records the time when the file's content was last modified. When the configuration file is edited and saved, this timestamp is updated synchronously and can be used to determine whether the configuration file content has changed.

[0120] The specific implementation process of the above two detection methods may include the following steps: 1. Detection based on registry callback functions: During the driver initialization phase, the configuration arbitration module registers callback functions with the operating system for the driver-specific registry path and subscribes to all configuration item change events under this path. During the driver runtime phase, once a user or application modifies any configuration item under this path, the operating system immediately triggers the registered callback function. The configuration arbitration module receives the change notification and the changed configuration item identifier through the callback function, thus determining that a configuration change event has occurred. This method is an event-driven detection method with high real-time performance and no additional performance overhead.

[0121] 2. Polling detection based on configuration file modification timestamps: During driver initialization, the configuration arbitration module records the modification timestamp of the current configuration file as a baseline value. During driver operation, the configuration arbitration module reads the current modification timestamp of the configuration file according to a preset polling cycle (e.g., once per second) and compares the current timestamp with the baseline value. If the current timestamp is inconsistent with the baseline value, it is determined that the configuration file content has changed, confirming that a configuration change event has occurred. Subsequently, the configuration file content is reloaded and the changed configuration items are parsed. This method is an active polling detection, compatible with file system scenarios without callback mechanisms, and is simple to implement and highly versatile.

[0122] In some embodiments, the detection methods for configuration change events include, but are not limited to: monitoring API call events, determining that a configuration change event has occurred in response to the configuration modification API provided by the driver being called; monitoring hot-plug event notifications, determining that a configuration change event has occurred in response to device hot-plug events reported by the system; and monitoring system power state switching events, determining that a configuration change event has occurred in response to the system entering hibernation, waking up, or a power policy change. It is worth noting that regardless of the detection method used, as long as the change of configuration items can be accurately detected and the subsequent update process can be triggered, it falls within the protection scope of this application.

[0123] By providing two methods for detecting configuration change events—registry callback function monitoring and configuration file timestamp polling—it ensures both the real-time performance of event-driven detection and compatibility with scenarios without callback mechanisms. Furthermore, by supporting the combined use of multiple detection methods, it can comprehensively detect configuration parameter changes under different circumstances, providing a reliable event triggering basis for dynamic configuration updates during runtime, and further improving the response speed and scenario adaptability of driver configuration adjustments.

[0124] For example, please refer to Figure 4 , Figure 4 This is a flowchart of updating configuration parameters during the driver runtime phase provided in one possible implementation of this application. Its application scenario is as follows: After the driver completes initialization and is loaded into the operating system kernel space, it enters a stable phase of continuous operation. At this time, it is necessary to support dynamic adjustment of configuration parameters (such as user modification of the registry, application passing runtime configuration through API, system hot-plug events triggering configuration changes, etc.) to ensure that the driver can still adapt to device requirements in different operating environments without restarting the driver or reloading the entire driver module.

[0125] Combination Figure 4 The process of updating configuration parameters during the above-mentioned driver operation phase includes at least one of the following steps 41 to 49: Step 41, modify the INF configuration items. Users can use a text editor to modify the configuration items in the driver installation information file (INF), such as changing the feature level parameter from the basic level to the high level.

[0126] Step 42: Modify the registry configuration. The operating system reads the modified INF file and writes the changed configuration items to the driver configuration key in the operating system registry. Registry configuration items may include, but are not limited to, feature levels, buffer sizes, debug switches, etc.

[0127] Step 43: Listen for registry callback functions. The arbitration module monitors driver configuration key value changes by registering operating system registry callback functions. These registry callback functions are automatically invoked by the operating system when registry values ​​are modified, serving as a real-time registry change detection mechanism.

[0128] Step 44: Detect configuration change events. When the registry callback function is triggered, the configuration arbitration module reads the changed configuration item name and new value, confirms that a configuration change event has occurred, and clarifies the specific configuration item scope involved in this change.

[0129] Step 45: Trigger the arbitration process. Configure the arbitration module to start the arbitration process, read the current values ​​of all configuration sources for the changed configuration items, and prepare for subsequent priority arbitration.

[0130] Step 46: Perform priority arbitration. The configuration arbitration module compares the current values ​​of the same configuration item in each configuration source according to the priority rule of "runtime dynamic configuration > registry configuration > type default configuration > global default configuration". For example, the registry configuration modified in step 42 (high priority) can override the corresponding parameter in the type default configuration (low priority).

[0131] Step 47: Update the configuration parameter layer. The configuration arbitration module writes the valid configuration parameters determined after arbitration into the configuration parameter layer, updating only the changed configuration items without modifying the entire hardware abstraction layer or uninstalling or reloading the driver.

[0132] Step 48: Notify configuration of updates. The configuration arbitration module notifies the relevant driver modules that depend on the configuration parameters in the driver that the configuration parameters have been updated via callback functions or event notification mechanisms.

[0133] Step 49: Read and run the updated configuration. The driver module reads the new configuration values ​​from the configuration parameter layer and continues running according to the new configuration, thus updating the configuration parameters during the driver's runtime without requiring a driver restart.

[0134] It is worth noting that steps 41-49 above are merely illustrative processes. The execution order of each step can be adjusted according to the actual scenario, some steps can be merged or split, and the configuration update process in different scenarios can selectively execute some steps. The above examples do not constitute a limitation on the technical solution of this application. For example, in step 44, the detection of configuration change events uses a response mechanism triggered by a registry callback function. In other implementations, methods such as polling the modification timestamp of the configuration file mentioned in the above embodiments can also be used to continuously and actively detect configuration change events during the driver operation phase. This application does not limit the specific detection method for configuration change events.

[0135] In some embodiments, the configuration parameter layer includes a list of critical resources that indicate hardware resources that need to be isolated. The method further includes: The system detects the driver's operating environment, which includes both virtual and physical operating environments. When the driver is in a virtual operating environment, it remaps the access paths of the hardware resources indicated by the critical resource list based on the driver's operating mode and / or operating platform to achieve isolation.

[0136] In this embodiment, the critical resource list is a dedicated configuration item in the configuration parameter layer, storing a set of hardware resource identifiers that need to be isolated. Hardware resources typically possess the following characteristics: they are resources upon which the core functions of the device depend, and are prone to access conflicts in multi-instance / multi-virtual machine scenarios, such as hardware register address spaces, interrupt numbers, shared video memory regions, Direct Memory Access (DMA) channels, and device configuration ports. The critical resource list can be implemented using arrays, linked lists, or bitmap structures to store resource identifiers. For example, it can store a list of register base addresses and interrupt numbers that need to be isolated, loaded by the configuration parameter layer during driver initialization or runtime environment switching, providing a clear scope definition for subsequent isolation operations.

[0137] In this embodiment, the detection of the driver's runtime environment is performed by the virtualization isolation module. The virtualization isolation module first determines whether the current driver is running on a physical machine (physical runtime environment) or a virtual machine (virtual runtime environment) by reading the virtualization identifier register, querying the virtualization feature bits in the system firmware, and calling the virtualization detection interface provided by the operating system. If it is in a virtual runtime environment, it further obtains the driver's running mode and running platform: the running mode includes host mode, guest mode, etc.; the running platform can be detected by the virtualization isolation module itself by reading the virtualization platform signature and querying the capability information reported by the virtualization layer, or the output results of the platform detection module in the above embodiment can be reused (after completing the hardware type and running platform detection, the platform detection module can synchronize virtualization-related running platform information to the virtualization isolation module). This application does not limit the source of the running platform.

[0138] In one aspect of this embodiment, access path remapping refers to the process of replacing the driver's original access address / interface to hardware resources with an isolated access address / interface allowed by the virtualization environment. Exemplarily, implementation methods may include, but are not limited to: 1. Address mapping: If the hardware resource is a register address space, the original physical register address is remapped to the virtual register address corresponding to the virtual machine, or to the simulated register address provided by the virtualization layer, so that the driver accesses the isolated address space and avoids conflicts caused by directly accessing physical hardware resources.

[0139] 2. Interface replacement: If the hardware resources are interrupt numbers, DMA channels, etc., the original hardware interrupt numbers are replaced with virtual interrupt numbers allocated by the virtualization layer, and the original physical DMA channels are replaced with virtual DMA channels provided by the virtualization layer. The driver then interacts with the hardware through the replaced interface to achieve resource isolation.

[0140] 3. Access Restriction: For resources such as configuration ports in the critical resource list, the access control mechanism of the virtualization layer restricts the driver to access only a subset of resources allocated to the current virtual machine, and prohibits access to corresponding resources of other virtual machines or the host machine.

[0141] It is worth noting that this embodiment uses access path remapping as an example of isolation implementation. However, in real-world scenarios, other isolation methods can also be used, such as directly restricting the resource access range of the driver through resource permission control of the virtualization layer. Any solution that implements isolation for hardware resources indicated by the critical resource list in a virtual operating environment falls within the protection scope of this application.

[0142] By defining a list of key resources at the configuration parameter level to clarify the isolation scope, and dynamically adjusting the access path of hardware resources in combination with the operating environment and operating platform, precise isolation of hardware resources in virtualization scenarios is achieved. This not only ensures the security of hardware access in multi-virtual machine scenarios and avoids resource conflicts, but also eliminates the need to develop separate driver versions for different virtualization scenarios, thus improving the adaptability and versatility of drivers in virtualization environments.

[0143] In some embodiments, the operating mode includes a client mode. Based on the driver's operating mode and / or operating platform, the access paths to the hardware resources indicated by the critical resource list are remapped, including: When the driver is running in guest mode, the critical resource list is obtained from the configuration parameter layer; based on the running platform, the access paths of the hardware resources indicated by the critical resource list are remapped.

[0144] In this embodiment of the application, the guest mode refers to the operating mode in which the driver runs inside the virtual machine and interacts with the virtualization layer as part of the virtual machine's operating system. In this mode, the device is usually allocated to the virtual machine by the virtualization layer through methods such as passthrough or semi-virtualization. The driver needs to adapt to the resource allocation rules of the virtualization layer to avoid resource conflicts with other virtual machines or the host machine.

[0145] In one aspect of this embodiment, a three-layer progressive detection mechanism can be used to determine the final isolation strategy. Combining the detection logic of the above embodiment, the specific process is as follows: First layer: Operating environment detection The virtualization isolation module first performs runtime environment detection. By reading the virtualization identifier register, querying the system firmware virtualization feature bits, and calling the operating system virtualization detection interface, it determines whether the current driver runtime environment is a physical runtime environment or a virtual runtime environment. If the detected runtime environment is a physical runtime environment, no further isolation process is required, and the driver directly accesses resources according to the physical hardware rules. When the detected runtime environment is a virtual runtime environment, the second layer of detection is initiated.

[0146] Second layer: Operation mode detection Once the virtual operating environment is confirmed, the virtualization isolation module further detects the driver's operating mode to determine if it is in guest mode. The detection methods include: reading the mode identifier issued by the virtualization layer, querying the interaction protocol version between the driver and the virtualization layer, and detecting the device allocation type (e.g., whether it is a passthrough device). If the operating mode is not guest mode (e.g., host mode), the corresponding general resource access rules are applied; when the operating mode is confirmed to be guest mode, the third-layer detection is initiated.

[0147] Third layer: Platform matching and isolated execution After confirming that the operating environment is a virtual operating environment and the operating mode is guest mode, the virtualization isolation module obtains the operating platform (the operating platform can be detected by the virtualization isolation module itself, or the output result of the above platform detection module can be reused, and this application does not limit this); then it reads the list of key resources from the configuration parameter layer, determines the corresponding isolation policy according to the current operating platform, and performs access path remapping on the hardware resources indicated by the list of key resources to achieve resource isolation.

[0148] It is worth noting that the order of the three-layer detection can be adjusted according to the actual architecture. For example, the operating mode can be detected first and then the operating environment can be detected. Multiple information can also be detected simultaneously. As long as the isolation strategy is ultimately determined based on the multi-layer judgment logic of "operating environment-operating mode-operating platform", it falls within the protection scope of this application.

[0149] For example, through the aforementioned layered detection and remapping mechanism of the virtualization isolation module, it is possible to achieve the effect of dividing a single physical GPU into multiple virtual GPU instances, with each instance independently assigned to a virtual machine, without modifying the core code of the physical GPU driver. Specifically, the core functions of the physical GPU driver (such as register operations defined by the hardware abstraction layer and graphics rendering instruction processing) are decoupled from the isolation requirements of the virtualization scenario, and the driver core code does not need to be modified for the virtualization scenario. As an independent extension module, the virtualization isolation module only obtains the key resource list and performs access path remapping through the configuration parameter layer during driver initialization and runtime. All virtualization-related adaptation logic can be encapsulated within the virtualization isolation module to achieve decoupling from the hardware operation logic of the driver core. Secondly, the hardware resources of a single physical GPU (such as register address space, interrupt number, video memory area, DMA channel, etc.) can be pre-divided into multiple resource subsets, each of which corresponds to a virtual GPU instance. When multiple virtual machines start, the virtualization layer allocates a resource subset to each virtual machine and configures the corresponding virtualization runtime platform information. When the driver runs in guest mode within the virtual machine, the virtualization isolation module detects and confirms that the current environment is guest mode. Based on the runtime platform issued by the virtualization layer, it remaps the original physical resource access paths in the critical resource list to the access paths of the resource subset allocated to the current virtual machine. This ensures that the driver within each virtual machine can only access its own resource subset, achieving multi-instance isolation from the driver level, which is equivalent to a single physical GPU being divided into multiple independent virtual GPU instances.

[0150] By obtaining a list of key resources from the configuration parameter layer in guest mode and performing access path remapping on hardware resources according to the running platform, precise resource isolation is achieved for virtualized guest scenarios, ensuring the security of driver access to hardware resources in multi-virtual machine environments and avoiding resource access conflicts between different virtual machines.

[0151] In some embodiments, remapping access paths for hardware resources indicated by the critical resource list, based on the operating platform, includes: Based on the operating platform, determine the corresponding predefined resource mapping strategy; based on the resource mapping strategy, calculate the address offset; based on the address offset, remap the access requests of the hardware resources indicated by the critical resource list to virtual addresses, which are virtualized addresses determined based on the address offset and isolated from the physical addresses.

[0152] In this embodiment, the resource mapping strategy is a hardware resource access path conversion rule for different types of virtualization platforms. Its core function is to redirect, offset, or translate the access paths of hardware resources in the key resource list, thereby achieving isolation between virtual client resources and host physical resources. The resource mapping strategy can be differentiated according to the operating platform. For example, it can be stored using a key-value pair structure, where the key is the operating platform identifier and the value is the mapping rule corresponding to that operating platform. The rule content includes the correspondence between hardware resource types and offsets, address translation algorithms, resource isolation granularity, etc. Different operating platforms correspond to different resource mapping strategies, ensuring compatibility with the resource allocation rules of different virtualization platforms.

[0153] In this embodiment of the application, the specific execution process of the above-mentioned access path remapping may include, but is not limited to, the following steps: Step 1: Determine the resource mapping strategy corresponding to the running platform: After the virtualization isolation module obtains the current running platform, it queries the predefined resource mapping strategy set and matches it to obtain the exclusive resource mapping strategy corresponding to the current running platform. This strategy defines the remapping rules for hardware resources such as register resources, video memory resources, and interrupt resources.

[0154] Step 2: Calculate the address offset: The virtualization isolation module reads the list of key resources from the configuration parameter layer. For each hardware resource in the list (such as the physical base address of a set of hardware registers, the physical start address of a video memory block, etc.), it calculates the address offset of the resource according to the matched resource mapping strategy. The calculation logic of the address offset is defined by the resource mapping strategy. For example, if the hardware resource is a register base address, and the strategy defines the offset as a fixed step size corresponding to the virtual machine sequence number allocated by the virtualization layer, then the address offset = virtual machine sequence number × register set size; if the resource is a video memory block, and the strategy defines the offset as the difference between the video memory allocation start address issued by the virtualization layer and the physical video memory start address, then this difference is directly used as the address offset.

[0155] Step 3: Remapping to Virtual Address: For each hardware resource in the critical resource list, the virtualization isolation module adds the address offset calculated in Step 2 to the original physical access address of the resource to obtain the remapped virtual address. Subsequent driver access requests to critical resources (such as reading / writing registers, accessing video memory) are all initiated through this virtual address. The virtualization layer further maps this virtual address to a subset of physical resources allocated to the current virtual machine, achieving isolation from host physical resources and other virtual machine resources. This virtual address is only visible to drivers within the current virtual machine and is completely isolated from the physical address, avoiding resource access conflicts across virtual machines / hosts.

[0156] It is worth noting that the above remapping process is illustrated using address offset calculation as an example. In actual scenarios, resource mapping strategies can also adopt other implementation methods such as address translation table lookup and virtualization layer interface forwarding. As long as the solution is based on the resource mapping strategy corresponding to the running platform and converts the access path of critical resources to achieve isolation, it falls within the protection scope of this application.

[0157] By matching the corresponding resource mapping strategy based on the running platform and calculating the address offset according to the resource mapping strategy to realize the hardware resource access path remapping, a mechanism is achieved to realize precise resource isolation under different virtualization platforms. It not only adapts to the differentiated resource allocation rules of different virtualization platforms, but also completes the access path conversion in a lightweight manner through address offset, without modifying the core driver code, reducing the complexity of virtualization adaptation, and ensuring the security of resource isolation between multiple virtual machine instances.

[0158] In some embodiments, hardware resources include at least one of the following: register address space and video memory region. Remapping access requests for hardware resources indicated by the critical resource list to virtual addresses based on address offsets includes: Based on the address offset, access requests to the register address space are remapped to the virtual register address space; and / or, access requests to the video memory region are remapped to the virtual video memory region.

[0159] In this embodiment, the register address space is a set of continuous or non-contiguous physical addresses used to control hardware behavior and read hardware status. It includes, but is not limited to, control register groups (such as rendering control registers and interrupt control registers) and status register groups (such as device serial number registers and temperature status registers). These are core resources for direct interaction between the driver and hardware. In multi-virtual machine scenarios, direct access to physical registers can lead to configuration conflicts, requiring isolation mapping. The video memory region is the address space of the processor's physical video memory (or a portion of the system's shared video memory). It stores graphics-related data such as texture data, frame buffers, and command buffers. In multi-virtual machine scenarios, this is a hardware resource with significant resource consumption and prone to access conflicts, also requiring isolation mapping.

[0160] In one aspect of this embodiment, the virtualization isolation module can perform offset calculation on the physical base address of each register based on the calculated address offset for the register address space included in the critical resource list: Virtual register address = Physical register base address + Address offset; Subsequent register read / write requests initiated by the driver (such as writing to the rendering control register or reading the interrupt status register) are all initiated through the virtual register address. The virtualization layer maps this virtual address to a subset of physical registers allocated to the current virtual machine, thereby achieving register access isolation between different virtual machines and avoiding mutual interference in configuration.

[0161] In one aspect of this embodiment, the virtualization isolation module, for the video memory region included in the critical resource list, can first perform basic address translation based on the calculated address offset: initial virtual video memory address = physical video memory base address + address offset. Based on this, it can also combine the video memory list information in the virtual machine context to complete the mapping. The video memory list is a set of video memory block indices issued by the virtualization layer to the current virtual machine that it is allowed to access. The virtualization isolation module matches and verifies the initial virtual video memory address with the video memory list, retaining only the addresses corresponding to the allowed video memory blocks in the list and filtering out the disallowed addresses, ultimately obtaining the virtual video memory region. Subsequent video memory access requests initiated by the driver (such as texture data writing and frame buffer reading) can all be initiated through this virtual video memory region, achieving isolation of video memory resources.

[0162] It is worth noting that the isolation of the video memory region is not limited to the above-mentioned "address offset + video memory list" implementation method. It can also be implemented by any one or more combinations of the following methods, all of which fall within the scope of protection of this application: 1. Static partitioning: The physical video memory is divided into several blocks of fixed size. Each virtual machine is allocated an independent video memory block region. The address offset is the difference between the starting address of the corresponding video memory block and the physical video memory base address. It is suitable for scenarios with stable resource requirements.

[0163] 2. Dynamic paging: Introducing a graphics page table (GPT) similar to the memory management unit (MMU) of the central processing unit (CPU) to support fine-grained graphics memory page mapping. The address offset is the page offset corresponding to the entry in the graphics memory page table, thereby improving the utilization of graphics memory resources.

[0164] 3. Base address offset + boundary check: The base address and access limit of each virtual machine's video memory are set through hardware registers. Combined with the boundary check of the driver layer, a rough isolation is achieved. The address offset is the difference between the set video memory base address and the physical video memory base address. This method is simple to implement and has high hardware compatibility.

[0165] By designing remapping mechanisms for the register address space and the video memory region respectively, precise isolation of the two types of core hardware resources is achieved, ensuring the independence of hardware resource access in multi-virtual machine scenarios and avoiding resource access conflicts.

[0166] In some embodiments, hardware resources include interrupt numbers. After determining the corresponding predefined resource mapping strategy based on the operating platform, the method further includes: remapping access requests for interrupt numbers to virtualized interrupt numbers according to the resource mapping strategy.

[0167] In this embodiment, the interrupt number is a hardware interrupt identifier used by the processor when initiating an interrupt request. It is used to notify interrupt events such as rendering completion, data transmission completion, and hardware errors, and is a core resource for asynchronous event interaction between the driver and the hardware. In a virtual machine scenario, if the virtual guest driver directly uses the host's hardware interrupt number, interrupt events cannot be accurately distributed to the corresponding virtual machine. Therefore, it is necessary to remap the interrupt number to a virtualized interrupt number to achieve interrupt resource isolation.

[0168] In this embodiment, the virtualization isolation module can match the corresponding resource mapping strategy according to the current running platform, and then read the interrupt number mapping rule from the strategy. The rule defines the correspondence between interrupt numbers and virtualization interrupt numbers, or the allocation algorithm for virtualization interrupt numbers. For interrupt numbers contained in the critical resource list, the module converts them into corresponding virtualization interrupt numbers according to the mapping rule. For example, if the resource mapping strategy defines "the virtualization interrupt number corresponding to the interrupt number is: virtualization interrupt number = interrupt number + virtual machine serial number × interrupt number step size", the corresponding virtualization interrupt number can be calculated based on the current virtual machine serial number. When the driver registers the interrupt handling function with the hardware or the hardware triggers an interrupt request, the remapped virtualization interrupt number is used, and the virtualization layer will accurately distribute the virtualization interrupt number to the current virtual machine.

[0169] It is worth noting that the above-mentioned interrupt number remapping implementation is only an example. Other implementation methods such as dynamic allocation of interrupt numbers and interrupt virtualization interface forwarding can also be used. As long as the scheme is based on the resource mapping strategy to remap physical interrupt numbers to virtualized interrupt numbers to achieve isolation, it falls within the protection scope of this application.

[0170] By remapping interrupt numbers to virtualization interrupt numbers, interrupt resource isolation is achieved, ensuring accurate distribution of interrupt events in multi-virtual machine scenarios, avoiding interrupt conflicts or false event triggering, and improving the stability and reliability of driver interrupt handling in virtualization environments.

[0171] For example, please refer to Figure 5 , Figure 5 This is a schematic diagram of virtualization isolation provided in one possible implementation of this application. Figure 5 The virtualization isolation shown is used to achieve secure isolation and address / interrupt remapping between virtual machines and host hardware resources when virtual machines access host hardware resources.

[0172] Specifically, Figure 5 The physical operating environment 510 shown represents the actual hardware resource space, the virtual operating environment 520 represents the virtual resource space accessed by the virtual client, and the virtualization isolation module 260 is the control module, responsible for detecting the operating environment, operating mode, and operating platform, and executing the corresponding resource mapping strategy. Specifically, Figure 5 The virtualization isolation process shown may include, but is not limited to: 1. Driver loading initiates the virtualization detection process. The driver is loaded in the virtual guest environment, and the virtualization isolation module 260 initiates the detection process.

[0173] 2. The runtime environment detection layer in the virtualization isolation module 260 identifies the current runtime environment by reading the virtual mode field set by the hypervisor, detecting the virtual machine characteristic register, and querying the virtual machine identifier. When the virtual mode field indicates that the current runtime environment is virtualized, the runtime environment detection layer outputs a virtualization flag as true, confirming that the current runtime environment is virtual 520, not physical runtime environment 510.

[0174] 3. The runtime mode detection layer in the virtualization isolation module 260 distinguishes the current runtime mode by reading the hypervisor configuration, detecting the guest identifier, and querying the virtualization role register. When it is detected that the processor is currently running in a virtual guest rather than the virtual machine host, the runtime mode detection layer outputs the guest flag as true, confirming that the current processor is in virtual guest mode.

[0175] 4. The runtime platform detection layer in the virtualization isolation module 260 identifies the type of the current virtualization runtime platform, such as the first virtualization platform or the second virtualization platform. Different virtualization platforms may use different resource isolation mechanisms. The output of the runtime platform detection layer will be input to the resource remapping engine to select the appropriate mapping rule.

[0176] 5. The virtualization isolation module 260 obtains a list of key resources from the configuration parameter layer and reads the hardware resource information therein. For example, Figure 5 The diagram shows a portion of the hardware resource information: the register address space 0x10000000 in the physical runtime environment 510, interrupt numbers IRQ15-20, the video memory area 0x00000000-0xFFFFFFFF, and the system interface offset 0x0 (standard physical offset).

[0177] 6. The resource remapping engine in the virtualization isolation module 260 calculates the address offset dedicated to the virtual client based on the three-layer detection results. This offset ensures that the resource access address of the virtual client does not overlap with the host's physical address space, corresponding to the system interface offset 0x10000000 (address offset) of the virtual runtime environment 520 in the figure.

[0178] 7. The virtualization isolation module 260 remaps the register access requests of the virtual guest to the virtualized address space, using a dedicated offset for address translation. That is, the register address space 0x10000000 in the physical runtime environment 510 is remapped to the virtual register address space 0x20000000 in the virtual runtime environment 520.

[0179] 8. The virtualization isolation module 260 remaps the interrupt requests of the virtual client to the virtualization interrupt number to avoid conflict with the interrupt number of the host. That is, the interrupt numbers IRQ 15-20 of the physical runtime environment 510 are remapped to the virtualization interrupt numbers IRQ 30-35 of the virtual runtime environment 520.

[0180] 9. The virtualization isolation module 260 remaps the video memory access of the virtual guest to the allocated virtual video memory area, ensuring isolation from the host's video memory area. That is, the video memory area 0x00000000-0xFFFFFFFF of the physical runtime environment 510 is remapped to the virtual video memory area 0x80000000-0xBFFFFFFF of the virtual runtime environment 520.

[0181] 10. The virtualization isolation module 260 can also establish a virtualization security mapping table to record the mapping relationship between virtual addresses and physical addresses for use during subsequent resource access. For example, this mapping table can be implicitly included in the output logic of the resource remapping engine.

[0182] 11. The driver continues initialization using the remapped resources. The driver initialization module uses the remapped resource addresses for subsequent initialization, ensuring that all resource access is performed through the virtualization isolation module 260. At this time, the driver accesses only the resources shown in the virtual runtime environment 520, namely the virtual register address space 0x20000000, virtualization interrupt numbers IRQ30-35, the virtual video memory region 0x80000000-0xBFFFFFFF, and the dedicated offset 0x10000000.

[0183] It is worth noting that the above combination Figure 5 The description is merely illustrative and does not limit the following aspects: specific address values, interrupt numbers, offset values, specific types of virtualization platforms, execution order of each step (e.g., the three-layer detection order of steps 2 to 4 can be adjusted or executed synchronously), specific implementation methods for obtaining the list of key resources, etc. Any scheme that is based on the virtualization isolation module to perform detection of the operating environment, operating mode, and operating platform, and remaps hardware resources according to the detection results to achieve isolation, falls within the protection scope of this application.

[0184] For example, please refer to Figure 6 , Figure 6 This is an architecture diagram of the driver configuration system provided in one possible implementation of this application.

[0185] The driver configuration system 200 includes a hardware abstraction layer 210, a configuration parameter layer 220, a two-dimensional mapping module 230, a platform detection module 240, a configuration arbitration module 250, and a virtualization isolation module 260. The hardware abstraction layer 210 and the configuration parameter layer 220 are dynamically linked and jointly perform driver initialization and / or driver execution. The two-dimensional mapping module 230 matches the corresponding hardware abstraction layer and configuration parameter layer based on type information. The platform detection module 240 identifies the current hardware type and operating platform and generates type information. The configuration arbitration module 250 performs priority arbitration to determine the set of configuration parameters in the configuration parameter layer. The virtualization isolation module 260 performs virtualization isolation, enabling the driver to run normally on a virtual platform. These modules work collaboratively to achieve dynamic adaptation, dynamic parameter updates, and virtualization isolation in the driver configuration system 200.

[0186] It is worth noting that the connection method, module name, communication method, interaction sequence, and specific implementation form of the coordination logic of each module in the above-mentioned driver configuration system are not limited. Any technical solution that determines the hardware abstraction layer and configuration parameter layer based on the hardware type and operating platform is within the protection scope of this application.

[0187] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0188] For example, please refer to Figure 7 , Figure 7 This is a structural block diagram of a drive configuration device provided in one possible implementation of this application. The drive configuration device 700 includes a detection module 710, a matching module 720, and an association module 730.

[0189] The detection module 710 is used to determine type information after the driver is loaded. The type information is used to indicate the processor's hardware type and operating platform.

[0190] The matching module 720 is used to determine the appropriate hardware abstraction layer and configuration parameter layer based on the hardware type and operating platform indicated by the type information. The hardware abstraction layer is used to encapsulate the set of function pointers of the processor's hardware operation interface, and the configuration parameter layer is used to store the set of configuration parameters required for driver operation.

[0191] The association module 730 is used to establish a dynamic association between the hardware abstraction layer and the configuration parameter layer, so that the driver can use the hardware abstraction layer to perform hardware operations and use the configuration parameter layer to configure resources.

[0192] In some embodiments, the matching module 720 is further configured to: determine the hardware abstraction layer and the configuration parameter layer based on the mapping table and the hardware type and operating platform indicated by the type information. The mapping table defines the correspondence between the type information and the hardware abstraction layer and the configuration parameter layer.

[0193] In some embodiments, the mapping table includes a first mapping relationship and a second mapping relationship. The first mapping relationship is the mapping between hardware type and hardware abstraction layer, and the second mapping relationship is the mapping between runtime platform and configuration parameter layer.

[0194] The matching module 720 is also used to: query the first mapping relationship based on the hardware type to determine the hardware abstraction layer; and query the second mapping relationship based on the operating platform to determine the configuration parameter layer.

[0195] In some embodiments, the mapping table includes a third mapping relationship, which is a mapping relationship between a combination of hardware type and operating platform and a combination of hardware abstraction layer and configuration parameter layer.

[0196] The matching module 720 is also used to: determine the combination of hardware type and operating platform; and based on the combination of hardware type and operating platform, query the third mapping relationship to determine the combination of hardware abstraction layer and configuration parameter layer.

[0197] In some embodiments, the driver configuration device 700 further includes an update module 740. The update module 740 is configured to: determine a target configuration parameter set from multiple configuration sources according to a priority rule, wherein the target configuration parameter set is a set of configuration parameters that ultimately take effect during the driver initialization phase; and update the configuration parameter layer according to the target configuration parameter set.

[0198] In some embodiments, the target configuration parameter set includes multiple configuration items. The update module 740 is further configured to: for each configuration item in the target configuration parameter set, if a configuration item exists in the configuration parameter layer, overwrite the value of the configuration item in the configuration parameter layer with the value of the configuration item in the target configuration parameter set.

[0199] In some embodiments, the multiple configuration sources include at least two of the following: runtime dynamic configuration, registry configuration, type default configuration, and global default configuration.

[0200] The priority rules are as follows: runtime dynamic configuration has a higher priority than registry configuration, registry configuration has a higher priority than type default configuration, and type default configuration has a higher priority than global default configuration.

[0201] In some embodiments, the update module 740 is further configured to: For each configuration item in the registry, multiple configuration sources are searched sequentially in descending order of priority. If the current configuration source contains the configuration item, the value of the configuration item in the current configuration source is used as the target value of the configuration item. If the current configuration source does not contain the configuration item, the search continues to the next configuration source. Based on the target values ​​of multiple configuration items, the target configuration parameter set is determined.

[0202] In some embodiments, the driver configuration device 700 further includes a runtime update module (not shown).

[0203] The update module is used to: detect configuration change events during driver operation, whereby configuration change events indicate that the value of at least one configuration item has changed; when a configuration change event is detected, determine the latest valid value of at least one configuration item from multiple configuration sources according to priority rules for the at least one configuration item that has changed; and update the configuration parameter layer according to the latest valid value.

[0204] In some embodiments, the update module is further configured to: monitor registry callback functions, and determine that a configuration change event has occurred in response to the registry callback function being triggered; and / or, poll the modification timestamp of the configuration file, and determine that a configuration change event has occurred in response to a change in the modification timestamp.

[0205] In some embodiments, the configuration parameter layer includes a critical resource list that indicates hardware resources that need to be isolated. The driver configuration device 700 also includes a virtualization module 750.

[0206] Virtualization module 750 is used for: The system detects the driver's operating environment, which includes both virtual and physical operating environments. When the driver is in a virtual operating environment, it remaps the access paths of the hardware resources indicated by the critical resource list based on the driver's operating mode and / or operating platform to achieve isolation.

[0207] In some embodiments, the operating mode includes a guest mode. The virtualization module 750 is also used for: When the driver is running in guest mode, the critical resource list is obtained from the configuration parameter layer; based on the running platform, the access paths of the hardware resources indicated by the critical resource list are remapped.

[0208] In some embodiments, the virtualization module 750 is further configured to: determine a corresponding predefined resource mapping strategy based on the operating platform; calculate an address offset based on the resource mapping strategy; and remap access requests for hardware resources indicated by the critical resource list to virtual addresses based on the address offsets, wherein the virtual addresses are virtualized addresses determined based on the address offsets and isolated from physical addresses.

[0209] In some embodiments, hardware resources include at least one of the following: register address space and video memory region.

[0210] The virtualization module 750 is also used to: remap access requests from the register address space to the virtual register address space based on the address offset; and / or remap access requests from the video memory region to the virtual video memory region.

[0211] In some embodiments, hardware resources include interrupt numbers. The virtualization module 750 is further configured to: remap access requests for interrupt numbers to virtualization interrupt numbers according to a resource mapping strategy.

[0212] The driver configuration device provided in this application first determines the hardware type and operating platform type information used to indicate the processor, then matches the corresponding hardware abstraction layer and configuration parameter layer based on the type information, and finally establishes a dynamic association between the two, so that the driver can call the hardware abstraction layer to perform hardware operations and read the configuration parameter layer for resource configuration. On the one hand, the dual-dimensional matching mechanism based on hardware type and operating platform can accurately adapt to the driver configuration requirements of different hardware types and operating platforms, improving the pertinence of driver configuration; on the other hand, the decoupling of the hardware abstraction layer and configuration parameter layer can reduce the amount of code modification during cross-platform runtime, and eliminates the need to maintain multiple hardware abstraction layer instances for different operating platforms, improving code reusability. In summary, the driver configuration device provided in this application improves driver development efficiency.

[0213] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0214] For example, please refer to Figure 8 , Figure 8This is a structural block diagram of a computer device provided in one possible implementation of this application. The computer device 800 can be any electronic device with data computing, processing, and storage functions. The computer device 800 can be used to implement the driver configuration method provided in the above embodiments.

[0215] Typically, computer device 800 may include a processor 810 and a memory 820.

[0216] Processor 810 may include one or more processing cores, such as a quad-core processor or an octa-core processor. Processor 810 may be implemented using at least one hardware form selected from DSP (Digital Signal Processor), FPGA (Field Programmable Gate Array), and PLA (Programmable Logic Array). Processor 810 may also include a main processor and a coprocessor. The main processor, also known as the CPU, is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 810 may integrate a GPU, which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 810 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0217] The memory 820 may include one or more computer-readable storage media, which may be non-transitory. The memory 820 may also include high-speed random access memory and NVM (Non-Virtual Machine). Volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage medium in memory 820 is used to store a computer program configured to be executed by one or more processors to implement the above-described drive configuration method.

[0218] Those skilled in the art will understand that Figure 8 The structure shown does not constitute a limitation on the computer device 800, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0219] In an illustrative embodiment, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor of a computer device, implements the aforementioned driver configuration method. Optionally, the computer-readable storage medium may be a ROM (Read-Only Memory), RAM (Random Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, or optical data storage device, etc.

[0220] In an exemplary embodiment, a chip is also provided, the chip including programmable logic circuitry and / or program instructions stored in a computer-readable storage medium. A processor of a computer device reads the programmable logic circuitry and / or program instructions from the computer-readable storage medium, and executes the programmable logic circuitry and / or program instructions, causing the computer device to perform the aforementioned drive configuration method.

[0221] In an exemplary embodiment, a computer program product is also provided, which includes a computer program that is loaded and executed by a processor to implement the driver configuration method described above.

[0222] It should be understood that "multiple" as used herein refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the step numbers described herein are merely illustrative of one possible execution order. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.

[0223] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A driver configuration method, characterized in that, The method includes: After the driver is loaded, the type information is determined, which indicates the processor's hardware type and operating platform; Based on the hardware type and operating platform indicated by the type information, an appropriate hardware abstraction layer and configuration parameter layer are determined. The hardware abstraction layer is used to encapsulate the set of function pointers of the processor's hardware operation interface, and the configuration parameter layer is used to store the set of configuration parameters required for the driver to run. A dynamic association is established between the hardware abstraction layer and the configuration parameter layer so that the driver uses the hardware abstraction layer to perform hardware operations and uses the configuration parameter layer to configure resources.

2. The method according to claim 1, characterized in that, The step of determining the appropriate hardware abstraction layer and configuration parameter layer based on the hardware type and operating platform indicated by the type information includes: Based on the mapping table and the hardware type and operating platform indicated by the type information, the hardware abstraction layer and the configuration parameter layer are determined; wherein, the mapping table is used to define the correspondence between the type information and the hardware abstraction layer and the configuration parameter layer.

3. The method according to claim 2, characterized in that, The mapping table includes a first mapping relationship and a second mapping relationship; wherein, the first mapping relationship is the mapping relationship between the hardware type and the hardware abstraction layer, and the second mapping relationship is the mapping relationship between the running platform and the configuration parameter layer; The step of determining the hardware abstraction layer and the configuration parameter layer based on the mapping table and the hardware type and operating platform indicated by the type information includes: Based on the hardware type, query the first mapping relationship to determine the hardware abstraction layer; Based on the operating platform, the second mapping relationship is queried to determine the configuration parameter layer.

4. The method according to claim 2, characterized in that, The mapping table includes a third mapping relationship, which is the mapping relationship between the combination of the hardware type and the operating platform and the combination of the hardware abstraction layer and the configuration parameter layer. The step of determining the hardware abstraction layer and the configuration parameter layer based on the mapping table and the hardware type and operating platform indicated by the type information includes: Determine the combination of the hardware type and the operating platform; Based on the combination of the hardware type and the operating platform, the third mapping relationship is queried to determine the combination of the hardware abstraction layer and the configuration parameter layer.

5. The method according to claim 1, characterized in that, After determining the appropriate hardware abstraction layer and configuration parameter layer based on the hardware type and operating platform indicated by the type information, the method further includes: According to priority rules, a target set of configuration parameters is determined from multiple configuration sources. The target set of configuration parameters is the set of configuration parameters that ultimately take effect during the initialization phase of the driver. Update the configuration parameter layer based on the target configuration parameter set.

6. The method according to claim 5, characterized in that, The target configuration parameter set includes multiple configuration items; The step of updating the configuration parameter layer according to the target configuration parameter set includes: For each configuration item in the target configuration parameter set, if the configuration item exists in the configuration parameter layer, the value of the configuration item in the target configuration parameter set is used to overwrite the value of the configuration item in the configuration parameter layer.

7. The method according to claim 5, characterized in that, The multiple configuration sources include at least two of the following: runtime dynamic configuration, registry configuration, type default configuration, and global default configuration; The priority rules include: the priority of the runtime dynamic configuration is higher than the priority of the registry configuration, the priority of the registry configuration is higher than the priority of the type default configuration, and the priority of the type default configuration is higher than the priority of the global default configuration.

8. The method according to claim 5, characterized in that, The step of determining the target configuration parameter set from multiple configuration sources according to priority rules includes: For each configuration item in the registry, the multiple configuration sources are searched sequentially in descending order of priority; If the configuration item is included in the current configuration source being searched, the value of the configuration item in the current configuration source being searched shall be used as the target value of the configuration item; If the configuration item is not found in the current configuration source, continue searching for the next configuration source; The target configuration parameter set is determined based on the target values ​​of multiple configuration items.

9. The method according to claim 5, characterized in that, The method further includes: During the operation of the driver, a configuration change event is detected, which is used to indicate that the value of at least one configuration item has changed; Upon detecting the occurrence of the configuration change event, for the at least one configuration item that has been changed, the latest valid value of the at least one configuration item is determined from the plurality of configuration sources according to the priority rule; Update the configuration parameter layer based on the latest valid value.

10. The method according to claim 9, characterized in that, The detection configuration change event includes: Monitor registry callback functions, and determine that the configuration change event has occurred in response to the triggering of the registry callback function; and / or, Poll the modification timestamp of the configuration file, and determine that the configuration change event has occurred in response to a change in the modification timestamp.

11. The method according to any one of claims 1 to 10, characterized in that, The configuration parameter layer includes a list of key resources, which is used to indicate hardware resources that need to be isolated. The method further includes: The driver's operating environment is detected, including both a virtual operating environment and a physical operating environment; When the driver is in the virtual runtime environment, the access paths of the hardware resources indicated by the critical resource list are remapped according to the driver's running mode and / or running platform to complete the isolation.

12. The method according to claim 11, characterized in that, The operating mode includes client mode; The step of remapping the access paths of the hardware resources indicated by the critical resource list according to the driver's operating mode and / or operating platform includes: When the driver is running in the client mode, the list of key resources is obtained from the configuration parameter layer; Based on the operating platform, the access paths of the hardware resources indicated by the critical resource list are remapped.

13. The method according to claim 12, characterized in that, The step of remapping the access paths of the hardware resources indicated by the critical resource list according to the operating platform includes: Based on the operating platform, determine the corresponding predefined resource mapping strategy; Calculate the address offset according to the resource mapping strategy; Based on the address offset, access requests for hardware resources indicated by the critical resource list are remapped to virtual addresses, which are virtualized addresses that are determined based on the address offset and are isolated from physical addresses.

14. The method according to claim 13, characterized in that, The hardware resources include at least one of the following: register address space, video memory area; The step of remapping access requests for hardware resources indicated by the critical resource list to virtual addresses based on the address offset includes: Based on the address offset, the access request to the register address space is remapped to the virtual register address space; and / or, The access requests for the video memory region are remapped to the virtual video memory region.

15. The method according to claim 13, characterized in that, The hardware resources include interrupt numbers; After determining the corresponding predefined resource mapping strategy based on the operating platform, the method further includes: According to the resource mapping strategy, the access request for the interrupt number is remapped to the virtualization interrupt number.

16. A drive configuration device, characterized in that, The device includes: The detection module is used to determine type information after the driver is loaded, the type information being used to indicate the processor's hardware type and operating platform; The matching module is used to determine the appropriate hardware abstraction layer and configuration parameter layer based on the hardware type and operating platform indicated by the type information. The hardware abstraction layer is used to encapsulate the set of function pointers of the processor's hardware operation interface, and the configuration parameter layer is used to store the set of configuration parameters required for the driver to run. The association module is used to establish a dynamic association between the hardware abstraction layer and the configuration parameter layer, so that the driver uses the hardware abstraction layer to perform hardware operations and uses the configuration parameter layer to perform resource configuration.

17. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program that is loaded and executed by the processor to implement the method as claimed in any one of claims 1 to 15.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which is loaded and executed by a processor to implement the method as described in any one of claims 1 to 15.

19. A chip, characterized in that, The chip includes programmable logic circuitry and / or program instructions, which, when the chip is running, are used to implement the method as described in any one of claims 1 to 15.

20. A computer program product, characterized in that, The computer program product includes a computer program that is loaded and executed by a processor to implement the method as described in any one of claims 1 to 15.

Images