A method and apparatus for installing server graphics card drivers

Abstract

This invention provides a method and apparatus for installing server graphics card drivers, comprising: in an out-of-band management environment, acquiring the platform architecture information of the target server and the device identifiers of at least two heterogeneous graphics cards mounted thereon; matching the corresponding adapter driver packages for each heterogeneous graphics card from a preset driver policy library based on the platform architecture information and device identifiers; creating a temporary virtual display channel based on the platform architecture information before the target operating system kernel is loaded; injecting the adapter driver packages into the kernel module of the target operating system in parallel through the virtual display channel; and driving each heterogeneous graphics card to output display based on the injected adapter driver packages after the target operating system starts. This invention enables the synchronous installation and efficient deployment of multiple graphics card drivers, significantly improving the efficiency and success rate of computing architecture migration.

Description

Technical Field

[0001] This application relates to the field of server technology, and more specifically, to a method and apparatus for installing server graphics card drivers. Background Technology

[0002] With the continuous expansion of data center scale and the diversification of computing architectures, servers face frequent hardware upgrades and architecture migration needs. Especially during the process of domestic substitution, servers need to migrate from traditional x86 architectures to domestically developed and controllable architectures such as ARM, LoongArch, and SW64. In such computing architecture migrations, target servers often feature various heterogeneous graphics cards, including graphics cards compatible with the original source architecture and graphics cards adapted to the new target architecture.

[0003] Existing methods for installing graphics card drivers typically rely on the operating system's plug-and-play mechanism or interactive installation with manual intervention. However, in architecture migration scenarios, these methods have significant drawbacks: First, drivers for heterogeneous graphics cards need deep compatibility with the specific architecture's operating system kernel, making accurate matching difficult with simple plug-and-play mechanisms; second, servers during migration are usually in a silent state without display output, unable to provide the human-computer interface required for interactive installation; finally, the lack of effective management of the installation order and resource allocation for multiple graphics card drivers in parallel can easily lead to driver conflicts or display anomalies, affecting migration efficiency and success rate. Summary of the Invention

[0004] The present invention aims to overcome the shortcomings of the prior art and provide a method and apparatus for installing server graphics card drivers, so as to solve the problems of difficult installation, poor compatibility and lack of effective management of graphics card drivers during the migration of server computing architecture.

[0005] In a first aspect, the present invention provides a method for installing a server graphics card driver, applied to a target server during a computing architecture migration process, the method comprising: In an out-of-band management environment, obtain the platform architecture information of the target server and the device identifiers of at least two heterogeneous graphics cards it is equipped with; Based on the platform architecture information and the device identifier, the corresponding driver packages for each heterogeneous graphics card are matched from the preset driver policy library. Before the target operating system kernel is loaded, a temporary virtual display channel is created based on the platform architecture information; The adapter driver package is injected into the kernel module of the target operating system in parallel through the virtual display channel. After the target operating system starts, the heterogeneous graphics cards are driven to output and display based on the injected adaptation driver package.

[0006] Preferably, obtaining the platform architecture information of the target server and the device identifiers of the at least two heterogeneous graphics cards it carries includes: Access the target server's device management bus via the baseboard management controller to read the processor type, chipset model, and vendor ID and device ID of each graphics card; The source computing architecture of the target server is determined based on the processor type and the chipset model, and the instruction set architecture of each graphics card is determined based on the vendor ID and the device ID of each graphics card. The source computing architecture is compared with the instruction set architecture of each graphics card to identify a hybrid graphics card configuration that includes both the source architecture graphics card and the target architecture graphics card. Then, the platform architecture information and the device identifier are determined based on the hybrid graphics card configuration.

[0007] Preferably, the step of matching the corresponding adapter driver package from the preset driver policy library to each of the heterogeneous graphics cards includes: The kernel version and system bitness of the operating system to be installed are determined based on the platform architecture information. The hardware interface type and memory specifications of each graphics card are determined based on the device identifier. Based on the kernel version, system bitness, hardware interface type, and video memory specifications, driver files that simultaneously meet both physical and logical compatibility requirements are selected from the driver policy library and used as the adaptation driver package.

