Bootstrapped description table repair method, apparatus, device, and medium

Abstract

The application relates to the technical field of cloud technology, can be applied to business scenes such as financial technology and medical health, and discloses a description table repair method and device based on boot loading, equipment and a medium, which comprises the following steps: loading a boot loader and identifying a direct memory access remapping description table state to generate state information; when the state information indicates an error, the description table is repaired to obtain a repaired direct memory access remapping description table; the repaired description table is loaded into a system accessible area to generate a loading position identifier; an operating system accesses the repaired description table based on the loading position identifier; and an input / output virtualization function is enabled based on the repaired description table. According to the application, the direct memory access remapping description table is detected and repaired in the boot stage, and the repaired description table is correctly loaded and accessed by the operating system, so that the input / output virtualization function can be correctly identified and enabled even if the table is damaged or incorrectly configured.

Description

Technical Field

[0001] This invention relates to the field of cloud technology, and in particular to a method, apparatus, device, and medium for repairing a descriptor table based on bootloader. Background Technology

[0002] In existing technologies, many hardware platforms, especially older systems, often suffer from improperly configured or corrupted Direct Memory Access Remapping (DMAR) tables. The DMAR table is a critical data structure for the operating system to identify and enable hardware virtualization functions. If its information is incomplete or does not conform to specifications, the operating system cannot correctly load virtualization-related functions, even if the hardware platform supports virtualization extensions. This defect directly leads to a decline in system virtualization performance, or even prevents the virtualization environment from running properly.

[0003] In the fintech sector, virtualization technology is widely used for secure isolation of financial transaction systems, resource scheduling of financial data analytics platforms, and flexible deployment of large-scale computing clusters. However, when the DMAR table of the hardware platform contains errors, the virtualization infrastructure cannot start correctly. Financial institutions may face the risk of insufficient system performance or business interruption when performing high-concurrency transaction processing, risk modeling calculations, or compliance audits. This severely limits the application value of fintech systems in terms of security and stability.

[0004] In the healthcare sector, virtualization technology is used for high-availability deployment of electronic medical record storage systems, computing resource scheduling of medical image analysis platforms, and multi-party access support for remote consultation systems. If virtualization support is disabled, the hardware resources of healthcare data centers cannot be effectively isolated and allocated, potentially leading to delays in image processing tasks, obstructed patient data access, or interruptions to remote diagnosis and treatment services. In medical settings, any malfunction in virtualization functionality can impact clinical efficiency and patient safety. Summary of the Invention

[0005] The main objective of this invention is to provide a bootloader-based description table repair method, apparatus, device, and storage medium, which aims to solve the technical problem that when the DMAR table of the hardware platform is misconfigured or damaged, the operating system cannot correctly identify and load virtualization support functions, even if the hardware itself supports VT-d, which will lead to the inability to enable input / output virtualization.

[0006] To achieve the above objectives, the present invention provides a descriptor table repair method based on bootloader loading, comprising:

[0007] Load the bootloader, and use the bootloader to identify the status of the direct memory access remapping descriptor table and generate direct memory access remapping descriptor table status information;

[0008] When the status information of the direct memory access remapping descriptor table indicates an error, the direct memory access remapping descriptor table is repaired by the bootloader, and a repaired direct memory access remapping descriptor table is generated.

[0009] The bootloader loads the repaired direct memory access remapping descriptor table into the system's accessible area and generates a loading location identifier.

[0010] The operating system accesses the repaired direct memory access remapping descriptor table in the system's accessible area based on the load location identifier.

[0011] The input / output virtualization function is enabled based on the repaired direct memory access remapping descriptor.

[0012] Furthermore, to achieve the above objectives, the present invention provides a descriptor table repair device based on bootloader, comprising:

[0013] The boot recognition module is used to load the bootloader, identify the status of the direct memory access remapping descriptor table through the bootloader, and generate direct memory access remapping descriptor table status information.

[0014] The description table repair module is used to repair the direct memory access remapping description table through the bootloader when the status information of the direct memory access remapping description table indicates that there is an error, and generate a repaired direct memory access remapping description table.

[0015] The table loading module is used to load the repaired direct memory access remapping description table into the system's accessible area through the bootloader and generate a loading location identifier.

[0016] The kernel access module is used to access the repaired direct memory access remapping descriptor table in the system's accessible area based on the load location identifier by the operating system.

[0017] The virtualization enabling module is used to enable input / output virtualization functionality based on the repaired direct memory access remapping descriptor table.

[0018] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a boot-loaded descriptor table repair program stored in the memory and executable on the processor, wherein when the boot-loaded descriptor table repair program is executed by the processor, it implements the steps of the boot-loaded descriptor table repair method as described above.

[0019] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a boot-loaded descriptor table repair program, wherein the boot-loaded descriptor table repair program, when executed by a processor, implements the steps of the boot-loaded descriptor table repair method as described above.

[0020] Beneficial Effects: This invention relates to the field of cloud technology and can be applied to business scenarios such as fintech and healthcare. It discloses a method, apparatus, device, and medium for repairing a direct memory access remapping descriptor table based on bootloader, comprising: loading a bootloader and identifying the status of the direct memory access remapping descriptor table, generating status information; when the status information indicates an error, repairing the descriptor table to obtain a repaired direct memory access remapping descriptor table; loading the repaired descriptor table into a system-accessible area, generating a load location identifier; the operating system accessing the repaired descriptor table based on the load location identifier; and enabling input / output virtualization functionality based on the repaired descriptor table. This invention, by performing error detection and repair on the direct memory access remapping descriptor table during the boot phase and ensuring that the repaired descriptor table can be correctly loaded and accessed by the operating system, enables the hardware platform to correctly identify and enable input / output virtualization functionality even in cases of table corruption or configuration errors, ensuring the effective use of virtualization capabilities and improving system stability and compatibility. Attached Figure Description

[0021] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings:

[0022] Figure 1 This is a schematic diagram of an application environment for a description table repair method based on bootloading, according to an embodiment of the present invention.

[0023] Figure 2 This is a flowchart illustrating an embodiment of the description table repair method based on bootloading according to the present invention;

[0024] Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the description table repair device based on boot loading of the present invention;

[0025] Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0026] Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0027] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0028] The descriptor table repair method based on bootloader provided in this invention can be applied to applications such as... Figure 1 In this application environment, the client communicates with the server via a network. The server can load the bootloader from the client and identify the status of the Direct Memory Access Remapping Descriptor Table (DMR Table), generating status information. When the status information indicates an error, the descriptor table is repaired to obtain a repaired DMR Table. The repaired descriptor table is loaded into a system-accessible area, generating a load location identifier. The operating system accesses the repaired descriptor table based on the load location identifier. Input / output virtualization (I / O) functionality is enabled based on the repaired descriptor table. This invention detects and repairs errors in the DMR Table during the boot phase, ensuring that the repaired descriptor table can be correctly loaded and accessed by the operating system. This allows the hardware platform to correctly identify and enable I / O virtualization functionality even if the table is corrupted or misconfigured, ensuring the effective use of virtualization capabilities and improving system stability and compatibility. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. Specific embodiments of this invention are described in detail below.

[0029] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the bootloader-based descriptor table repair method provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0030] like Figure 2 As shown, the descriptor table repair method based on bootloader proposed in this invention includes the following steps:

[0031] S10, Load the bootloader, identify the status of the direct memory access remapping descriptor table through the bootloader, and generate direct memory access remapping descriptor table status information.

[0032] In this embodiment, loading the bootloader not only means retrieving a piece of executable code from the storage medium, but also includes the hardware-to-software transition process. After the hardware completes basic initialization through firmware, it provides a signal indicating that the memory and peripherals are operational. This signal is used to trigger the reading of the bootloader. The bootloader code is typically stored in non-volatile memory, such as a flash memory chip or the boot partition of a solid-state drive. After being read, it is placed in a preset memory region and mapped by the memory management unit, enabling the processor to execute it in an instruction-stream manner.

[0033] During bootloader execution, a set of tables defining advanced configuration and power interfaces needs to be parsed. Among these tables, the Direct Memory Access Remapping Description Table (DMRD) defines the mapping relationships between Input / Output Memory Management Units (I / O Memory). To identify its status, the integrity of this table must be verified item by item. First, the checksum field is calculated and compared to ensure that the data in the table has not been corrupted or tampered with during transmission or storage. Second, the length field is checked to confirm that the structure definition conforms to the specification. If the checksum result is incorrect or the length does not meet the specification requirements, a status message needs to be generated during the bootloader phase, containing three parts: an existence flag, checksum correctness, and length compliance. The generation of this status message is the basis for subsequent judgments on whether repairs are necessary.

[0034] The process of generating the Direct Memory Access Remapping Descriptor Table (DMTD) status information involves comparing the original table content provided by the firmware with the standard defined in the specification, item by item. The processor calculates the sum of the data fields using checksum verification logic and compares it with the checksum value in the table header to obtain the result. Length verification compares the total number of bytes defined in the table header with the actual storage length to determine data integrity. The resulting status information is a structured data representation, making it easy for the operating system or subsequent repair modules to read and interpret.

[0035] In one implementation, the bootloader can automatically read code snippets from the Master Boot Record (MBR) on the boot disk after the firmware completes hardware initialization, load them into the low address space, and then trigger processor execution. In another implementation, the bootloader can reside in a separate flash memory chip, which is directly mapped into memory by the firmware using a specified boot vector. For state recognition, a dedicated verification logic module can be used to handle checksum calculations, or this can be accomplished through a processor instruction loop. For length verification, it can be accelerated using a hardware comparator or implemented by comparing the length markers of memory locations using kernel functions.

[0036] On some platforms, different versions of verification logic can be loaded via the bootloader's plugin mechanism, thus adapting to different versions of advanced configurations and power interface specifications. Table scan speed can also be improved by adding caching strategies, such as preloading the table collection into the cache before performing verification, to reduce latency when accessing non-volatile storage. In a multi-processor environment, one core can handle bootloading and table parsing, while another core initiates memory checks in advance, thereby shortening the overall initialization time.

[0037] This embodiment loads and executes the bootloader during the boot phase, simultaneously verifying and length-checking the direct memory access remapped description table (DMR). This allows the table's status information to be obtained before the operating system takes over hardware resources. This approach ensures that the availability of virtualization support functions can be identified in advance and avoids the problem of virtualization functions failing to activate in later stages due to table corruption.

[0038] S20, when the status information of the direct memory access remapping descriptor table indicates an error, the direct memory access remapping descriptor table is repaired by the bootloader, and a repaired direct memory access remapping descriptor table is generated.

[0039] In this embodiment, when the Direct Memory Access Remapping Descriptor Table (DMRD) status information indicates an error, a repair process must be initiated immediately. The generation of this error message signifies that during the bootloader phase, checksum or length verification failed, or that the table structure contains parts inconsistent with the advanced configuration and power interface specifications. The repair process relies on the bootloader, as it has complete control over the hardware and memory before the operating system takes over, enabling it to directly access and modify the table structure in memory.

[0040] The first step in the repair process is to parse the error type based on the status information. This status information typically includes flags for checksum errors, length errors, or structural corruption, each with a different processing path. For example, a checksum error might only require recalculating and writing the checksum field, while structural corruption requires rewriting the field data. After parsing, the bootloader locates the corrupted data structure within the address range of the description table. The location process compares each field one by one using the offset defined in the table header; when a field that does not conform to the specification is detected, the corrupted location is determined.

[0041] After locating the issue, the bootloader needs to invoke pre-prepared repair strategies. These repair strategies conform to the ACPI specification, such as recalculation rules for validation fields or completion rules for missing fields. Repair strategies can be stored as templates in the bootloader's configuration area or implemented as code logic. These repair strategies replace corrupted data fields with compliant content, thereby generating a rewritten description table.

[0042] After data rewriting is complete, the checksum must be recalculated. Regenerating the checksum requires traversing the entire table's data area, performing an addition operation on each byte, taking the least significant byte, and finally writing it to the checksum field in the table header. After the checksum update is complete, the length field also needs to be verified again to ensure that the table length was not corrupted during the repair process. If the verification passes, a repair completion flag is generated, and the repaired table is output to a designated memory area as the official version for use.

[0043] In one implementation, the bootloader modifies the original table directly in memory, completing the repair through an overwrite operation. This approach is suitable for hardware platforms with limited storage space or that do not support redundant storage. In another implementation, the table can be copied to a newly allocated memory area first, and the repair operation can be performed in the new area, avoiding the loss of original data due to repair failure. This approach is suitable for financial or medical systems that require high reliability.

[0044] Alternatively, a dynamic loading and repair template approach can be used. Repair templates for different hardware platforms can be stored in non-volatile storage, and the bootloader can call the corresponding template based on the status information, thus achieving cross-platform compatibility. For some devices, repair templates can also be dynamically replaced via remote updates to support future specification changes.

[0045] This embodiment repairs the Direct Memory Access Remapping Descriptor Table (DMR) during the boot loading phase. This ensures that even if the table provided by the hardware platform is faulty, the system can still obtain a compliant table, thus preventing the operating system from being unable to enable I / O virtualization during loading due to non-compliant tables. This approach guarantees the availability of hardware virtualization functionality while avoiding system performance degradation or virtualization failure caused by table corruption.

[0046] S30, the repaired direct memory access remapping descriptor table is loaded into the system accessible area by the bootloader, and a loading location identifier is generated;

[0047] In this embodiment, the repaired direct memory access remapped table is loaded into the system-accessible area so that the operating system can read and parse this table during the initialization phase, thereby ensuring the smooth activation of virtualization functions. After completing the table repair, the bootloader needs to allocate a contiguous block of memory and ensure that this area is visible to the operating system. Continuity is a necessary condition because the descriptor table needs to be parsed by the operating system in a linear manner; if the memory space is not contiguous, it will cause parsing failure or out-of-bounds access.

[0048] After allocation, the repaired table content is completely copied to this contiguous memory space. The copy operation includes not only the table headers but also all fields and data segments to ensure table integrity. To prevent unintentional modification of the table content by the operating system or other processes during runtime, the access permissions for this space need to be set to read-only. This is achieved by modifying the page table attributes of the memory management unit.

[0049] Simultaneously, the pointers to the advanced configuration and power interface tables must be updated to point to the newly allocated contiguous memory space, enabling the operating system to locate this repaired table when scanning the system description table. After the update, the bootloader generates a load location identifier containing the starting address of the contiguous memory space and the table length information for subsequent access by the operating system. This identifier is typically stored in a kernel-readable global variable or in the boot parameter area.

[0050] In one implementation, contiguous memory space is allocated through a region reserved by the firmware, ensuring no conflicts with other runtime memory. This approach is suitable for resource-constrained platforms. Alternatively, memory can be dynamically allocated by calling a memory management service during system boot. This is more common in high-performance servers because it allows for flexible selection of address ranges based on the operating environment.

[0051] Redundancy mechanisms can also be employed on platforms with high compatibility requirements, where the repaired table is loaded into two different memory regions, generating dual identifiers. When the operating system accesses the table, the first identifier is used first, and if an access error occurs, it switches to the backup identifier, thereby enhancing stability.

[0052] In some implementations, the load location identifier can also be extended to include verification information, such as storing the hash value of the table after copying, for the operating system to verify data integrity. This is particularly useful in data-sensitive fields such as finance and healthcare.

[0053] This embodiment ensures that the operating system always has access to a compliant table during initialization by loading the repaired descriptor table into a system-accessible area during the boot phase and generating a load location identifier containing the start address and length. This not only eliminates the problem of virtualization functionality being unavailable due to corruption of the original table, but also avoids the risk of table corruption during runtime through read-only protection and address pointer updates, thereby improving the reliability and security of the system during the virtualization function activation process.

[0054] S40, the operating system accesses the repaired direct memory access remapping descriptor table in the system's accessible area based on the loading location identifier;

[0055] In this embodiment, after the repaired direct memory access remapping descriptor table has been loaded into the system's accessible region, the operating system needs to locate and access the table based on the load location identifier. The load location identifier typically contains the starting address of the contiguous memory space and the table length information, which is the key basis for the operating system to locate the memory region. During the initialization phase, the operating system initiates a scanning process of the advanced configuration and power interface table set. This process is completed by the kernel loader and relies on the memory management unit to map physical addresses to the kernel's virtual address space.

[0056] After successful mapping, the operating system first reads the header structure of the memory space to confirm that the table is indeed a Direct Memory Access Remapping Descriptor Table (DMR). The header typically contains a signature field to identify its category and purpose. If the signature does not match expectations, the operating system treats it as an invalid table, thus avoiding loading incorrect data. After signature verification, the operating system continues to parse the repaired table's internal structure. These structures typically contain information such as device domains, address mappings, and hardware resource allocations. The parsing results are used to generate internal data structures for subsequent calls by the virtualization subsystem.

[0057] The presence of the load location identifier ensures that the operating system can access the repaired table accurately and reliably, and ensures that the parsed data is consistent with the content repaired during the boot phase, thereby eliminating the risk of virtualization initialization failure due to damage to the original table.

[0058] In one implementation, the load location identifier is passed to the operating system as a boot parameter by the bootloader, and the operating system directly reads the parameter to obtain the table address during kernel initialization. This approach is suitable for systems tightly integrated with firmware.

[0059] Load location identifiers can also be passed through kernel configuration files or the device tree, making it suitable for general-purpose operating systems running on different hardware platforms. For example, in ARM-based medical devices, the location identifier can be written to a device tree node, and the operating system resolves this node at startup to obtain the table address.

[0060] It can also query the load location identifier at runtime via system call interfaces, which is suitable for server platforms that need to dynamically detect or switch virtualization support during runtime. This type of implementation is typically used in highly available financial servers to quickly restore virtualization support under different hardware configurations.

[0061] This embodiment utilizes the operating system's access to the repaired Direct Memory Access Remapping Descriptor Table (DMRD) based on the load location identifier. This ensures that the kernel accurately locates the repaired table and verifies its integrity during virtualization initialization. This approach avoids virtualization startup failures caused by corrupted or misplaced tables, enabling stable virtualization support and improving system reliability and compatibility in complex application environments.

[0062] S50, enable input / output virtualization based on the repaired direct memory access remapping descriptor table.

[0063] In this embodiment, once the operating system has access to the repaired Direct Memory Access Remapping Descriptor Table (DMR), the next step is to enable the Input / Output Virtualization (I / O) function based on this table. The enabling process involves several key steps, each corresponding to specific hardware or software operations. First, the configuration parameters of the I / O Memory Management Unit (IMMU) must be extracted from the repaired table. These parameters include register settings, memory segment mapping methods, cache coherence control bits, and other information, forming the basis for subsequent initialization procedures. After extraction, these parameters need to be written into the I / O Memory Management Unit's control register. The register configuration status feedback determines whether the write was successful and whether the virtualization environment's memory isolation requirements are met.

[0064] With the register status confirmed to be valid, the direct memory access address remapping table can be initialized. The remapping table is typically stored in contiguous physical memory, and its structure includes page table entries, mapped address ranges, access control bits, and other components. The initialization process generates an address remapping table object, which serves as the entry point for virtualization subsystem calls within the operating system kernel. After generating the table object, the virtualization device driver needs to be loaded. The driver is responsible for interacting with the hardware control registers and providing the operating system interface to ensure that the upper-level virtual machine manager can correctly invoke IOMMU functions.

[0065] After the driver is ready, the CPU's hardware virtualization extended instruction set needs to be enabled, such as VMXON on Intel platforms and SVM instructions on AMD platforms. This step ensures that the CPU and IOMMU work together, enabling virtualization functionality to be supported at the instruction level. After these operations are completed, the I / O memory management unit is activated based on the generated address remapping table object. At this time, the system writes the remapping table base address to the RTADDR register and sets the TE (Translation Enable) flag, indicating that the virtualization function has entered the running state. Finally, the system generates a virtualization function enabling status containing status codes and error flags for subsequent diagnosis and maintenance. The status information can be recorded in the system log or debug interface.