[0008] Preferably, the step of creating a temporary virtual display channel based on the platform architecture information before the target operating system kernel is loaded includes: Based on the platform architecture information, determine whether the target server supports the graphical output protocol of the unified extensible firmware interface; If it is determined that the graphics output protocol is supported, the basic services of the graphics output protocol are called during the pre-boot execution environment phase to simulate a virtual frame buffer device independent of the physical graphics card. Configure the corresponding data transmission interface according to the input / output characteristics of the virtual frame buffer device, and use the data transmission interface as the temporary virtual display channel.

[0009] Preferably, the step of injecting the adaptation driver package into the kernel module of the target operating system in parallel through the virtual display channel includes: According to the kernel module loading specification of the target operating system, the adapter driver package is encapsulated into a data stream that conforms to the kernel module format; The encapsulated data stream is directly written into the dynamic area reserved for kernel module loading in memory through the virtual display channel; After the write is complete, the kernel's device driver symbol table is updated so that the kernel can recognize and load the adapter driver package at startup.

[0010] Preferably, it further includes: During the driver injection process through the virtual display channel, the power consumption and temperature parameters of the target server are collected in real time through the out-of-band management environment. Calculate the current hardware load margin based on the power consumption parameters and the temperature parameters; If the load margin is lower than the preset safety threshold, it is determined that there is an abnormal risk in the current environment, the driver injection for the current graphics card is suspended, and the backup basic display driver preset in the firmware is called to take over the display function.

[0011] Preferably, after the target operating system starts and the heterogeneous graphics cards are driven to output display based on the injected adaptation driver package, the method further includes: The actual display output signal of the target operating system is captured through the out-of-band management environment; The actual display output signal is compared with the preset expected display topology to calculate the topology matching degree; If the topology matching degree is lower than the preset matching threshold, the display output priority is redistributed according to the physical slot order of each heterogeneous graphics card until the topology matching degree reaches the matching threshold.

[0012] In a second aspect, the present invention provides a server graphics card driver installation device, comprising: The information acquisition module is used to acquire, in an out-of-band management environment, the platform architecture information of the target server and the device identifiers of at least two heterogeneous graphics cards it is equipped with; The driver package matching module is used to match the corresponding driver packages for each heterogeneous graphics card from a preset driver policy library based on the platform architecture information and the device identifier. The virtual display channel creation module is used to create a temporary virtual display channel based on the platform architecture information before the target operating system kernel is loaded. The driver package injection module is used to inject the driver package into the kernel module of the target operating system in parallel through the virtual display channel. The driver module is used to drive the heterogeneous graphics cards to output and display based on the injected adaptation driver package after the target operating system starts.

[0013] Thirdly, the present invention provides a readable medium including executable instructions, which, when executed by a processor of an electronic device, cause the electronic device to perform any of the methods described in the first aspect.

[0014] Fourthly, the present invention provides an electronic device including a processor and a memory storing execution instructions, wherein when the processor executes the execution instructions stored in the memory, the processor performs the method as described in any of the first aspects.

[0015] This invention provides a method and apparatus for installing server graphics card drivers. First, by acquiring platform architecture information and heterogeneous graphics card device identifiers through an out-of-band management environment before the operating system kernel loads, it accurately identifies hybrid graphics card configurations during computing architecture migration, providing a precise basis for subsequent driver matching. Second, based on the platform architecture information and device identifiers, it matches compatible driver packages from the driver policy library, ensuring that each heterogeneous graphics card obtains a driver compatible with its hardware characteristics and the operating system kernel, avoiding system instability or display abnormalities caused by driver incompatibility. Third, by creating a temporary virtual display channel before the operating system kernel loads, it solves the problem of not being able to perform driver installation interaction in an environment without display output, providing a reliable data transmission path for parallel driver injection. Finally, by injecting the compatible driver packages into the kernel module in parallel through the virtual display channel, it achieves synchronous installation and efficient deployment of multiple graphics card drivers, significantly improving the efficiency and success rate of computing architecture migration.

[0016] The further effects of the aforementioned non-conventional preferred method will be explained below in conjunction with specific embodiments. Attached Figure Description

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

[0018] Figure 1 This is a schematic diagram illustrating a server graphics card driver installation method according to an embodiment of the present invention; Figure 2 This is a schematic diagram illustrating another server graphics card driver installation method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the components of a server graphics card driver installation device according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0020] See Figure 1 The image shows a specific embodiment of a server graphics card driver installation method provided by the present invention. In this embodiment, the server graphics card driver installation method includes:

[0021] Step 101: In the out-of-band management environment, obtain the platform architecture information of the target server and the device identifiers of at least two heterogeneous graphics cards it is equipped with; Specifically, this embodiment applies to the target server during the computing architecture migration process. The out-of-band management environment refers to a dedicated management subsystem that runs independently of the server's main operating system and main processor, typically including a baseboard management controller. This management environment has independent hardware channels and network connections, enabling low-level access and control of the server even when the server's main processor is not running or the operating system is not loaded. The computing architecture migration process refers to the overall conversion of the server from the source computing architecture to the target computing architecture, such as migrating from x86 architecture to ARM, LoongArch, or SW64 architecture. During this migration, the target server may simultaneously retain graphics cards compatible with the source architecture and add graphics cards adapted to the target architecture, forming a hardware configuration with at least two heterogeneous graphics cards coexisting. Platform architecture information includes the specific model and core architecture type of the processor, the model and manufacturer of the chipset, the type and version of the firmware, and the topology of the system bus. Device identification refers to the characteristic information that can uniquely identify the graphics card hardware, including vendor ID, device ID, subsystem ID, and revision number.

[0022] In this step, the specific implementation of obtaining platform architecture information and device identifiers is as follows: First, the device management bus of the target server is accessed through the baseboard management controller. This device management bus includes PCIe configuration space, I2C bus, or SMBus, from which the processor type, chipset model, and vendor ID and device ID of each graphics card are read. Second, the source computing architecture of the target server is determined based on the read processor type and chipset model. For example, if the processor type is Intel Xeon series, the source computing architecture can be determined to be x86 architecture; if the processor type is Phytium FT series, the source computing architecture can be determined to be ARM architecture. Simultaneously, a preset hardware feature database is queried based on the vendor ID and device ID of each graphics card to determine the instruction set architecture adapted to each graphics card. This instruction set architecture includes x86 instruction set, ARM instruction set, LoongArch instruction set, or MIPS instruction set. Finally, the determined source computing architecture is compared and analyzed with the instruction set architecture of each graphics card to identify hybrid graphics card configurations in the current server that simultaneously contain graphics cards compatible with the source architecture (i.e., migrated source architecture graphics cards) and graphics cards adapted to the target architecture (i.e., migrated target architecture graphics cards). Based on the identified hybrid graphics card configurations, the complete platform architecture information and the device identifier set of all heterogeneous graphics cards are finally determined, providing a precise basis for subsequent driver matching.

[0023] Step 102: Based on the platform architecture information and device identifier, match the corresponding driver package for each heterogeneous graphics card from the preset driver policy library; Furthermore, the driver policy library is a pre-built and continuously maintained driver database that stores driver files optimized for different computing architectures, operating system versions, and graphics card models, along with their associated attribute information. Adaptive driver packages refer to drivers that have been selected and determined to be fully compatible with specific hardware configurations and software environments.

[0024] In this step, the specific implementation of matching the driver package is as follows: First, based on the platform architecture information obtained in step 101, determine the kernel version and system bitness of the operating system to be installed. The kernel version is, for example, Linux kernel version 5.4 or 5.10, and the system bitness is, for example, 32-bit or 64-bit. Second, based on the device identifier obtained in step 101, determine the hardware interface type and memory specifications of each graphics card. The hardware interface type includes PCIe Gen3, PCIe Gen4, PCIe Gen5, or AGP interface, and the memory specifications include memory capacity, memory type (e.g., GDDR6 or HBM2), and memory bus width. Finally, based on the kernel version, system bitness, hardware interface type, and memory specifications, filter driver files from the driver policy library. The filtering process uses a multi-dimensional matching algorithm, comparing the current configuration information with the attribute tags of each driver file in the driver policy library item by item, selecting driver files that simultaneously meet the physical compatibility requirements (i.e., hardware interface type and memory specifications match) and logical compatibility requirements (i.e., kernel version and system bitness match), as the corresponding driver packages for each heterogeneous graphics card.