[0066] In one implementation, configuration parameters are extracted via a firmware interface, for example, by reading the repaired table content through the ACPI subsystem in the Linux kernel and calling the `iommu_extract_params` function to obtain the parameters. This approach is suitable for use on general-purpose servers.

[0067] In another implementation, register configuration and table initialization are performed by a kernel module that communicates directly with the hardware, writing the corresponding configuration state to the device control register. This approach is suitable for high-performance financial servers, allowing for rapid configuration of multiple IOMMU units through batch initialization.

[0068] In medical device environments, a lightweight driver loading approach can be employed. By loading virtualized device drivers in a modular fashion, all functionality can be loaded at once during system startup, thus reducing startup latency. In this scenario, driver modules are dynamically loaded as needed, and the virtualization instruction set is only enabled when the device requires isolation functionality, thereby reducing resource consumption.

[0069] In cloud data center scenarios, configuration parameters and table objects can be distributed through a unified virtual machine management platform to ensure consistent virtualization configuration across different hardware nodes, thereby simplifying operation and maintenance and version control.

[0070] This embodiment enables I / O virtualization based on the repaired Direct Memory Access Remapping Descriptor Table (IDMUD), ensuring that the hardware platform can restore virtualization support even if the table is corrupted. Through parameter extraction, register configuration, IDMUD initialization, and driver loading, the system ensures proper isolation of memory access ranges across different virtual machines, preventing data leaks or conflicts across virtual machines. Simultaneously, the enabling of the CPU extended instruction set ensures that overall virtualization performance is not affected by IOMMU configuration repair. The generated status information provides a basis for subsequent diagnostics, further enhancing the system's stability and maintainability in complex scenarios.

[0071] This invention relates to the field of cloud technology and can be applied to business scenarios such as fintech and healthcare. It discloses a method, apparatus, device, and medium for repairing a direct memory access remapping descriptor table (DMR). The method includes: loading a bootloader and identifying the status of the DMR, generating status information; when the status information indicates an error, repairing the DMR to obtain a repaired DMR; loading the repaired DMR to a system-accessible area and generating a load location identifier; the operating system accessing the repaired DMR based on the load location identifier; and enabling input / output virtualization (I / O) functionality based on the repaired DMR. This invention detects and repairs errors in the DMR during the boot phase and ensures that the repaired DMR can be correctly loaded and accessed by the operating system. This allows the hardware platform to correctly identify and enable I / O virtualization even in cases of table corruption or configuration errors, ensuring the effective use of virtualization capabilities and improving system stability and compatibility.

[0072] In one embodiment, step S10 above includes:

[0073] S101 initializes the hardware environment through firmware and generates a hardware initialization completion signal;

[0074] S102, based on the hardware initialization completion signal, read the bootloader code from the non-volatile storage device;

[0075] S103, Load the bootloader code into the memory execution area and generate the memory execution area address;

[0076] S104, Execute the bootloader code in the memory execution region address;

[0077] S105, scans the Advanced Configuration and Power Interface Table set through the bootloader and generates the Advanced Configuration and Power Interface Table set scan results;

[0078] S106, Based on the scanning results of the advanced configuration and power interface table set, locate the direct memory access remapping description table in the advanced configuration and power interface table set;

[0079] S107, Verify the checksum field of the direct memory access remapping description table and generate a checksum verification status;

[0080] S108, Verify the length field of the direct memory access remapping description table and generate a length verification status;

[0081] S109, Based on the checksum verification status and the length verification status, generate direct memory access remapping descriptor table status information including direct memory access remapping descriptor table existence flag, checksum status, and length compliance.

[0082] In this embodiment, the goal is to enable the bootloader to determine the availability of the Direct Memory Access Remapping Descriptor Table (DMR) and attribute error types during the earliest controllable stage of execution. This determination output is called DMR status information. To achieve this, the firmware first initializes the hardware environment. The firmware is the first piece of system software executed after the processor is powered on, typically implemented as a unified extensible firmware interface or a traditional basic input / output system. During the firmware phase, the hardware environment completes tasks such as memory controller training, processor mode configuration, bus enumeration, and interrupt controller configuration. After these processes are completed, the firmware issues a hardware initialization completion signal. This signal can be a firmware event callback or a queryable status bit, signifying that the system memory mapping and hardware resource map have stabilized, and subsequent reads and writes will no longer be interrupted by firmware takeover. Subsequent actions are performed after this signal to avoid inconsistent access results before the memory mapping or root system description pointer is available.

[0083] After the hardware initialization completion signal arrives, the bootloader code is read from a non-volatile storage device. Non-volatile storage devices refer to media that retain data even when power is lost; common implementations include serial peripheral interface flash memory, system partitions of solid-state drives, and embedded multimedia cards. The bootloader code exists as a binary image and includes bootstrap logic, a memory allocator, table enumeration logic, and verification routines. The reading can be implemented using the block device read interface provided by the firmware or file system services, or it can directly perform sector-level data transfer based on the partition start and length. The key is to ensure that the image verification passes and alignment requirements are met.

[0084] The bootloader code is loaded into the memory execution region (MIG) and its address is generated. The MIG is a collection of physical pages with executable permissions, requiring page boundary alignment and cache consistency. The generated MIG address includes both a physical base address for device-level access and a virtual entry point for processor instruction fetching. After copying, the relevant cache lines need to be invalidated to ensure that subsequent instruction fetches retrieve the latest image content.

[0085] Upon execution of the bootloader code in the memory execution region, processor control is transferred to the entry point. This entry point initializes its own stack, page tables, and exception handling framework, subsequently driving a process for discovering system description data. During this process, the bootloader scans the Advanced Configuration and Power Interface (AMI) table set. The AMI table set consists of an array of table pointers pointed to by the root system description pointer, with each array element pointing to the physical address of its respective function table. The scanning process typically begins by retrieving the root system description pointer from the firmware system table; if the firmware does not provide it, it falls back to a fixed area in low memory and searches by signature. After obtaining the extended system description table, it traverses the entries, reading the header of each target table one by one, recording fields such as signature, length, and revision number, forming the AMI table set scan result. The scan result is a structured list, containing at least the physical address, signature, length, and resolution status of each table, serving as the basis for subsequent location and verification.

[0086] Based on the scan results, the direct memory access remapping descriptor table is located in the table set. The location action is performed using a four-byte signature, where the signature value is a fixed code representing the direct memory access remapping. Upon successful matching, the physical address and declaration length of the target table are obtained. During matching, the possibility of multiple tables of the same type needs to be considered. The location logic should prioritize the higher address version in the extended system description table, and perform version and priority checks on duplicate instances, retaining the one with the highest resolution consistency.

[0087] Two types of consistency checks are performed on the located direct memory access remapped description table. The first type is checksum field check. Specifically, this involves unsigned summation of each byte within the declared length range of the table header. The result is truncated to eight bits and compared with zero. A result of zero indicates a pass. To avoid out-of-bounds errors, the read window strictly uses the table header length as its upper bound, while also checking the mapped page boundaries. After verification, a checksum verification status is generated. This status expresses pass / fail and the type of anomaly found using an enumeration or Boolean combination, such as a non-zero byte sum, region read failure, or length out-of-bounds error. The second type is length field check. The length field comes from the table header and is used to declare the total length of the table body. Length verification requires combining the minimum boundary of the internal structure items, comparing the declared length with the cumulative length of the structure items, and confirming that there are no truncation or padding errors. If the declared length exceeds the range of continuous memory mapping, it is determined to be non-compliant. The length verification result forms a length verification status, distinguishing between pass, too short, too long, no mapping across pages, and misaligned internal item boundaries.

[0088] The checksum and verification status, along with the length verification status, are combined to generate the Direct Memory Access Remapping Description Table (DMR) status information. This status information is a structured record containing at least three types of fields: existence flag, checksum status, and length compliance. The existence flag indicates whether the target table was successfully located in the scan results; the checksum status corresponds to a summary of the checksum and verification status; and the length compliance status corresponds to a summary of the length verification status. To support subsequent remediation decisions, the status information can also carry auxiliary fields, such as the table's physical address, declared length, revision number, advanced configuration and power interface version in the firmware report, and its index position in the table set. The generation process requires consistent input; that is, if the existence flag is negative, the checksum and length fields should not be marked as passed. This constraint prevents unintended triggering of subsequent processes.

[0089] This embodiment can reliably obtain system description data by reading the bootloader code and running it in an independent memory execution area after the firmware completes hardware environment initialization; it avoids identification bias caused by relying on firmware vendor-specific interfaces by uniformly scanning and locating the advanced configuration and power interface table sets; and it can determine whether the table exists, is complete, and can be accepted by subsequent processing before entering the kernel by performing double consistency checks on the direct memory access remapped description table and merging the results into status information including existence flag, check status, and length compliance.

[0090] In one embodiment, step S20 above includes:

[0091] S201, when the status information of the direct memory access remapping descriptor table indicates an error, the error type field is parsed based on the status information of the direct memory access remapping descriptor table;

[0092] S202, based on the error type field, locate the corrupted data structure in the direct memory access remapping description table;

[0093] S203, Obtain the set of repair strategies defined by the advanced configuration and power interface specifications;

[0094] S204, Based on the set of repair strategies, rewrite the data content in the damaged data structure and generate a rewritten direct memory access remapping description table;

[0095] S205, based on the rewritten direct memory access remapping description table, determine the checksum field processing value and generate the checksum processing result;

[0096] S206, Update the rewritten direct memory access remapping description table based on the checksum processing result, and generate a checksum-updated direct memory access remapping description table.

[0097] S207, verify the compliance of the length field of the updated direct memory access remapping description table and generate a length verification status;

[0098] S208, Generate a repair completion verification flag based on the length verification status;

[0099] S209, when the repair completion verification flag indicates successful repair, the updated direct memory access remapping descriptor table is output as the repaired direct memory access remapping descriptor table.

[0100] In this embodiment, the goal is to perform repairability assessment and structural repair on the Direct Memory Access Remapping Descriptor Table (DMR) after the bootloader takes over processor execution, and to form a memory table instance that satisfies consistency constraints. The triggering condition originates from the error indicator bit in the DMR status information. This indicator bit is jointly generated by the preceding checksum and length compliance determination, reflecting that the current table data is mismatched or missing. Based on this, the bootloader enters the repair process, first parsing the error type field. The error type field is a structured tag set written by the status collection routine, typically containing enumeration values ​​such as checksum mismatch, declaration length anomaly, internal item alignment error, missing structure item, and version mismatch. The parsing implementation extracts this area in read-only mode and maps the enumeration to executable repair action categories for action dispatch in subsequent location and rewrite phases.

[0101] Locating corrupted data structures relies on a dual mapping relationship between error category and table layout. The Direct Memory Access Remapping Description Table consists of a header and several remapping structures, common structures including hardware remapping unit descriptions, reserved memory region descriptions, and address translation service entries. The location process first determines the current layout version based on the header length and revision number, then linearly traverses according to the structure signature order or jumps directly to the target segment based on the offset index. To avoid false hits, the location logic simultaneously checks the length field and minterm boundaries of each structure; if the relative offset does not meet the alignment requirements, it does not enter the rewrite branch but is recorded as an unrepairable item or a downgraded item. The location result is returned in the form of the starting offset and the expected length, while retaining the original byte window for subsequent comparison.

[0102] The acquisition of the remediation strategy set is used to transform standard constraints into an executable rule set. The set sources include advanced configuration and power interface versions from firmware reports, processor and chipset capability bits, a list of known platform defects, and the rule base built into the bootloader. Rules express requirements for field values, bit meanings, and structural order through constraint entries, such as header revision numbers and initial checksum values, consistency between length fields and structural accumulations, minimum number of hardware remapping cell arrays, and the matching relationship between address width and flag bits. The set generation process filters out inapplicable rules based on version and capability, and sorts the remaining rules in execution order to form a deterministic rewrite sequence.

[0103] When rewriting a corrupted data structure based on a set of repair strategies, replacement content needs to be constructed in a separate working buffer to reduce the risk of damaging the original table. The rewrite process includes filling missing fields, normalizing flags, correcting structural order, and adjusting inline lengths and alignment. Specifically, the implementation writes at the byte level, maintaining consistent endianness for all multi-byte values ​​and synchronously updating associated internal counts. Unsafe rewrites are rejected, such as forcibly setting unknown reserved bits to one or writing across table declaration boundaries. After rewriting, a rewritten direct memory access remapping description table is obtained, which semantically satisfies the rule constraints but has not yet passed the overall consistency check.

[0104] To restore the consistency of the header checksum, a checksum processing result needs to be generated based on the rewritten Direct Memory Access Remapping Descriptor Table (DMI). This is achieved by temporarily setting the checksum field to zero, accumulating all bytes within the declared header length, calculating the compensation value, and writing it back to the processing result structure with an octet. If an unreachable page or out-of-bounds error is encountered during the calculation, a failure flag is returned, and no changes are written. Subsequently, the rewritten DMI is updated using the checksum processing result, resulting in a checksum-updated DMI. The update action only modifies the checksum field and does not affect other areas. After writing, a quick check is performed again to confirm that the accumulated sum is zero. If the quick check fails, the write is abandoned, and the system rolls back to the rewritten version.

[0105] The compliance check of the length field is performed after the checksum and update. It calculates the cumulative length of internal items using a structured traversal, compares the result with the header length field, and marks it as passed if they match. If they don't match, it concludes that the length is too short or too long based on the direction of the deviation. If the header length falls into unmapped memory or crosses a mapped page boundary, it is determined to be an invalid length. This conclusion, along with the alignment check and internal item count check, generates a length verification status. The length verification status is combined with the checksum and quick check results to form the basis for generating the repair completion verification flag. The repair completion verification flag is expressed using a combination of Boolean and enumeration. In the pass state, it includes the pass category and version information; in the failure state, it records the failure stage and error code for subsequent logging or downgrade path use.

[0106] If the verification flag indicates success after repair, the output verifies and updates the Direct Memory Access Remapping Descriptor Table (DMI) as the repaired DMI. The output is not copied to external media; rather, it confirms that the table in memory can proceed with the loading process. To ensure consistency, the header signature and revision number are checked again before output, and the corresponding memory page is locked as read-only to prevent accidental writes in subsequent processes. If the verification flag fails, no output is generated; the returned status carries the failure type and location information, allowing subsequent selection of rollback, rebuild, or disabling of the feature path.

[0107] This embodiment, by addressing error type-based localization and rule-based rewriting when an error indication is triggered, can accurately repair inconsistencies within the Direct Memory Access Remapping Descriptor Table (DMR). By prioritizing rewriting, checksum calculation, and length verification, it ensures the generated memory table simultaneously satisfies three consistency constraints: signature, checksum, and length. By fixing the single-point decision on the completion verification flag, only tables satisfying all constraints are output to the subsequent loading path, thus reducing the risk of errors being discovered only at the operating system stage. Compared to full replacement without distinguishing error sources, this process reduces unnecessary and potentially incompatible writes, improving success rates in multi-platform environments. Compared to skipping repairs and directly disabling functionality, it restores availability when the hardware has I / O virtualization capabilities but the descriptor table is flawed, providing a correct parameter basis for subsequent kernel configuration of the I / O memory management unit, reducing the probability of virtualization function activation failures, and shortening problem localization and recovery time.

[0108] In one embodiment, step S203 includes:

[0109] S2031, Read the repair template index from the bootloader configuration area;

[0110] S2032, Based on the repair template index, load the predefined repair template set;

[0111] S2033, Based on the predefined repair template set, parse the field rewriting strategy;

[0112] S2034, Based on the field rewrite strategy, select compatible repair strategies according to the advanced configuration and power interface specification version number;

[0113] S2035 generates a set of repair strategies that includes filtered repair strategies and version compatibility flags.

[0114] In this embodiment, the goal is to establish an executable, verifiable, and traceable chain of repair rules during the boot phase, ensuring that the rewriting of fields in the direct memory access remapping description table is based on evidence and consistent with the platform firmware environment. The repair template index originates from the bootloader configuration area, which can be a unified extensible firmware interface variable space, a non-volatile random access memory key-value area, a configuration file in the boot partition, or a trusted read-only resource partition. The index can be a single integer identifier or a composite key composed of dimensions such as platform identifier, chipset family, firmware vendor, version number, and regional policy. The read process needs to complete access permission verification, boundary verification, checksum or signature verification to avoid out-of-bounds and forgery; if the read fails, a controlled default index should be returned and the source recorded for subsequent traceability.

[0115] A predefined set of repair templates carries the structured rule resources upon which field rewriting depends. The carrier medium can be an independent binary package, compressed archive, data objects in a read-only firmware volume, or a logical set formed through multi-file directory mapping. The set is managed using versioned directories or manifest files, with different firmware versions and platform capabilities mapped to different subsets. The loading process first locates candidate subsets based on the repair template index, then verifies the manifest signature and digest, allocates read-only memory and completes alignment mapping, and performs incremental merging as needed to overlay basic rules and platform patches. The loader must ensure idempotency and atomicity to avoid rule tearing caused by partial loading. To reduce the time cost of the boot path, page-level lazy loading and on-demand expansion can be enabled, decompressing and mapping rule segments accessed for the first time.

[0116] The field rewriting strategy is a formal expression of the rewriteable fields, structural constraints, and dependencies in the description table. The strategy comprises three parts: matching predicates, rewriting actions, and post-validation. Matching predicates can be combined based on signatures, revision numbers, structure types, offset ranges, bitmasks, and value ranges. Rewriting actions support assignment, bit-wise clearing or setting, end-ordered numeric writing, rearranging structure items, inserting or removing structure items, and synchronously updating internal counters and length fields. Post-validation constrains the rewriting results to meet conditions such as alignment, minimum item length, and cross-reference consistency. The strategy syntax can be defined using compact intermediate representations, such as key-value pairs to express targets, conditions, and actions, or micro-interpreter bytecode to express execution steps. At runtime, the bootloader parses it into a low-level instruction sequence, ensuring efficient operation in a constrained execution environment. To avoid violating unknown reserved bits, the strategy level should explicitly mark the rules that reserved bits cannot be rewritten and apply strong constraints during interpretation and execution.

[0117] The advanced configuration and power interface specification version number comes from the platform firmware's reporting path. It can be obtained through the revision number field in the root system description pointer structure, the revision number field in the extended system description table, the query service provided by the firmware interface, or version information cached by the bootloader during the early enumeration phase. The goal of the compatibility filtering strategy is to eliminate rules that are inconsistent with the current specification version or incompatible with platform capabilities. The filtering process not only compares major and minor specification versions but also considers the limitations reflected in the processor feature registers, chipset function registers, and I / O memory management unit capability registers to eliminate rewriting actions that would activate disabled bits or exceed hardware limits. When multiple version adaptation branches exist for the same field, a single branch is selected based on priority to avoid rule conflicts. To improve robustness, conflict detection and rollback strategies can be introduced: when two rules act on the same target and their actions are incompatible, the rule that matches the firmware version and is on the hardware capability whitelist is prioritized; if the conflict cannot be eliminated, the entire set of rules is rolled back to the low-risk rule set.

[0118] The output of the remediation strategy set needs to carry two types of information: one is a directly executable strategy sequence, including sorted rewrite actions and corresponding matching conditions; the other is metadata, covering version compatibility flags, source lists, hash digests, signatures, tolerance settings, and scope descriptions. Version compatibility flags not only record the specification version but also the associated hardware capability snapshot and risk level, used for auditing in subsequent remediation and verification phases. The set generation process should ensure replayability, recording input indexes, list versions, and filtering decisions in a structured format for easy on-site reproduction. When the bootstrapping process is executed in a memory-constrained environment, compact coding and table-driven execution models can be used to reduce memory consumption; on platforms with higher computing power, more stringent conflict analysis and static verification can be enabled to further reduce rewrite risks.