[0025] Step 103: Before the target operating system kernel is loaded, create a temporary virtual display channel based on the platform architecture information; Furthermore, "before the target operating system kernel loads" refers to the stage during server startup from the completion of firmware initialization to the point where the operating system kernel begins to take over hardware control, including the unified extensible firmware interface stage or the pre-boot execution environment stage. The virtual display channel is a logical communication path independent of the physical graphics card, used to provide basic data transmission and display output capabilities when the physical graphics card driver is not yet ready.

[0026] In this step, the specific implementation of creating a virtual display channel is as follows: First, based on the firmware type and version obtained in step 101 from the platform architecture information, it is determined whether the target server supports the Unified Extensible Firmware Interface (UEFI) graphics output protocol. The graphics output protocol is a standardized interface defined in the UEFI specification for performing graphics operations in the firmware environment. Second, if the determination result is yes, the basic services provided by the graphics output protocol are called during the pre-boot execution environment phase to simulate and create a virtual frame buffer device in memory that is independent of any physical graphics card. This device allocates a dedicated area in memory as a display buffer and provides basic pixel drawing and text output functions. Finally, based on the input and output characteristics of the created virtual frame buffer device, including the buffer start address, buffer size, pixel format, and resolution parameters, the corresponding data transmission interface is configured. This data transmission interface is used as a temporary virtual display channel for driver injection operations in subsequent steps.

[0027] Step 104: Inject the adapter driver package into the kernel module of the target operating system in parallel through the virtual display channel; Specifically, parallel injection refers to simultaneously performing injection operations on the driver packages of multiple heterogeneous graphics cards, or using a multi-threaded approach to quickly deploy all driver packages. A kernel module is a driver unit in an operating system that can be dynamically loaded and unloaded, typically with a specific format and loading specification. In this step, the specific implementation of parallel injection via a virtual display channel is as follows: First, according to the kernel module loading specification of the target operating system, each driver package determined in step 102 is encapsulated into a data stream conforming to the kernel module format. The kernel module loading specification defines the module's file format, header information structure, symbol table requirements, and naming and calling conventions for initialization functions. Second, through the virtual display channel created in step 103, each encapsulated data stream is directly written into the dynamic area reserved for kernel module loading in memory. The dynamic area is a memory address space predefined in the operating system specification for storing the kernel modules to be loaded; this area remains accessible until the operating system kernel completes initialization. Finally, after all data streams have been written, the kernel's device driver symbol table is updated, adding the name, memory entry address, dependencies, and version information of each adapter driver package to the table. This enables the kernel to recognize these pre-built driver packages during subsequent startup and complete the driver initialization and registration according to the standard process.

[0028] Step 105: After the target operating system starts, drive the output display of each heterogeneous graphics card based on the injected adapter package.

[0029] Furthermore, "after the target operating system boots up" refers to the stage where the operating system kernel completes initialization, device enumeration, and module loading, entering normal operation. At this point, because the adapter driver package has been pre-injected into the kernel module and registered through the device driver symbol table, the operating system can automatically discover and load the corresponding driver when enumerating graphics card devices.

[0030] This step, after driving the output display of each heterogeneous graphics card, also includes a verification and optimization process for the display output effect. Specifically, it is implemented as follows: First, the actual display output signal of the target operating system is captured using the out-of-band management environment's video capture function. This actual display output signal includes the current output resolution, refresh rate, color depth, and the arrangement of multiple monitors. Second, the captured actual display output signal is compared with a preset expected display topology to calculate the topology matching degree. The expected display topology is a display output layout pre-configured according to server management requirements, such as specifying a graphics card in a specific physical location as the primary display output, setting an extended display mode, or a mirrored display mode. The topology matching degree is calculated using a quantization algorithm to determine the similarity between the actual output and the expected output in various parameters. Finally, if the calculated topology matching degree is lower than a preset matching threshold, the display output priority is reassigned according to the physical slot order of each heterogeneous graphics card on the motherboard. The physical slot order can be, for example, the PCIe slot number order or the CPU affinity order. By adjusting the graphics card enumeration order or modifying the display output configuration parameters, the comparison and adjustment operations are repeatedly performed until the topology matching degree reaches the matching threshold, ensuring that the final display output meets management expectations.

[0031] As can be seen from the above technical solutions, the beneficial effects of this embodiment are: by completing the accurate matching and parallel pre-injection of heterogeneous graphics card drivers before the operating system kernel is loaded through the out-of-band management environment, the problem of poor multi-graphics card compatibility and inability to perform interactive installation during the migration of computing architecture is solved, and the automation level of driver deployment and migration success rate are significantly improved.