[0119] In terms of engineering implementation, it is necessary to protect the reliability, integrity, and security of loading and parsing. For reliability, segmented verification, timeout control, and failure rollback mechanisms ensure that the failure of any sub-step will not pollute already effective resources. For integrity, manifest signing and hash verification of each segment's content prevent tampered rules from entering the execution path; in trusted execution environments, firmware-provided verification primitives are prioritized. For security, the source path and access permissions of template sets are restricted, and loading from uncertified removable media or insecure partitions is prohibited; dangerous actions, such as cross-boundary writes, writing to reserved areas, and alignment violations, are shielded at the interpretation and execution layer. For performance, a pre-compiled cache is established for high-frequency platforms and known configurations, storing the filtering results and execution sequences in a read-only area for direct reuse when the platform signature remains unchanged, reducing secondary parsing overhead. For maintainability, modular design decouples index reading, set loading, policy parsing, compatibility filtering, and set generation, facilitating unit testing and field replacement.

[0120] This embodiment constructs a complete source chain during the bootstrapping phase, from index to template, from template to policy, and from policy to compatible sequence, enabling field rewriting based on verifiable rules rather than empirical writes. The index ensures precise and controllable loading targets, the template set provides a standardized rule carrier, the parsed rewriting policy clearly defines the rewriting target and action, and the policy set generated after filtering based on specification version and hardware capabilities ensures that the execution sequence is consistent with the platform environment. Therefore, without relying on firmware updates, it provides a stable, traceable, and reproducible basis for subsequent description table repair, reduces the risk of incompatible rewriting and out-of-bounds writes, improves the adaptation success rate in multi-platform environments, and provides reliable metadata support for subsequent consistency verification and problem auditing.

[0121] In one embodiment, step S30 above includes:

[0122] S301, Obtain the length information of the repaired direct memory access remapping descriptor table;

[0123] S302, allocate contiguous memory space based on the length information;

[0124] S303, copy the repaired direct memory access remapping descriptor table to the contiguous memory space;

[0125] S304, Set the access attribute of the contiguous memory space to read-only;

[0126] S305, Update the advanced configuration and power interface table pointer to point to the contiguous memory space;

[0127] S306, Generate a load location identifier containing the start address and length information of the contiguous memory space.

[0128] In this embodiment, the goal is to stably place the repaired Direct Memory Access Remapping Descriptor Table (DMI) into the system's accessible area during the boot phase, allowing it to be subsequently discovered and used by the operating system. This requires a complete execution chain, from size acquisition to memory placement, from permission setting to pointer updating, and from address generation to traceable identifier generation. The length information comes from the length field in the descriptor table header. During reading, the signature and revision number are simultaneously checked to prevent misreading adjacent table bodies. For cases where the length is zero, out of bounds, or inconsistent with the checksum, a failure rollback strategy is implemented, and subsequent placement actions are stopped. To meet alignment and page granularity constraints, the length is rounded up to the page size or the alignment boundary required by the platform, while head and tail protection pages are reserved to avoid abnormal reads and writes caused by cross-boundary access.

[0129] Contiguous memory space is allocated through the firmware or boot environment's memory service, prioritizing storage types suitable for being reserved and enumerated by the operating system, such as reclaimable high-configuration and power interface dedicated memory or protected reserved memory. The allocation interface requires the page number and alignment mask as input, returns the physical base address, and establishes an allocation record. If allocation fails, a compromise retry is attempted in the low-address and high-address range to accommodate the addressing limitations of earlier platforms. During the copying phase, block copying is performed with the physical address as the destination, using a non-overlapping memory copying path. After copying, data fencing and cache write-back are performed to ensure consistent content for subsequent reads. On architectures with data caching enabled, row-aligned write-back and invalidation operations are added to eliminate write-merge lag.

[0130] The access attribute setting process marks the contiguous memory space as read-only and prohibits execution. Depending on the architecture, this is achieved through page table entry flags or firmware memory attribute interfaces. A common combination is a read-only and non-executable strategy consistent with caching. At the same time, to prevent third-party components from overwriting this area, a locking flag is added to the corresponding allocation record. If necessary, this area is removed from the set visible to the general allocator.

[0131] The updates to the advanced configuration and power interface table pointers follow the principles of version selection and linked list consistency. If the system has an extended system description table, the table address is appended or replaced, and the number and length of the table header are updated. At the same time, the checksum of the extended system description table is recalculated. If only the root system description table exists, the root system description table is updated in the same way, and the checksum is recalculated. In both cases, the sequentiality and atomicity of the write operations must be guaranteed. Shadow buffers and pointer swaps can be used to avoid concurrent reading of intermediate states. After completion, the update sequence is ended with a memory barrier instruction.

[0132] The load location identifier is generated after all successful placement conditions are met. Its minimum components include the physical start address and length information of the contiguous memory space. It can be expanded to include the alignment boundary at the time of placement, memory attribute snapshot, signature and revision number of the bearer table, generation timestamp and hash digest. It is stored in the handover area or reserved configuration area of ​​the bootloader in a structured layout. The location and format of the handover area are read by the operating system in subsequent access stages to establish virtual mapping and security verification.

[0133] To ensure cross-platform availability, the process adaptively handles three types of differences: pointer width selection due to address width differences, rounding strategy selection due to page size differences, and allocation type selection due to firmware memory type differences. At these points of difference, capability detection results drive the branch path, avoiding reliance on fixed constants. If any step in the entire chain fails, cleanup logic is executed to release allocated but not yet effective space and undo any written but unverified pointer changes, ensuring the system is in a safe state for continued booting.

[0134] This embodiment employs a concatenated execution chain: length-based driver alignment allocation, read-only attributes to ensure integrity, table chain updates to establish discoverable paths, and location identifiers to provide traceable entry points. The repaired Direct Memory Access Remapping Descriptor Table (DMR) is placed in a stable and visible location and reliably recognized by the operating system. Tightened permissions reduce the risk of component tampering during the later stages of booting, table chain verification and recalculation ensure consistency, and the address and metadata carried by the location identifier provide a definitive reference for subsequent access and diagnostics. Based on this, the reachability and reliability of critical table resources required for input / output virtualization can be restored without modifying the firmware, reducing adaptation failures caused by platform differences and improving the success rate of subsequent virtualization activation.

[0135] In one embodiment, step S40 above includes:

[0136] S401 initiates the advanced configuration and power interface table scan process through the operating system kernel;

[0137] S402, Based on the starting address information in the loading location identifier, locate the contiguous memory space;

[0138] S403, the memory management unit maps the contiguous memory space to the operating system kernel address space;

[0139] S404, Read the header structure of the repaired direct memory access remapping descriptor table in the kernel address space;

[0140] S405, verify that the advanced configuration and power interface signature in the header structure is a direct memory access remapping descriptor;

[0141] S406, parse the remapping structure of the repaired direct memory access remapping descriptor table, and generate the remapping structure parsing result;

[0142] S407, Based on the parsing result of the remapping structure, load the repaired direct memory access remapping descriptor table into the operating system kernel management area.

[0143] In this embodiment, the goal is to enable the kernel to stably, verifiably, and resolvably obtain the repaired direct memory access remapping descriptor table based on the load location identifier without enabling firmware interaction, and to incorporate the table content into the kernel's table management system. During the kernel's advanced configuration and power interface table scan process, the table discovery subsystem and verification subpath are initialized, and a one-time boot-time kernel buffer is established to temporarily store the location identifier and metadata generated during subsequent parsing. The load location identifier originates from the handover area during the boot phase and includes at least the physical start address and length information, and may also include the alignment granularity at the time of generation, a memory attribute snapshot, and a table signature digest. The scan process first reads the handover area, verifies the identifier structure version and length, and prevents abnormal access caused by out-of-bounds parsing or version mismatch.

[0144] Locating contiguous memory space relies on the start address and length information in the load location identifier. When early memory mapping is not yet fully established, the kernel needs to choose between identity mapping and temporary page table mapping strategies. To ensure the address can be used long-term, the kernel allocates a reserved page frame range for the target physical region and records a lifetime marker bound to this range to prevent it from being reclaimed by the page allocator. If the start address does not meet page alignment requirements or is inconsistent with the current kernel page size, rounding and boundary extension are performed to ensure the mapped range completely covers the page table body.

[0145] When mapping contiguous memory space to the kernel address space, configuration is required based on the page table format and attribute bits of the platform's memory management unit. Page table entries are set to read-only and non-executable, and the caching strategy is chosen to be consistent with the write-back or non-cached mode during the boot phase, avoiding reading old data due to differences in consistency policies. After the mapping is established, memory barriers and translation backstop buffer flushing are performed to ensure that subsequent accesses hit the new page table entries. For platforms that support physical address extension, page table entries use a descriptor format that matches the address width to avoid high-order truncation.

[0146] When reading the header structure of the repaired Direct Memory Access Remapping Descriptor Table (DMRD) in the kernel address space, the signature, length, revision number, and checksum fields are read in the fixed layout order of the header, and range and consistency checks are performed. The signature must be equal to the DMRD identifier, corresponding to a four-byte encoded value; the length should be greater than or equal to the header length and not exceed the mapping area length; and the checksum, after being accumulated byte-by-byte, should have a modulo value of zero. Failure in any of these steps triggers a rollback path, revoking the current mapping and recording the error code to prevent invalid content from being imported into the kernel table management.

[0147] After signature verification, the process proceeds to the table body parsing stage, where the remapped structure is sequentially traversed and its type is distributed. The parsing routine identifies and processes entries such as host controller definition structures, reserved memory region structures, and address translation service-related structures. From each entry, it extracts the segment number, register base address, support bitmap, device scope, and path elements, organizing them into a parsing result set according to segment number and device scope. Boundary checks and length advance verification are performed during parsing to ensure that each entry advance does not exceed boundaries or fall into empty regions. A skipping strategy is employed for unknown entry types, and the original offset of unknown entries is recorded in the parsing result set for subsequent diagnostics.

[0148] The generated remapping structure resolution result is represented as a structured object, including segment-to-control register mapping, initial device-to-domain attribution, a reserved memory window list, and a global function bit set, along with source verification information for parameter input during the subsequent input / output virtualization enabling phase. When loading the repaired direct memory access remapping description table into the kernel management area, a read-only region is first allocated in the kernel's table management memory pool, the verified table body is copied, and this region is registered in the kernel table directory. The registration action updates the table index structure in the kernel, bidirectionally associating the table with its resolution result, ensuring that the corresponding register base address and domain configuration can be directly referenced during capability query and device enumeration phases. After registration, the temporary mapping initially established for the physically contiguous region is revoked or its access permissions are downgraded, retaining only the read-only copy in the kernel management area as the entry point for subsequent use, thereby shortening the dependency chain on the handover region and reducing the risk of being overwritten.

[0149] This access process adaptively controls three types of differences. For different address widths, parsing and mapping uniformly read the width hint from the load location identifier and select a matching data structure layout. For different page sizes, the rounding strategy for mapping intervals and the construction of page table entries switch according to the capability detection results, ensuring that page boundary alignment does not disrupt table continuity. For different firmware reporting styles, it accepts both workflows that directly access addresses from the handover area and workflows that cross-validate via table chains. If there is a conflict between the two, the entry with the same signature and checksum prevails, and the difference is recorded in the log structure.

[0150] This embodiment achieves this by using controlled mapping with the load location identifier as the entry point, validity determination with signature and verification as thresholds, structured parsing with entry traversal as the main framework, and kernel read-only copy registration as the endpoint. The repaired direct memory access remapping descriptor table can be stably and accurately integrated into the kernel's table management system. The parsing results provide directly usable register addresses and domain configurations for subsequent input / output virtualization activation. Read-only mapping and copy registration reduce the risks associated with long-term exposure of the boot handover area. Boundary and consistency checks constrain invalid tables to enter the runtime state, and adaptive difference handling improves availability on heterogeneous platforms. This establishes reliable preconditions for subsequent control register programming and remapping table initialization, reducing the probability of failures during the activation phase and increasing the activation success rate.

[0151] In one embodiment, step S50 includes:

[0152] S501, Based on the repaired direct memory access remapping description table, extract the input / output memory management unit configuration parameters and generate a configuration parameter set;

[0153] S502, Based on the set of configuration parameters, configure the input / output memory management unit control register and generate the register configuration state;

[0154] S503, based on the register configuration state, initialize the direct memory access address remapping table and generate an address remapping table object;

[0155] S504, load the virtual device driver;

[0156] S505 enables the CPU hardware virtualization extended instruction set;

[0157] S506, Activate the input / output memory management unit function based on the address remapping table object;

[0158] S507 generates an input / output virtualization function enabled status containing status codes and error flags.

[0159] In this embodiment, the process of extracting input / output memory management unit configuration parameters and generating a configuration parameter set based on the repaired direct memory access remapping description table is a prerequisite for register programming and table construction. The remapping structure entries are parsed, collecting segment numbers, register base addresses, host address widths, supported capabilities, and limitation bits. Bit fields related to address translation, cache invalidation, error reporting, queue invalidation, and page-level granularity are extracted from the capability fields to form a standardized key-value set. Alignment checks and accessibility probes are performed on the register base addresses, and read-back verification confirms the mapping is effective. Device scopes and path elements are merged to generate an initial mapping list from device to domain, along with domain identifier allocation ranges and alignment requirements. The set structure simultaneously records table source verification information and the expected refresh sequence for sequential constraints in subsequent steps.

[0160] Based on the configuration parameter set, the input / output memory management unit control registers are configured. When generating the register configuration state, the translation enable bit is first kept off to prevent address translation before the root table is installed. The root table address register, domain failure queue, page table failure control, and fault tolerance and error interrupt mask bits are written according to capability constraints, and then a readback verification is performed to confirm that the written values ​​are consistent with the expected values. For platforms that support queued failures, the queue base address and queue depth are set, and an empty queue submission is performed to verify the doorbell register response. The register configuration state records the current value of each control bit, the read-only capability mask, the bit fields requiring secondary confirmation, and a snapshot of the previous error status register, providing a basis for conditional judgment during the table initialization and activation phases.

[0161] Based on the register configuration state, the direct memory access address remapping table is initialized. When generating the address remapping table object, memory for the root table and context table matching the capability fields is allocated to meet page alignment and physical continuity requirements. The root table is filled according to segment number subscripts, and the root entries point to the corresponding context tables. The context tables arrange context entries according to bus number and device function number, and write fields such as domain identifier, address width, translation mode, and page table root address. For domains requiring multi-level page tables, page table pages are allocated and zeroed out level by level, page directory entries and page table entries are written, and appropriate page granularity is set for the mapped peripheral memory range. After each domain is built, context cache invalidation and page table cache invalidation are triggered in the order specified by the register configuration state to ensure that the translation hardware does not use stale entries. The address remapping table object aggregates the root table physical address, context table set, domain-to-device mapping, invalidation policy, and refresh sequence identifier to form the unique input required for subsequent activation.

[0162] During the virtualization device driver loading process, the input / output memory management unit is abstracted as an address translation provider within the system. Kernel memory allocation and direct memory access hooks are registered, and peripheral direct memory access callbacks are replaced with domain-based address translation paths. In collaboration with the peripheral bus management component, devices are bound according to the device-to-domain mapping, completing the initialization of passthrough and shared domain operating modes. During driver loading, unavailable segments or register base addresses that fail capability verification are marked as unsuitable for translation, preventing invalid hardware writes during subsequent activation phases.

[0163] When the CPU hardware virtualization extended instruction set is enabled, the control register bits are set and the extended root state is initialized to ensure that the subsequent upper-layer virtualization stack can use device allocation, passthrough, and interrupt multiplexing capabilities. This step does not overlap with the register configuration of the input / output memory management unit, keeping the address translation hardware in a safe state of being activatable but not activated, preventing premature activation of translation before table installation is completed.

[0164] When activating the I / O memory management unit function based on the address remapping table object, the physical base address of the root table is written to the root table address register, triggering the root table pointer set command and waiting for hardware confirmation. Then, the context cache and page table cache are invalidated sequentially to ensure the hardware view is completely switched to the newly constructed table set. The error status and fault record registers are checked; if any uncleared entries exist, error clearing and secondary invalidation are performed to confirm the status is zeroed. Finally, the translation enable bit is set, and the status bits are read to confirm activation completion. For platforms that support device-requested address translation services, the policy in the address remapping table object determines whether the requested path is allowed to take effect, and corresponding callbacks are registered in the driver layer to handle translation failures and page table faults.

[0165] When generating the I / O virtualization function enable status, which includes status codes and error flags, the final value of the register configuration status, the confirmation bit of the activation command, the contents of the error register, the return code of the failure command, and the number of bound devices and domains are collected and encoded into a structured status object according to a fixed field order. The status code reflects the final phase of the activation process, and the error flags contain a bitmap of fatal errors and recoverable warnings. At the same time, the segment number or device scope where the error occurred is recorded to facilitate upper-layer policy determination on whether to allow degraded operation or retry.

[0166] Example Explanation: In the actual operation of fintech businesses, the reliable activation of virtualization functions is directly related to the stability of business systems and data security. Taking a cross-border payment clearing platform as an example, the system startup phase first requires loading a bootloader to initialize the hardware environment through firmware, ensuring that all computing and storage devices are in a usable state. When the bootloader runs in memory, it scans the set of advanced configuration and power interface tables stored in the platform firmware, locates the Direct Memory Access Remapping Descriptor Table (DMRD), verifies the compliance of its checksum and length fields, and then generates complete table status information including presence flags, checksum status, and length status. During this process, if the payment platform runs on a server cluster with older hardware, the DMRD may be corrupted or have inconsistent configurations; the system will identify the anomaly through the status information.

[0167] Once an error is detected in the descriptor table, the bootloader locates the corrupted data structure based on the error type field. It then loads a predefined set of repair templates, parses the field rewriting strategies within them, and filters for a compatible set of repair strategies based on the advanced configuration and power interface specification version numbers reported by the system firmware. These repair strategies are used to rewrite the corrupted fields, update the checksum, and revalidate the length field, thereby generating a usable repair completion flag. This ensures that the rewritten descriptor table meets consistency and integrity requirements. At this stage, the payment clearing platform obtains the repaired direct memory access remapped descriptor table, laying the foundation for subsequent virtualization environment construction.

[0168] The repaired descriptor table needs to be loaded into a system-accessible area by the bootloader. The system allocates contiguous memory space based on the descriptor table's length information and copies the repaired table to this area, setting it to read-only to prevent tampering during runtime. The pointer to the advanced configuration and power interface table is updated in the new memory space, generating a load location identifier containing the start address and length information. This identifier allows the operating system to accurately locate the descriptor table during kernel initialization, ensuring data consistency. In payment clearing systems, this process ensures that the underlying memory mapping of transaction data channels does not conflict, preventing virtualization failures due to table loading failures.

[0169] Upon entering the operating system phase, the kernel initiates an advanced configuration and power interface table scan process based on the load location identifier. Through address location and memory management unit mapping, it maps contiguous memory space to the kernel address space and reads the repaired table header structure. After verifying the signature field to confirm it is a direct memory access remapping descriptor table, it further parses the remapping structure, generates the parsing result, and loads it into the kernel management area. In financial scenarios, this stage allows the system to take over the memory remapping resources required for virtualization, ensuring that encryption key tables and transaction log caches in cross-border payment processes are accurately bound to the virtualization security domain, improving data isolation.

[0170] Based on the repaired description table, the system begins to enable the input / output virtualization function. First, the configuration parameters of the input / output memory management unit are extracted, a parameter set is generated and written to the control register, forming the register configuration state. Based on this state, the address remapping table is initialized, a table object is generated, and it is associated with the device mapping relationship. After loading the virtualization device driver, the platform can perform isolated management of different types of transaction interfaces and database access paths. Subsequently, the CPU's hardware virtualization extended instruction set is enabled to ensure that the input / output memory management unit matches the processor's virtualization capabilities. After the table object is activated, the system generates a function-enabled state containing status codes and error flags, providing reliable operational confirmation. In financial scenarios, this enables the virtualized environment to provide higher processing efficiency for high-frequency concurrent transactions and ensures that data from different institutions in the payment path does not cross-leak.