[0032] Figure 1 The embodiments shown are merely basic examples of the method of the present invention. Other preferred embodiments of the method can be obtained by making certain optimizations and extensions based on them.

[0033] like Figure 2 The image shows another specific embodiment of a server graphics card driver installation method according to the present invention. This embodiment further describes the method based on the foregoing embodiments, and includes the following steps:

[0034] Step 201: During the driver injection process through the virtual display channel, the power consumption and temperature parameters of the target server are collected in real time through the out-of-band management environment; Specifically, the process of driver injection via the virtual display channel refers to the operation phase described in step 104 of the above embodiment, which involves writing the adapter driver package into the memory kernel module area. This phase involves continuous data transmission and frequent memory access, causing the server hardware to be in an active working state. The out-of-band management environment refers to an independent management channel built on the baseboard management controller. This controller has independent processors, memory, and network interfaces, and does not depend on the operation of the server's main processor and main operating system. It can continue to work when the main system is in the pre-boot phase or an abnormal state. Power consumption parameters are quantitative indicators reflecting the power consumption of various hardware components of the server, including but not limited to the real-time power consumption of the central processing unit, the power consumption of the memory module, the power consumption of the graphics card, and the output power of the power supply unit. These parameters can be obtained by the baseboard management controller accessing the power management bus and power sensors. Temperature parameters are quantitative indicators reflecting the thermal state of various key components inside the server, including the core temperature of the central processing unit, the temperature of the chipset, the temperature of the graphics processing unit, the temperature of the power supply unit, and the ambient temperature inside the chassis. These parameters can be obtained by the baseboard management controller reading temperature sensors located throughout the motherboard. The baseboard management controller continuously collects the real-time values ​​of the aforementioned power consumption and temperature parameters at a preset sampling frequency, such as once per second or ten times per second, and stores the collected data in the local cache of the management controller for subsequent analysis and processing.

[0035] Step 202: Calculate the current hardware load margin based on power consumption and temperature parameters; Furthermore, load margin refers to the remaining capacity of server hardware in its current operating state from its design limits or safety boundaries. It is used to assess whether the hardware has the ability to continue to withstand additional workloads. Calculating load margin requires considering both power consumption and temperature. In terms of power consumption, real-time power consumption parameters are compared with the maximum allowable power consumption thresholds of hardware components, such as the thermal design power limit of the CPU or the rated output power of the power supply unit, to calculate the power consumption margin ratio. The specific formula is: Power Consumption Margin = (Maximum Allowable Power Consumption - Current Real-Time Power Consumption) / Maximum Allowable Power Consumption × 100%. In terms of temperature, real-time temperature parameters are compared with the highest operating temperature thresholds of hardware components, such as the junction temperature limit of the CPU or the overheat protection temperature of the graphics card, to calculate the temperature margin ratio. The specific formula is: Temperature Margin = (Highest Operating Temperature - Current Real-Time Temperature) / (Highest Operating Temperature - Normal Operating Temperature) × 100%. Finally, the overall load margin of the current hardware is determined by combining the power consumption margin and the temperature margin. This is typically done by taking the minimum of the two or a weighted average to reflect the most constrained safety boundary. If a hardware component has multiple sampling points, such as a multi-core processor, the highest temperature is used in the calculation to ensure that the evaluation results cover the worst-case scenario.

[0036] Step 203: If the load margin is lower than the preset safety threshold, it is determined that there is an abnormal risk in the current environment, the driver injection for the current graphics card is suspended, and the backup basic display driver preset in the firmware is called to take over the display function.