[0171] The entire process within the financial clearing platform enhances the stable activation of virtualization and strengthens device access isolation. Through the collaboration between the bootloader and the operating system, virtualization support functions can resume normal operation even when tables are corrupted or malfunctioning, preventing system downtime caused by underlying configuration errors during peak trading periods. In applications such as multi-country clearing and real-time risk control analysis, this mechanism significantly reduces risk. Simultaneously, the configured register status and activation reports provide system maintenance personnel with clear judgment criteria, enabling rapid response to potential faults and improving overall business continuity and security.

[0172] In the healthcare industry, the stable activation of virtualization functionality is directly related to the secure and efficient operation of data acquisition systems, remote monitoring devices, and health record storage platforms. Taking a wearable device-based remote management platform for chronic diseases as an example, during system startup, a bootloader is first loaded. The firmware initializes the hardware environment, ensuring that the processor, storage units, and external communication interfaces are available. When the bootloader executes in memory, it scans the set of advanced configuration and power interface tables stored in the firmware, locates the direct memory access remapping description table, and verifies its checksum and length fields. If the table is corrupted or the fields are non-compliant, the generated status information will clearly indicate the abnormal situation, preventing the operating system from rashly enabling virtualization functionality without confirming data integrity.

[0173] When the status information indicates an error, the bootloader locates the corrupted data structure based on the error type field, reads the repair template index from the configuration area, loads a predefined set of repair templates, parses the field rewrite strategies, and then filters for compatible repair rules based on the advanced configuration and power interface specification version number provided by the system firmware. Through these repair strategies, the corrupted data structure is rewritten, a new checksum is generated, and the length field is verified to ensure the table is logically and structurally correct. Once the repair is complete and a verification flag indicates success, a usable table is output. This ensures that the remote monitoring platform's devices can still obtain a reliable virtualization support environment even in abnormal situations.

[0174] The repaired table is loaded into a system-accessible area by the bootloader. A contiguous memory space is allocated based on the table's length, and the repaired table is copied into this area. The space is then set to read-only to prevent tampering by external applications or malicious code. The pointer to the advanced configuration and power interface table is updated to the new memory address, generating a load location identifier so that the operating system can accurately locate the table during subsequent startups. This step is particularly important for medical data platforms because it prevents data loss or misscheduling during health data transmission due to underlying mapping errors.

[0175] At the operating system level, the kernel restarts the advanced configuration and power interface table scan process based on the load location identifier, locates the memory space where the repair table resides, and maps this space to the kernel address space through the memory management unit. After reading the table header structure, it verifies that the identifiers within it confirm it as a direct memory access remapped description table, and then further parses the remapped structure within it, generating the parsing result and loading it into the kernel management area. In remote health monitoring scenarios, this means that the system can securely bind sensor data such as heart rate and blood glucose to the corresponding virtualization channels, ensuring that the collected data does not erroneously cross-reference when multiple devices are connected simultaneously.

[0176] Based on the repaired table, the system finally enables the input / output virtualization function. By extracting the configuration parameters of the input / output memory management unit, a parameter set is generated and written to the control register, forming the register configuration state. In this state, the address remapping table is initialized, a table object is generated, and the mapping function is activated. At this time, the virtualization device driver is loaded to ensure that various medical sensors and data acquisition modules can work correctly in the virtualized environment. Simultaneously, the processor's hardware virtualization extended instruction set is enabled to support subsequent multi-channel data processing. Finally, the system generates an enabled state with status codes and error flags, enabling the platform to provide verifiable operational assurance. In the healthcare platform, this mechanism ensures that remotely acquired data can be stably transmitted to the analysis system under high concurrency and cross-regional transmission conditions, avoiding monitoring interruptions caused by hardware table anomalies.

[0177] Throughout the process, the healthcare platform ensures the smooth activation of virtualization functions even in the event of hardware table corruption or misconfiguration, thereby guaranteeing the continuous and stable operation of wearable devices, home health monitoring terminals, and the cloud data platform. For long-term chronic disease management and telemedicine services, this mechanism enhances the system's fault tolerance and data reliability, enabling the stable transmission and storage of patients' daily vital sign data, providing doctors and health management personnel with continuous and reliable decision support.

[0178] This embodiment organizes configuration extraction, register programming, table construction, driver access, processor extension activation, and execution into a dependent sequence. Constraints for read-back verification, cache invalidation, and error cleanup are established at each stage. The address translation hardware obtains a complete and consistent root table and context relationship before activation, avoiding the use of uninstalled or partially installed tables during activation, thereby reducing the risk of translation failures and system unavailability. Using the address remapping table object as the sole activation input eliminates implicit dependencies caused by implementation differences. Device binding and domain allocation at the driver layer are completed before activation, reducing the overhead of device migration and rebinding after activation. Decoupling the processor extension and input / output memory management unit satisfies the prerequisites of the virtualization runtime stack without introducing timing interference to the translation hardware. The final structured activation state provides a deterministic basis for upper-layer strategies, enabling rapid fault location and stable reuse of successes, improving activation success rate and runtime reliability in heterogeneous hardware and multi-operating system environments.

[0179] In one embodiment, a bootloader-based descriptor table repair apparatus is provided, which corresponds one-to-one with the bootloader-based descriptor table repair method described in the above embodiments. (Refer to...) Figure 3 , Figure 3This is a schematic diagram of the functional modules of a preferred embodiment of the bootloader-based descriptor table repair device of the present invention. The modules include a boot identification module 10, a descriptor table repair module 20, a table loading module 30, a kernel access module 40, and a virtualization enabling module 50. Detailed descriptions of each functional module are as follows:

[0180] The boot recognition module 10 is used to load the bootloader, identify the status of the direct memory access remapping descriptor table through the bootloader, and generate direct memory access remapping descriptor table status information.

[0181] The description table repair module 20 is used to repair the direct memory access remapping description table through the bootloader when the status information of the direct memory access remapping description table indicates that there is an error, and generate a repaired direct memory access remapping description table.

[0182] Table loading module 30 is used to load the repaired direct memory access remapping description table into the system accessible area through the bootloader and generate a loading location identifier.

[0183] Kernel access module 40 is used to access the repaired direct memory access remapping descriptor table in the system's accessible area based on the load location identifier by the operating system;

[0184] Virtualization enabling module 50 is used to enable input / output virtualization functionality based on the repaired direct memory access remapping descriptor table.

[0185] In one embodiment, the guide identification module 10 is specifically used for:

[0186] The hardware environment is initialized through firmware, and a hardware initialization completion signal is generated.

[0187] Based on the hardware initialization completion signal, the bootloader code is read from the non-volatile storage device;

[0188] The bootloader code is loaded into the memory execution region, and the memory execution region address is generated;

[0189] Execute the bootloader code located in the memory execution region address;

[0190] The advanced configuration and power interface table set is scanned by the bootloader, and the scan results of the advanced configuration and power interface table set are generated.

[0191] Based on the scanning results of the Advanced Configuration and Power Interface Table set, the Direct Memory Access Remapping Description Table is located in the Advanced Configuration and Power Interface Table set.

[0192] Verify the checksum field of the direct memory access remapping description table and generate a checksum verification status;

[0193] Verify the length field of the direct memory access remapping description table and generate a length verification status.

[0194] Based on the checksum verification status and the length verification status, generate direct memory access remapping descriptor table status information that includes a direct memory access remapping descriptor table existence flag, checksum status, and length compliance.

[0195] In one embodiment, the description table repair module 20 is specifically used for:

[0196] When the status information of the direct memory access remapping descriptor table indicates an error, the error type field is parsed based on the status information of the direct memory access remapping descriptor table.

[0197] Based on the error type field, locate the corrupted data structure in the direct memory access remapping description table;

[0198] Obtain the set of remediation strategies defined by the advanced configuration and power interface specifications;

[0199] Based on the set of repair strategies, the data content in the damaged data structure is rewritten to generate a rewritten direct memory access remapping description table.

[0200] Based on the rewritten direct memory access remapping description table, determine the checksum field processing value and generate the checksum processing result.

[0201] Based on the checksum processing result, update the rewritten direct memory access remapping description table to generate a checksum-updated direct memory access remapping description table.

[0202] Verify the compliance of the length field in the updated direct memory access remapping description table and generate a length verification status.

[0203] A repair completion verification flag is generated based on the length verification status.

[0204] When the repair completion verification flag indicates that the repair was successful, the updated direct memory access remapping descriptor table is output as the repaired direct memory access remapping descriptor table.

[0205] In one embodiment, the description table repair module 20 is specifically used for:

[0206] Read the repair template index from the bootloader configuration area;

[0207] Based on the repair template index, load the predefined repair template set;

[0208] Based on the predefined set of repair templates, the field rewriting strategy is parsed.

[0209] Based on the field rewrite strategy, compatible repair strategies are selected according to the advanced configuration and power interface specification version number;

[0210] Generate a set of repair strategies that includes filtered repair strategies and version compatibility flags.

[0211] In one embodiment, the table loading module 30 is specifically used for:

[0212] Obtain the length information of the repaired direct memory access remapping descriptor table;

[0213] Allocate contiguous memory space based on the length information;

[0214] Copy the repaired direct memory access remapping descriptor table to the contiguous memory space;

[0215] Set the access attribute of the contiguous memory space to read-only;

[0216] Update the advanced configuration and power interface table pointers to point to the contiguous memory space;

[0217] Generate a load location identifier that includes the start address and length information of the contiguous memory space.

[0218] In one embodiment, the kernel access module 40 is specifically used for:

[0219] The advanced configuration and power interface table scan process is initiated through the operating system kernel.

[0220] Based on the starting address information in the loading location identifier, locate the contiguous memory space;

[0221] The contiguous memory space is mapped to the operating system kernel address space through the memory management unit;

[0222] Read the header structure of the repaired direct memory access remapping descriptor table in the kernel address space;

[0223] Verify that the advanced configuration and power interface signature in the header structure is a direct memory access remapped descriptor identifier;

[0224] Parse the remapping structure of the repaired direct memory access remapping descriptor table to generate the remapping structure parsing result;

[0225] Based on the parsing results of the remapping structure, the repaired direct memory access remapping descriptor table is loaded into the operating system kernel management area.

[0226] In one embodiment, the virtualization enabling module 50 is specifically used for:

[0227] Based on the repaired direct memory access remapping description table, the input / output memory management unit configuration parameters are extracted to generate a configuration parameter set.

[0228] Based on the set of configuration parameters, configure the input / output memory management unit control register and generate the register configuration status;

[0229] Based on the register configuration state, initialize the direct memory access address remapping table and generate an address remapping table object;

[0230] Load the virtualization device driver;

[0231] Enable the CPU hardware virtualization extended instruction set;

[0232] The input / output memory management unit function is activated based on the address remapping table object;

[0233] Generate an input / output virtualization feature enabled status that includes status codes and error flags.

[0234] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements the functions or steps of a boot-loaded descriptor table repair method on the server side.

[0235] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of a boot-loaded descriptor table repair method.

[0236] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps:

[0237] Load the bootloader, and use the bootloader to identify the status of the direct memory access remapping descriptor table and generate direct memory access remapping descriptor table status information;

[0238] When the status information of the direct memory access remapping descriptor table indicates an error, the direct memory access remapping descriptor table is repaired by the bootloader, and a repaired direct memory access remapping descriptor table is generated.

[0239] The bootloader loads the repaired direct memory access remapping descriptor table into the system's accessible area and generates a loading location identifier.

[0240] The operating system accesses the repaired direct memory access remapping descriptor table in the system's accessible area based on the load location identifier.

[0241] The input / output virtualization function is enabled based on the repaired direct memory access remapping descriptor.

[0242] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0243] Load the bootloader, and use the bootloader to identify the status of the direct memory access remapping descriptor table and generate direct memory access remapping descriptor table status information;

[0244] When the status information of the direct memory access remapping descriptor table indicates an error, the direct memory access remapping descriptor table is repaired by the bootloader, and a repaired direct memory access remapping descriptor table is generated.

[0245] The bootloader loads the repaired direct memory access remapping descriptor table into the system's accessible area and generates a loading location identifier.

[0246] The operating system accesses the repaired direct memory access remapping descriptor table in the system's accessible area based on the load location identifier.

[0247] The input / output virtualization function is enabled based on the repaired direct memory access remapping descriptor.

[0248] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0249] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0250] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0251] It should be noted that if any software tools or components not belonging to this company appear in the embodiments of this application, they are merely illustrative examples and do not represent actual use. The embodiments described above are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A descriptor table repair method based on bootloader, characterized in that, Includes the following steps: Load the bootloader, and use the bootloader to identify the status of the direct memory access remapping descriptor table and generate direct memory access remapping descriptor table status information; When the Direct Memory Access Remapping Descriptor Table (DMRD) status information indicates an error, the bootloader repairs the DMRD to generate a repaired DMRD, including: parsing the error type field based on the DMRD status information; locating the corrupted data structure in the DMRD based on the error type field; and obtaining a set of repair strategies defined by the Advanced Configuration and Power Interface (AMI) specification, including: reading the repair template index from the bootloader configuration area; loading a predefined repair template set based on the repair template index; parsing the field rewrite strategy based on the predefined repair template set; and filtering compatible repair strategies based on the AMI version number according to the field rewrite strategy. The process involves several steps: First, generating a set of repair strategies, including filtered repair strategies and version compatibility flags. Second, rewriting the data content in the corrupted data structure based on the repair strategy set to generate a rewritten direct memory access remapping description table (DMI). Third, determining the checksum field processing value based on the rewritten DMI, generating a checksum processing result. Fourth, updating the rewritten DMI based on the checksum processing result to generate a checksum-updated DMI. Fifth, verifying the compliance of the length field in the checksum-updated DMI and generating a length verification status. Sixth, generating a repair completion verification flag based on the length verification status. Seventh, when the repair completion verification flag indicates successful repair, outputting the checksum-updated DMI as the repaired DMI. The bootloader loads the repaired direct memory access remapping descriptor table into the system's accessible area and generates a loading location identifier. The operating system accesses the repaired direct memory access remapping descriptor table in the system's accessible area based on the load location identifier. The input / output virtualization function is enabled based on the repaired direct memory access remapping descriptor.

2. The descriptor table repair method based on bootloader as described in claim 1, characterized in that, The bootloader is loaded, and through the bootloader, the state of the Direct Memory Access Remapping Descriptor Table (DMR) is identified, and DMR state information is generated, including: The hardware environment is initialized through firmware, and a hardware initialization completion signal is generated. Based on the hardware initialization completion signal, the bootloader code is read from the non-volatile storage device; The bootloader code is loaded into the memory execution region, and the memory execution region address is generated; Execute the bootloader code located in the memory execution region address; The advanced configuration and power interface table set is scanned by the bootloader, and the scan results of the advanced configuration and power interface table set are generated. Based on the scanning results of the Advanced Configuration and Power Interface Table set, the Direct Memory Access Remapping Description Table is located in the Advanced Configuration and Power Interface Table set. Verify the checksum field of the direct memory access remapping description table and generate a checksum verification status; Verify the length field of the direct memory access remapping description table and generate a length verification status. Based on the checksum verification status and the length verification status, generate direct memory access remapping descriptor table status information that includes a direct memory access remapping descriptor table existence flag, checksum status, and length compliance.

3. The descriptor table repair method based on bootloader as described in claim 1, characterized in that, The bootloader loads the repaired direct memory access remapping descriptor table into the system's accessible region, generating a load location identifier, including: Obtain the length information of the repaired direct memory access remapping descriptor table; Allocate contiguous memory space based on the length information; Copy the repaired direct memory access remapping descriptor table to the contiguous memory space; Set the access attribute of the contiguous memory space to read-only; Update the advanced configuration and power interface table pointers to point to the contiguous memory space; Generate a load location identifier that includes the start address and length information of the contiguous memory space.

4. The descriptor table repair method based on bootloader as described in claim 1, characterized in that, Accessing the repaired direct memory access remapping descriptor table in the system's accessible region via the operating system based on the load location identifier includes: The advanced configuration and power interface table scan process is initiated through the operating system kernel. Based on the starting address information in the loading location identifier, locate the contiguous memory space; The contiguous memory space is mapped to the operating system kernel address space through the memory management unit; Read the header structure of the repaired direct memory access remapping descriptor table in the kernel address space; Verify that the advanced configuration and power interface signature in the header structure is a direct memory access remapped descriptor identifier; Parse the remapping structure of the repaired direct memory access remapping descriptor table to generate the remapping structure parsing result; Based on the parsing results of the remapping structure, the repaired direct memory access remapping descriptor table is loaded into the operating system kernel management area.

5. The descriptor table repair method based on bootloader as described in claim 1, characterized in that, Enabling input / output virtualization based on the repaired direct memory access remapping descriptor table includes: Based on the repaired direct memory access remapping description table, the input / output memory management unit configuration parameters are extracted to generate a configuration parameter set. Based on the set of configuration parameters, configure the input / output memory management unit control register and generate the register configuration status; Based on the register configuration state, initialize the direct memory access address remapping table and generate an address remapping table object; Load the virtualization device driver; Enable the CPU hardware virtualization extended instruction set; The input / output memory management unit function is activated based on the address remapping table object; Generate an input / output virtualization feature enabled status that includes status codes and error flags.

6. A descriptor table repair device based on bootloader, characterized in that, The bootloader-based descriptor table repair device includes: The boot recognition module is used to load the bootloader, identify the status of the direct memory access remapping descriptor table through the bootloader, and generate direct memory access remapping descriptor table status information. The description table repair module is used to repair the Direct Memory Access Remapping Descriptor Table (DMRD) through the bootloader when the DMRD status information indicates an error, generating a repaired DMRD. The module includes: when the DMRD status information indicates an error, parsing an error type field based on the DMRD status information; locating corrupted data structures in the DMRD based on the error type field; and obtaining a set of repair strategies defined by the Advanced Configuration and Power Interface (AMI) specification, including: reading a repair template index from the bootloader configuration area; loading a predefined repair template set based on the repair template index; parsing a field rewrite strategy based on the predefined repair template set; and filtering for compatibility issues based on the AMI version number according to the field rewrite strategy. The system employs a repair strategy that generates a set of repair strategies, including filtered repair strategies and version compatibility flags. Based on this set of repair strategies, it rewrites the data content in the corrupted data structure, generating a rewritten direct memory access remapping description table (DMI). Based on the rewritten DMI, it determines the checksum field processing value and generates a checksum processing result. Based on the checksum processing result, it updates the rewritten DMI, generating a checksum-updated DMI. It verifies the compliance of the length field in the updated DMI, generating a length verification status. Based on the length verification status, it generates a repair completion verification flag. When the repair completion verification flag indicates successful repair, it outputs the updated DMI as the repaired DMI. The table loading module is used to load the repaired direct memory access remapping description table into the system's accessible area through the bootloader and generate a loading location identifier. The kernel access module is used to access the repaired direct memory access remapping descriptor table in the system's accessible area based on the load location identifier by the operating system; The virtualization enabling module is used to enable input / output virtualization functionality based on the repaired direct memory access remapping descriptor table.

7. A computer device, characterized in that, The computer device includes a memory, a processor, and a boot-loaded descriptor table repair program stored in the memory and executable on the processor, wherein the boot-loaded descriptor table repair program, when executed by the processor, implements the steps of the boot-loaded descriptor table repair method as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The storage medium stores a boot-loaded descriptor table repair program, which, when executed by a processor, implements the steps of the boot-loaded descriptor table repair method as described in any one of claims 1-5.

Images