[0037] Specifically, the preset safety threshold is a warning line pre-set based on the server's hardware specifications, thermal design, and reliability requirements, usually expressed as a percentage, such as 20% or 30%. When the calculated load margin is lower than this safety threshold, it indicates that the hardware is approaching its operating limit, and continuing to perform driver injection operations may lead to system overheating, power overload, hardware throttling, or even unexpected crashes. At this time, the system determines that there is an abnormal risk in the current environment and needs to take protective measures immediately. Suspending driver injection for the current graphics card means immediately stopping the memory write operation in step 104, stopping the transfer of data to the kernel module area, and releasing the occupied virtual display channel resources to avoid further increasing the hardware load. The backup basic display driver refers to a simplified version of the display driver pre-stored in the firmware non-volatile memory, such as a general frame buffer driver that conforms to the VGA compatibility standard or a basic driver that conforms to the UEFI graphics output protocol. This driver does not depend on the advanced features of specific graphics card hardware and can provide basic text output and simple graphics display capabilities on most graphics cards. By invoking the backup driver to take over the display function, the server can maintain basic display output capabilities even if the driver injection process is abnormally interrupted. This allows administrators to view the server status and troubleshoot via the out-of-band management console. Once the hardware load returns to normal, i.e., the temperature decreases or power consumption falls back to a safe range, the system can choose to resume the previously paused driver injection process or wait for manual intervention.

[0038] As can be seen from the above technical solutions, the beneficial effects of this embodiment are: by introducing a real-time monitoring and dynamic protection mechanism based on power consumption and temperature, while ensuring driver installation efficiency, it effectively avoids system crashes or hardware damage caused by hardware overload, and significantly improves the operational stability and reliability of the server during the architecture migration process.

[0039] This invention also provides a server graphics card driver installation device. See [link to related document]. Figure 3 The image shows a specific embodiment of a server graphics card driver installation device provided by the present invention. This embodiment of the device is used to execute... Figures 1-2 The physical apparatus of the method. Its technical solution is essentially the same as the above embodiments, and the corresponding descriptions in the above embodiments also apply to this embodiment. The apparatus includes:

[0040] The information acquisition module 301 is configured to acquire, in an out-of-band management environment, the platform architecture information of the target server and the device identifiers of at least two heterogeneous graphics cards it is equipped with; The driver package matching module 302 is configured to match the corresponding driver package for each heterogeneous graphics card from the preset driver policy library based on the platform architecture information and device identifier. The virtual display channel creation module 303 is configured to create a temporary virtual display channel based on platform architecture information before the target operating system kernel is loaded; The adapter driver injection module 304 is configured to inject the adapter driver package into the kernel module of the target operating system in parallel through the virtual display channel; Driver module 305 is configured to drive the output display of various heterogeneous graphics cards based on the injected adapter driver package after the target operating system starts.

[0041] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include main memory, such as high-speed random-access memory (RAM), or it may also include non-volatile memory, such as at least one disk storage device. Of course, the electronic device may also include other hardware required for other services.

[0042] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. Buses can be categorized as address buses, data buses, and other types. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0043] Memory is used to store instructions for execution. Specifically, instructions for execution are computer programs that can be executed. Memory can include main memory and non-volatile memory, and it provides the processor with execution instructions and data.

[0044] In one possible implementation, the processor reads the corresponding execution instructions from non-volatile memory into main memory and then executes them. Alternatively, it may obtain the corresponding execution instructions from other devices to form a server graphics card driver installation device at the logical level. The processor executes the execution instructions stored in the memory to implement a server graphics card driver installation method provided in any embodiment of the present invention.

[0045] The above is as described in the present invention. Figure 3 The method for installing a server graphics card driver provided in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor.

[0046] The steps of the method disclosed in the embodiments of this invention can be directly manifested as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0047] This invention also proposes a readable medium storing executable instructions. When these instructions are executed by a processor of an electronic device, the electronic device can perform a server graphics card driver installation method provided in any embodiment of this invention, specifically for executing, as described in the following embodiments: Figure 1 , Figure 2 The method shown.

[0048] The electronic devices in the foregoing embodiments may be computers.

[0049] Those skilled in the art will understand that embodiments of the present invention can be provided as methods or computer program products. Therefore, the present invention can be implemented in a completely hardware embodiment, a completely software embodiment, or a combination of software and hardware.

[0050] The various embodiments in this invention are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0051] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0052] The above are merely embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.

Claims

1. A method for installing a server graphics card driver, applied to a target server during a computing architecture migration process, characterized in that, The method includes: In an out-of-band management environment, obtain the platform architecture information of the target server and the device identifiers of at least two heterogeneous graphics cards it is equipped with; Based on the platform architecture information and the device identifier, the corresponding driver packages for each heterogeneous graphics card are matched from the preset driver policy library. Before the target operating system kernel is loaded, a temporary virtual display channel is created based on the platform architecture information; The adapter driver package is injected into the kernel module of the target operating system in parallel through the virtual display channel. After the target operating system starts, the heterogeneous graphics cards are driven to output and display based on the injected adaptation driver package.

2. The method according to claim 1, characterized in that, The process of obtaining the platform architecture information of the target server and the device identifiers of the at least two heterogeneous graphics cards it is equipped with includes: Access the target server's device management bus via the baseboard management controller to read the processor type, chipset model, and vendor ID and device ID of each graphics card; The source computing architecture of the target server is determined based on the processor type and the chipset model, and the instruction set architecture of each graphics card is determined based on the vendor ID and the device ID of each graphics card. The source computing architecture is compared with the instruction set architecture of each graphics card to identify a hybrid graphics card configuration that includes both the source architecture graphics card and the target architecture graphics card. Then, the platform architecture information and the device identifier are determined based on the hybrid graphics card configuration.

3. The method according to claim 1, characterized in that, The step of matching the corresponding adapter driver package from the preset driver policy library with each of the heterogeneous graphics cards includes: The kernel version and system bitness of the operating system to be installed are determined based on the platform architecture information. The hardware interface type and memory specifications of each graphics card are determined based on the device identifier. Based on the kernel version, system bitness, hardware interface type, and video memory specifications, driver files that simultaneously meet both physical and logical compatibility requirements are selected from the driver policy library and used as the adaptation driver package.

4. The method according to claim 1, characterized in that, The step of creating a temporary virtual display channel based on the platform architecture information before the target operating system kernel is loaded includes: Based on the platform architecture information, determine whether the target server supports the graphical output protocol of the unified extensible firmware interface; If support is found, the basic services of the graphics output protocol are invoked during the pre-boot execution environment phase to simulate a virtual frame buffer device independent of the physical graphics card. Configure the corresponding data transmission interface according to the input / output characteristics of the virtual frame buffer device, and use the data transmission interface as the temporary virtual display channel.

5. The method according to claim 1, characterized in that, The step of injecting the adaptation driver package into the kernel module of the target operating system in parallel through the virtual display channel includes: According to the kernel module loading specification of the target operating system, the adapter driver package is encapsulated into a data stream that conforms to the kernel module format; The encapsulated data stream is directly written into the dynamic area reserved for kernel module loading in memory through the virtual display channel; After the write is complete, the kernel's device driver symbol table is updated so that the kernel can recognize and load the adapter driver package at startup.

6. The method according to claim 1, characterized in that, Also includes: During the driver injection process through the virtual display channel, the power consumption and temperature parameters of the target server are collected in real time through the out-of-band management environment. Calculate the current hardware load margin based on the power consumption parameters and the temperature parameters; If the load margin is lower than the preset safety threshold, it is determined that there is an abnormal risk in the current environment, the driver injection for the current graphics card is suspended, and the backup basic display driver preset in the firmware is called to take over the display function.

7. The method according to claim 1, characterized in that, After the target operating system starts up, and after driving each heterogeneous graphics card to output display based on the injected adaptation driver package, the process further includes: The actual display output signal of the target operating system is captured through the out-of-band management environment; The actual display output signal is compared with the preset expected display topology to calculate the topology matching degree; If the topology matching degree is lower than the preset matching threshold, the display output priority is redistributed according to the physical slot order of each heterogeneous graphics card until the topology matching degree reaches the matching threshold.

8. A server graphics card driver installation device, characterized in that, include: The information acquisition module is used to acquire, in an out-of-band management environment, the platform architecture information of the target server and the device identifiers of at least two heterogeneous graphics cards it is equipped with; The driver package matching module is used to match the corresponding driver packages for each heterogeneous graphics card from a preset driver policy library based on the platform architecture information and the device identifier. The virtual display channel creation module is used to create a temporary virtual display channel based on the platform architecture information before the target operating system kernel is loaded. The driver package injection module is used to inject the driver package into the kernel module of the target operating system in parallel through the virtual display channel. The driver module is used to drive the heterogeneous graphics cards to output and display based on the injected adaptation driver package after the target operating system starts.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the method of any one of claims 1 to 7.

10. An electronic device, characterized in that, The electronic device includes: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement the method described in any one of claims 1 to 7.

Images