Firmware loading methods, servers, virtual machines, devices, chips, and storage media

Abstract

This application provides a firmware loading method, a server, a virtual machine, a device, a chip, and a storage medium. The method includes: obtaining configuration information of a first driver of the virtual machine when the virtual machine starts; determining the version information of a first firmware based on the configuration information of the first driver; traversing at least two running graphics processing units (GPUs), and determining, based on the firmware information of the at least two GPUs and the version information of the first firmware, loading the first firmware on a target GPU among the at least two GPUs. This improves both the flexibility of resource allocation and the utilization rate of resources.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a firmware loading method, server, virtual machine, device, chip, and storage medium. Background Technology

[0002] As a high-speed serial computer expansion bus standard (Peripheral Component Interconnect Express, PCIe) device, the model of a GPU can usually be identified by its vendor ID and device ID.

[0003] In related technologies, when multiple GPUs of the same model exist on the same server, since these GPUs have the same Vendor ID and Device ID, the version information of the loaded firmware is also the same. This results in the version information of the guest driver that matches the firmware being the same, which greatly limits the flexibility of resource allocation and reduces resource utilization. Summary of the Invention

[0004] This application provides a firmware loading method, server, virtual machine, device, chip, and storage medium, which can improve the flexibility of resource allocation and the utilization rate of resources.

[0005] The technical solution of this application is implemented as follows:

[0006] Firstly, embodiments of this application provide a firmware loading method applied to a server. The method includes:

[0007] When the virtual machine starts, obtain the configuration information of the virtual machine's first driver;

[0008] Based on the configuration information of the first driver, determine the version information of the first firmware;

[0009] Iterate through at least two running graphics processing units (GPUs), and based on the firmware information of the at least two GPUs and the version information of the first firmware, determine the target GPU among the at least two GPUs to load the first firmware.

[0010] Secondly, embodiments of this application provide a firmware loading method applied to a virtual machine. The method includes:

[0011] When the virtual machine starts, it sends the configuration information of the first driver to the server;

[0012] Obtain first indication information from the server, which indicates that the first firmware has been successfully loaded on the target GPU in at least two graphics processing units (GPUs) running on the server; wherein, the version information of the first firmware is associated with the configuration information of the first driver.

[0013] Thirdly, embodiments of this application provide a server, which includes a first acquisition unit and a first determination unit, wherein:

[0014] The first acquisition unit is used to acquire the configuration information of the first driver of the virtual machine when the virtual machine starts.

[0015] The first determining unit is used to determine the version information of the first firmware based on the configuration information of the first driver;

[0016] The first determining unit is further configured to traverse at least two running graphics processing units (GPUs) and, based on the firmware information of the at least two GPUs and the version information of the first firmware, determine to load the first firmware on the target GPU among the at least two GPUs.

[0017] Fourthly, embodiments of this application provide a virtual machine, which includes a second sending unit and a second acquiring unit, wherein:

[0018] The second sending unit is used to send the configuration information of the first driver to the server when the virtual machine starts.

[0019] The second acquisition unit is used to acquire first indication information from the server, which indicates that the first firmware has been successfully loaded on the target GPU of at least two graphics processing units (GPUs) running on the server; wherein the version information of the first firmware is associated with the configuration information of the first driver.

[0020] Fifthly, embodiments of this application provide an electronic device, including a processor and a memory. The memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory to execute the firmware loading method described in the first or second aspect above.

[0021] Sixthly, embodiments of this application provide a chip for implementing the firmware loading method described in the first or second aspect above.

[0022] Specifically, the chip includes a processor for calling and running a computer program from a memory, causing a device equipped with the chip to perform the firmware loading method described in the first or second aspect above.

[0023] In a seventh aspect, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by at least one processor, implements the firmware loading method described in the first or second aspect above.

[0024] Eighthly, embodiments of this application provide a computer program product, including computer program instructions that cause a computer to execute the firmware loading method described in the first or second aspect above.

[0025] Ninthly, embodiments of this application provide a computer program that, when run on a computer, causes the computer to execute the firmware loading method described in the first or second aspect above.

[0026] This application provides a firmware loading method, a server, a virtual machine, a device, a chip, and a storage medium. First, when the virtual machine starts, the server can obtain the configuration information of the virtual machine's first driver. Then, the server can determine the version information of the first firmware based on the configuration information of the first driver. Finally, the server can traverse at least two running GPUs and, based on the firmware information of at least two GPUs and the version information of the first firmware, determine which target GPU to load the first firmware on. In this way, the server can flexibly select the version information of the first firmware based on the configuration information of the first driver and load the first firmware on the target GPU. Thus, for multiple GPUs on the same server, when the configuration information of the first driver is different, the selected firmware version information will also be different, thereby enabling the loading of firmware with different versions on multiple GPUs. This allows the multiple GPUs to run first drivers with different configuration information, thereby improving both the flexibility of resource allocation and the utilization rate of resources.

[0027] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0028] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application. Obviously, the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0029] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0030] Figure 1 A flowchart illustrating an optional firmware loading method provided in this application embodiment. Figure 1 ;

[0031] Figure 2 A flowchart illustrating an optional firmware loading method provided in this application embodiment. Figure 2 ;

[0032] Figure 3 A detailed flowchart illustrating an optional firmware loading method provided in this application embodiment;

[0033] Figure 4 A schematic diagram of the composition structure of an optional server provided in an embodiment of this application;

[0034] Figure 5 A schematic diagram of the composition structure of an optional virtual machine provided in an embodiment of this application;

[0035] Figure 6 A schematic structural diagram of an electronic device provided in an embodiment of this application;

[0036] Figure 7 A schematic structural diagram of a chip provided in an embodiment of this application;

[0037] Figure 8 This is a schematic block diagram of a communication system provided in an embodiment of this application. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the specific technical solutions of this application will be further described in detail below with reference to the accompanying drawings of the embodiments of this application. The following embodiments are used to illustrate this application, but are not intended to limit the scope of this application.

[0039] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0040] In the following description, references to "some embodiments," "this embodiment," "this application embodiment," and examples, etc., describe a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same subset or different subset of all possible embodiments and may be combined with each other without conflict.

[0041] If the application documents contain similar descriptions such as "first / second", the following explanation shall be added: In the following description, the terms "first / second / third" are used only to distinguish similar objects and do not represent a specific order of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0042] In the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three kinds of relationships. For example, object A and / or object B can represent three situations: object A exists alone, object A and object B exist simultaneously, and object B exists alone.

[0043] In a GPU virtualization scenario, both the host driver and the guest driver need to run their own drivers, and each driver needs to communicate with the firmware in the GPU hardware to schedule various GPU hardware resources.

[0044] The Host driver, also known as the Host driver program, is a device that runs on the host operating system (Host OS) and is responsible for managing the communication between the GPU hardware on the host and the guest machines. The Host driver uses virtualization technology to divide the GPU resources into multiple virtual GPUs, with each virtual GPU corresponding to one guest machine.

[0045] The Guest driver, also known as the Guest driver or Guest driver program, runs in the Guest OS and is responsible for managing the virtual GPU hardware on the guest machine and sending requests to the host to obtain access to GPU resources.

[0046] Firmware can be a program written to either Erasable Programmable Read Only Memory (EPROM) or Electrically Erasable Programmable Read Only Memory (EEPROM). Firmware refers to the device "driver" stored inside the device. Through firmware, the operating system can implement specific machine operations according to standard device drivers, such as optical drives and burning discs. The interface provided by firmware allows host drivers and guest drivers to interact.

[0047] As a PCIe device, a GPU's model is typically identified by its PCIe Vendor ID and Device ID. Different combinations of Vendor ID and Device ID represent different GPU devices. The server operating system can use the Vendor ID and Device ID as identifiers to load the host driver for the GPU.

[0048] In the traditional model, when multiple GPUs of the same model exist on the same server, since these GPUs have the same Vendor ID and Device ID, the Host driver version information loaded for these GPUs is also the same. Furthermore, when loading the Host driver, the same version of Firmware is also loaded for these GPUs.

[0049] Due to the unique nature of virtualized environments, the Host driver primarily manages software and hardware resources, while the Firmware and Guest drivers are the actual users of GPU resources. The Guest driver needs the Firmware to utilize the various capabilities of the GPU hardware; therefore, the Firmware version information significantly impacts the GPU's functionality, performance, and stability. When multiple GPUs on the same server load the same version of Firmware, the Guest driver matching that Firmware must also use the same version. This severely limits the flexibility of virtual GPU (vGPU) resource allocation and reduces resource utilization.

[0050] Based on this, embodiments of this application provide a firmware loading method applied to a server. The method includes: first, obtaining configuration information of a first driver of the virtual machine when the virtual machine starts; then, determining the version information of a first firmware based on the configuration information of the first driver; and finally, traversing at least two running GPUs, and determining, based on the firmware information of the at least two GPUs and the version information of the first firmware, loading the first firmware on a target GPU among the at least two GPUs.

[0051] This application also provides a firmware loading method applied to a virtual machine. The method includes: sending configuration information of a first driver to a server when the virtual machine starts; obtaining first indication information from the server, the first indication information indicating that the first firmware has been successfully loaded on a target GPU among at least two graphics processing units (GPUs) running on the server; wherein the version information of the first firmware is associated with the configuration information of the first driver.

[0052] In this way, the version information of the first firmware can be flexibly selected based on the configuration information of the first driver, and the first firmware can be loaded on the target GPU. Thus, for multiple GPU cards on the same server, when the configuration information of the first driver is different, the selected firmware version information will also be different, thereby enabling different versions of firmware to be loaded on multiple GPU cards. This allows the multiple GPU cards to run the first driver with different configuration information, thereby improving both the flexibility of resource allocation and the utilization rate of resources.

[0053] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0054] Figure 1 A flowchart illustrating an optional firmware loading method provided in this application embodiment. Figure 1 ,like Figure 1 As shown, this includes S110 to S140:

[0055] S110, The virtual machine sends the configuration information of the first driver to the server.

[0056] It should be noted that when the virtual machine starts, it can send the configuration information of the first driver to the server, so that the server can obtain the configuration information of the first driver.

[0057] The configuration information of the first driver may include the driver type and / or version information of the first driver.

[0058] For example, the first driver can be the Guest driver.

[0059] It should be understood that, in the embodiments of this application, the configuration information of the first driver may include the driver type of the first driver, the version information of the first driver, or even other information of the first driver. The embodiments of this application do not limit this.

[0060] It should also be noted that, in this embodiment of the application, before the virtual machine sends the configuration information of the first driver to the server, the method may further include: the virtual machine starts and loads the Guest driver.

[0061] In some embodiments, before the virtual machine sends the configuration information of the first driver to the server, the method may further include: the virtual machine obtaining second indication information from the server, the second indication information being used to indicate that the second driver of the server has been successfully loaded.

[0062] For example, the second driver can be the Host driver.

[0063] Furthermore, after the virtual machine obtains the second instruction information from the server, the method may also include: starting the virtual machine and loading the Guest driver.

[0064] Accordingly, in some embodiments, before the server obtains the configuration information of the first driver of the virtual machine, the method may further include: determining that the second driver of the server has been successfully loaded.

[0065] S120. The server determines the version information of the first firmware based on the configuration information of the first driver.

[0066] For example, the first firmware may be firmware.

[0067] It should be understood that the configuration information of the first driver is matched with the version information of the first firmware. After obtaining the configuration information of the first driver, the server can obtain the version information of the first firmware based on the matching relationship between the configuration information of the first driver and the version information of the first firmware.

[0068] It should also be understood that the version information of the first firmware matches the configuration information of the first driver, which can be understood as the version information of the first firmware being associated with the configuration information of the first driver.

[0069] It should be noted that the server stores version information for multiple firmware versions. After obtaining the configuration information of the first driver, the server can select the version information of the first firmware that matches the configuration information of the first driver from among the multiple firmware version information.

[0070] It should also be noted that when the server determines the version information of the first firmware, this version information is one of the multiple firmware versions that the server can support. In other words, the first firmware is usable for the server, and the server can load the first firmware on one of the running GPUs.

[0071] It should be noted that the embodiments of this application involve three version information: the version information of the first driver, the version information of the second driver, and the version information of the first firmware. The server can load the second driver according to the version information of the second driver, and after the second driver is successfully loaded, it obtains the version information of the first driver of the virtual machine. Then, the server can determine the version information of the first firmware based on the version information of the first driver. The version information of the first driver and the version information of the first firmware are matched.

[0072] S130: The server iterates through at least two running GPUs and, based on the firmware information of the at least two GPUs and the version information of the first firmware, determines which target GPU to load the first firmware.

[0073] It should be noted that the firmware information of at least two GPUs may be whether at least two GPUs have loaded firmware, or it may be the firmware version information on the GPU that has loaded firmware. This application embodiment does not limit this.

[0074] Based on this, in the embodiments of this application, it is determined that loading the first firmware on the target GPU can be implemented in the following two possible ways.

[0075] One possible implementation is that the server determines whether to load the first firmware on the target GPU among the at least two GPUs based on the firmware information of at least two GPUs and the version information of the first firmware. This may include: if the target GPU has already loaded the second firmware and the version information of the second firmware is the same as the version information of the first firmware, then the server may determine that the first firmware has been loaded on the target GPU when the remaining resources on the target GPU are greater than or equal to the resources required by the first driver.

[0076] In other words, based on the firmware information of at least two GPUs and the version information of the first firmware, the server determines whether the second firmware is already loaded on the target GPU. First, it checks whether the second firmware is already loaded on the target GPU. Second, if the second firmware is already loaded on the target GPU, it checks whether the version information of the second firmware is the same as the version information of the first firmware. Then, if the version information of the second firmware is the same as the version information of the first firmware, it further checks whether the remaining resources on the target GPU are greater than or equal to the resources required by the first driver. Finally, if the remaining resources on the target GPU are greater than or equal to the resources required by the first driver, it can be determined that the first firmware has been loaded on the target GPU.

[0077] For example, suppose there are two GPUs, denoted as GPU1 and GPU2. If GPU1 has loaded the second firmware and the version information of the second firmware is the same as the version information of the first firmware, the server can determine that the first firmware has been loaded on GPU1 when the remaining resources on GPU1 are greater than or equal to the resources required by the first driver; or, if GPU2 has loaded the second firmware and the version information of the second firmware is the same as the version information of the first firmware, the server can determine that the first firmware has been loaded on GPU2 when the remaining resources on GPU2 are greater than or equal to the resources required by the first driver.

[0078] It should be noted that when the target GPU has loaded the second firmware, the server can determine that the first firmware has been loaded on the target GPU when both of the following conditions are met: the version information of the second firmware is the same as the version information of the first firmware, and the remaining resources on the target GPU are greater than or equal to the resources required by the first driver.

[0079] It should be understood that when the amount of remaining resources on the target GPU is greater than or equal to the amount of resources required by the first driver, the server can create the resources required by the first driver on the target GPU; furthermore, when the version information of the second firmware is the same as the version information of the first firmware, the fact that the second firmware has been loaded on the target GPU is essentially the same as the fact that the first firmware has been loaded on the target GPU.

[0080] This application provides a firmware loading method. If the target GPU has already loaded a second firmware, and the version information of the second firmware is the same as the version information of the first firmware, then the server can determine that the first firmware has been loaded on the target GPU when the remaining resources on the target GPU are greater than or equal to the resources required by the first driver. This improves the flexibility of resource allocation and also increases resource utilization.

[0081] Another possible implementation is that the server determines to load the first firmware on the target GPU among the at least two GPUs based on the firmware information of at least two GPUs and the version information of the first firmware. This may include: if there is a target GPU among the at least two GPUs that has not loaded firmware, the server can load the first firmware on the target GPU according to the version information of the first firmware.

[0082] In other words, when the server determines whether to load the first firmware on the target GPU based on the firmware information of at least two GPUs and the version information of the first firmware, it can determine whether there is a target GPU without firmware loaded among the at least two GPUs. If there is a target GPU without firmware loaded among the at least two GPUs, the server can load the first firmware on the target GPU according to the version information of the first firmware.

[0083] For example, suppose there are two GPUs, denoted as GPU1 and GPU2. If GPU1 does not have firmware loaded, the first firmware can be loaded on GPU1 based on its version information; or, if GPU2 does not have firmware loaded, the first firmware can be loaded on GPU2 based on its version information.

[0084] It should be noted that when the target GPU is not loaded with firmware, the remaining resources on the target GPU can be considered to be greater than or equal to the resources required by the first driver, and thus the server can create the resources required by the first driver on the target GPU.

[0085] This application provides a firmware loading method. If at least two GPUs contain a target GPU without firmware, the server can load the first firmware onto the target GPU based on the version information of the first firmware. This improves the flexibility of resource allocation and also increases resource utilization.

[0086] Based on the two possible implementations mentioned above, when the server loads the first firmware on the target GPU in at least two GPUs, the method may further include: the server creating the resources required for the first driver on the target GPU.

[0087] It should be noted that when the server loads the first firmware on the target GPU in at least two GPUs, the amount of remaining resources on the target GPU is greater than or equal to the amount of resources required by the first driver, thereby enabling the server to create the resources required by the first driver on the target GPU.

[0088] S140, The server sends the first instruction information to the virtual machine.

[0089] Accordingly, the virtual machine can obtain the server's initial instruction information.

[0090] The first indication information can be used to indicate that the first firmware has been successfully loaded on the target GPU.

[0091] For example, after obtaining the first indication information, the virtual machine can know that the first firmware has been successfully loaded on the target GPU.

[0092] In some embodiments, the method may further include: the virtual machine may determine, in response to a first indication message, that the first driver has been successfully loaded.

[0093] Using this method, after the virtual machine learns that the first firmware has been successfully loaded on the target GPU, it can further determine that the first driver has been successfully loaded. At this point, the resources required by the first driver created on the target GPU can provide normal vGPU functionality.

[0094] It should be noted that, in the embodiments of this application, when there are more than two virtual machines, at least two virtual machines may have different firmware version information.

[0095] In other words, there are at least two virtual machines that send different configuration information for the first driver to the server, which in turn makes the firmware version information loaded by these two virtual machines different.

[0096] For example, suppose there are two virtual machines, referred to as virtual machine 1 and virtual machine 2. Since virtual machine 1 and virtual machine 2 send different configuration information of the first driver to the server, the firmware version information loaded by virtual machine 1 and virtual machine 2 is also different.

[0097] This method allows at least two virtual machines to load different firmware versions, thereby improving both the flexibility of resource allocation and the utilization of resources.

[0098] It should also be noted that, in the embodiments of this application, when there are more than two virtual machines, the firmware version information loaded by each of the more than two virtual machines can also be the same.

[0099] In other words, when more than two virtual machines send the same configuration information for the first driver to the server, the firmware version information loaded by each of the more than two virtual machines is also the same.

[0100] This application provides a firmware loading method. First, when the virtual machine starts, the server can obtain the configuration information of the virtual machine's first driver. Then, the server can determine the version information of the first firmware based on the configuration information of the first driver. Finally, the server can traverse at least two running GPUs and, based on the firmware information of the at least two GPUs and the version information of the first firmware, determine which target GPU to load the first firmware on. In this way, the server can flexibly select the version information of the first firmware based on the configuration information of the first driver and load the first firmware on the target GPU. Thus, for multiple GPUs on the same server, when the configuration information of the first driver is different, the selected firmware version information will also be different, thereby enabling the loading of firmware with different versions on multiple GPUs. This allows the multiple GPUs to run first drivers with different configuration information, thereby improving both the flexibility of resource allocation and the utilization rate of resources.

[0101] In this embodiment, if the first firmware fails to load on a GPU, the server can use another GPU as the target GPU and execute one of the two possible implementation methods again: (1) If the target GPU has loaded the second firmware, and the version information of the second firmware is the same as the version information of the first firmware, the server can determine that the first firmware has been loaded on the target GPU when the remaining resources on the target GPU are greater than or equal to the resources required by the first driver; (2) If there is a target GPU among at least two GPUs that has not loaded the firmware, the server can load the first firmware on the target GPU according to the version information of the first firmware. If none of the GPUs on the server can execute method (1) and method (2) as target GPUs, it can be determined that the first firmware loading has failed.

[0102] In other words, based on S110 to S140, the server can determine that the first firmware was successfully loaded based on the firmware information of at least two GPUs and the version information of the first firmware; correspondingly, the server can also determine that the first firmware failed to load based on the firmware information of at least two GPUs and the version information of the first firmware.

[0103] Figure 2 A flowchart illustrating an optional firmware loading method provided in this application embodiment. Figure 2 ,like Figure 2 As shown, the method may include S210 to S240:

[0104] S210, The virtual machine sends the configuration information of the first driver to the server;

[0105] S220. The server determines the version information of the first firmware based on the configuration information of the first driver.

[0106] S230: The server iterates through at least two running GPUs and determines that the first firmware failed to load based on the firmware information of at least two GPUs and the version information of the first firmware.

[0107] S240, The server sends a third instruction message to the virtual machine.

[0108] The third indication information can be used to indicate that the first firmware failed to load.

[0109] In some embodiments, the server traverses at least two running GPUs and determines that the first firmware loading has failed based on the firmware information of the at least two GPUs and the version information of the first firmware. This may include: when the server traverses at least two running GPUs, if both at least two GPUs have already loaded the second firmware, then the version information of the second firmware is different from the version information of the first firmware, and / or the remaining resources on both at least two GPUs are less than the resources required by the first driver, the server may determine that the first firmware loading has failed.

[0110] In other words, when at least two GPUs have loaded the second firmware, the server can determine that the first firmware loading has failed if at least one of the following conditions is met: the version information of the second firmware is different from the version information of the first firmware, or the remaining resources on at least two GPUs are less than the resources required by the first driver.

[0111] For example, at least two GPUs include the target GPU. When the target GPU has loaded the second firmware, if the remaining resources on the target GPU are less than the resources required by the first driver, then the remaining resources on the target GPU are insufficient to create the resources required by the first driver on the target GPU, thus preventing the first firmware from being loaded on the target GPU, causing the first firmware loading to fail.

[0112] For example, at least two GPUs include the target GPU. When the target GPU has loaded the second firmware, if the version information of the second firmware is different from the version information of the first firmware, and the target GPU is unable to load any other firmware different from the second firmware, the loading of the first firmware will fail.

[0113] After the server sends the third instruction information to the virtual machine, the virtual machine can then obtain that third instruction information.

[0114] For example, after obtaining the third indication information, the virtual machine can know that the first firmware failed to load.

[0115] In some embodiments, the method may further include: determining, in response to a third indication message, that the first driver loading has failed.

[0116] Using this method, after the virtual machine learns that the first firmware has failed to load, it can further learn that the first driver has failed to load, thus failing to provide normal vGPU functionality.

[0117] Furthermore, if the virtual machine still needs to load the first driver after learning that it has failed to do so, it can trigger scheduling again. If a GPU meets the vGPU resource requirements at this time, the resources (vGPU resources) required by the first driver can be created on that GPU, thereby further loading the first firmware on that GPU. In other words, if the virtual machine still needs to load the first driver, it can continue to send the configuration information of the first driver to the server again and execute the process again. Figure 1 and Figure 2 The relevant processes continue until the first driver is successfully loaded.

[0118] This application provides a firmware loading method. First, when the virtual machine starts, the server can obtain the configuration information of the virtual machine's first driver. Second, the server can determine the version information of the first firmware based on the configuration information of the first driver. Then, the server can traverse at least two running GPUs and, based on the firmware information of at least two GPUs and the version information of the first firmware, determine that the first firmware loading has failed. Finally, the server sends a third indication message to the virtual machine, which can be used to indicate that the first firmware loading has failed. In this way, the virtual machine can determine that it cannot load the first firmware on any of the server's GPUs. At this point, the virtual machine can choose to load the first firmware on the GPUs of other servers, or the virtual machine can choose to send a first driver with other configuration information to the server so that other firmware can be loaded on the GPUs of that server. This improves both the flexibility of resource allocation and the utilization rate of resources.

[0119] The firmware loading method provided in the above embodiments will be described in detail below in conjunction with specific application scenarios.

[0120] This application proposes a method for loading firmware with different version information for each GPU in a multi-GPU environment. This allows multiple GPUs on a server to run Guest drivers (i.e., the aforementioned first driver) with different configuration information, improving the flexibility of deployment in a cloud environment and also improving resource utilization efficiency.

[0121] In this embodiment, firmware loading can be deferred until the Guest driver is loaded. By checking the Guest driver's configuration information, a matching firmware version is selected, and the firmware with that version is loaded onto the GPU. When a virtual machine starts and attempts to load a Guest driver with a different configuration, the server selects a GPU with firmware that matches the Guest driver to create vGPU resources (i.e., the resources required by the aforementioned first driver) and provides the runtime environment. If no matching firmware exists on a GPU, and a new GPU (without firmware loaded) exists, the firmware matching the Guest driver is loaded onto the new GPU.

[0122] In related technologies, the host driver loads firmware for the GPU simultaneously. Compared to traditional implementations, the technical solution provided in this application does not load firmware for the GPU during host driver loading. When the virtual machine starts loading the guest driver, the guest driver initialization phase begins. Specifically, the virtual machine first communicates with the server, which obtains the guest driver's configuration information. Based on this configuration, the server selects the supported firmware version and loads the firmware with that version for the GPU. At this point, the firmware is loaded on the GPU using vGPU resources, while other GPUs not using vGPU resources remain unloaded until vGPU resources become available. This method postpones firmware loading from the host driver initialization phase to the guest driver initialization phase. Therefore, the firmware version can be flexibly selected based on the guest driver's configuration information, allowing different versions of firmware to run on different GPUs on the same server, effectively improving the flexibility of GPU resource allocation.

[0123] Figure 3 This is a detailed flowchart illustrating an optional firmware loading method provided in an embodiment of this application. Prior to this detailed process, it is ensured that the Host driver on the server is correctly installed and running; that multiple GPUs on the server can run vGPU resources; and that the server contains a supported firmware file running on the hardware.

[0124] like Figure 3As shown, the firmware loading method can be applied to servers, and it can also be applied to virtual machines. Servers can run virtual machines, and guest drivers can run on these virtual machines. The server and GPU can be connected via a hardware interface. This detailed process can include steps S301 to S314:

[0125] S301, Start the Guest driver in the virtual machine.

[0126] For example, the virtual machine starts loading the Guest driver.

[0127] S302. The virtual machine sends the Guest driver type and version information to the server.

[0128] Accordingly, the server can obtain the Guest driver type and version information.

[0129] S303. The server selects a supported firmware version based on the Guest driver type and version information.

[0130] S304. The server iterates through all current GPUs and checks the firmware running status on each GPU.

[0131] S305. The server determines whether there is firmware with the same version information running on the GPU, and whether there are any remaining resources on the GPU.

[0132] If the server determines that there is firmware running on the GPU that matches the version information selected in S303, and there are remaining resources on the GPU, then execute S306 to S307; otherwise, execute S308.

[0133] S306. The server creates vGPU resources on the GPU.

[0134] The server creates the corresponding vGPU resources on the GPU selected in S305.

[0135] S307. The server sends a message to the virtual machine indicating that the firmware has been successfully loaded.

[0136] The server notifies the virtual machine that the firmware has been successfully loaded and executes S312.

[0137] S308. The server determines whether there is a GPU without firmware loaded.

[0138] If the server determines that there is a GPU without firmware loaded, then execute S309 to S310; otherwise, execute S311.

[0139] S309. The server loads firmware with this version information onto the GPU and creates vGPU resources on the GPU.

[0140] The server loads the firmware selected in S303 onto the GPU selected in S308 and creates the corresponding vGPU resources on that GPU.

[0141] S310, The server sends a message to the virtual machine that the firmware has been successfully loaded.

[0142] The server notifies the virtual machine that the firmware has been successfully loaded and executes S312.

[0143] S311, The server failed to send a firmware loading message to the virtual machine.

[0144] It should be noted that if the server sends a firmware loading failure message to the virtual machine, it means that firmware is loaded on all GPUs, but none of them are running the same firmware version selected in S303, and / or there are no remaining resources on all GPUs.

[0145] The server notifies the virtual machine of the firmware loading failure and executes S312.

[0146] S312. The virtual machine checks whether the firmware has been loaded successfully.

[0147] The virtual machine obtains the firmware loading result and determines whether the firmware was loaded successfully based on the result. If the firmware was loaded successfully, step S313 is executed; otherwise, if the firmware failed to load, step S314 is executed.

[0148] S313 and Firmware loaded successfully, VGPU is running normally.

[0149] It should be noted that if the Firmware loads successfully, it means that the Guest driver also loads successfully and can provide vGPU functionality normally.

[0150] S314, Firmware loading failed, VGPU cannot run.

[0151] It should be noted that if the Firmware fails to load, it means that the Guest driver also fails to load and cannot provide vGPU functionality properly.

[0152] This application provides a firmware loading method. In a multi-GPU environment, the firmware version information can be flexibly selected based on the Guest driver's configuration information (such as driver type or version information), and different versions of firmware can be loaded for different GPUs to adapt to different Guest drivers. This method can, on the one hand, provide better performance and stability for the Guest; on the other hand, it can significantly improve the flexibility of resource allocation and resource utilization in a cloud environment.

[0153] The preferred embodiments of this application have been described in detail above with reference to the accompanying drawings. However, this application is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this application, various simple modifications can be made to the technical solutions of this application, and these simple modifications all fall within the protection scope of this application. For example, the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, this application will not describe the various possible combinations separately. Furthermore, various different embodiments of this application can also be arbitrarily combined, as long as they do not violate the spirit of this application, they should also be considered as the content disclosed in this application. Moreover, without conflict, the various embodiments and / or the technical features in the various embodiments described in this application can be arbitrarily combined with the prior art, and the resulting technical solutions should also fall within the protection scope of this application.

[0154] It should be understood that in the various method embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0155] Based on the same inventive concept as the foregoing embodiments. Figure 4 The following is a schematic diagram of an optional server structure provided for an embodiment of this application, as shown below. Figure 4 As shown, server 400 may include a first acquisition unit 410 and a first determination unit 420, wherein:

[0156] The first acquisition unit 410 is used to acquire the configuration information of the first driver of the virtual machine when the virtual machine starts.

[0157] The first determining unit 420 is configured to determine the version information of the first firmware based on the configuration information of the first driver; and to traverse at least two running graphics processing units (GPUs) and determine, based on the firmware information of the at least two GPUs and the version information of the first firmware, to load the first firmware on a target GPU among the at least two GPUs.

[0158] In some embodiments of this application, the first determining unit 420 is further configured to determine that the first firmware has been loaded on the target GPU if the target GPU has loaded the second firmware and the version information of the second firmware is the same as the version information of the first firmware, and the remaining resources on the target GPU are greater than or equal to the resources required by the first driver.

[0159] In some embodiments of this application, the first determining unit 420 is further configured to determine, based on the version information of the first firmware, to load the first firmware on the target GPU if at least two GPUs have a target GPU that has not loaded firmware.

[0160] In some embodiments of this application, such as Figure 4 As shown, server 400 may further include creation unit 430, wherein:

[0161] Create unit 430 to create the resources required for the first driver on the target GPU.

[0162] In some embodiments of this application, such as Figure 4 As shown, server 400 may further include a first sending unit 440, wherein:

[0163] The first sending unit 440 is used to send first indication information to the virtual machine, the first indication information being used to indicate that the first firmware has been successfully loaded on the target GPU.

[0164] In some embodiments of this application, the first determining unit 420 is also used to determine that the second driver of the server has been successfully loaded.

[0165] In some embodiments of this application, when there are more than two virtual machines, at least two virtual machines load different firmware version information.

[0166] In some embodiments of this application, the configuration information of the first driver includes the driver type and / or version information of the first driver.

[0167] This application provides a server. First, when a virtual machine starts, the server can obtain the configuration information of the virtual machine's first driver. Then, the server can determine the version information of the first firmware based on the configuration information of the first driver. Finally, the server can traverse at least two running GPUs and, based on the firmware information of at least two GPUs and the version information of the first firmware, determine which target GPU to load the first firmware on. In this way, the server can flexibly select the version information of the first firmware based on the configuration information of the first driver and load the first firmware on the target GPU. Thus, for multiple GPUs on the same server, when the configuration information of the first driver is different, the selected firmware version information will also be different, thereby enabling the loading of firmware with different versions on multiple GPUs. This allows the multiple GPUs to run first drivers with different configuration information, thereby improving both the flexibility of resource allocation and the utilization rate of resources.

[0168] Those skilled in the art should understand that the above description of the server in the embodiments of this application can be understood with reference to the description of the firmware loading method in the embodiments of this application.

[0169] Based on the same inventive concept as the foregoing embodiments. Figure 5 A schematic diagram of the optional virtual machine structure provided in this application embodiment is shown below. Figure 5 As shown, the virtual machine 500 may include a second sending unit 510 and a second acquiring unit 520, wherein:

[0170] The second sending unit 510 is used to send the configuration information of the first driver to the server when the virtual machine starts.

[0171] The second acquisition unit 520 is used to acquire first indication information from the server. The first indication information indicates that the first firmware has been successfully loaded on the target GPU of at least two graphics processing units (GPUs) running on the server. The version information of the first firmware is associated with the configuration information of the first driver.

[0172] In some embodiments of this application, such as Figure 5 As shown, the virtual machine 500 may further include a second determining unit 530, wherein:

[0173] The second determining unit 530 is used to determine, in response to the first indication information, that the first driver has been successfully loaded.

[0174] In some embodiments of this application, the second acquisition unit 520 is used to acquire second indication information from the server, which is used to indicate that the second driver of the server has been successfully loaded.

[0175] In some embodiments of this application, when there are more than two virtual machines, at least two virtual machines load different firmware version information.

[0176] In some embodiments of this application, the configuration information of the first driver includes the driver type and / or version information of the first driver.

[0177] This application provides a virtual machine. Upon startup, the virtual machine sends configuration information of a first driver to a server; it also obtains first indication information from the server, indicating that a first firmware has been successfully loaded on a target GPU among at least two graphics processing units (GPUs) running on the server; wherein the version information of the first firmware is associated with the configuration information of the first driver. Thus, when the configuration information of the first driver sent by the virtual machine to the server is different, even if the first firmware is successfully loaded, the version information of the first firmware associated with that configuration information will also be different. This enables the loading of first firmware with different versions on multiple GPU cards, allowing multiple GPU cards to run first drivers with different configuration information, improving both the flexibility of resource allocation and resource utilization.

[0178] Those skilled in the art should understand that the above description of the virtual machine in the embodiments of this application can be understood with reference to the description of the firmware loading method in the embodiments of this application.

[0179] Figure 6 This is a schematic structural diagram of an electronic device 600 provided in an embodiment of this application. Figure 6 As shown, the electronic device 600 includes a processor 610 and a memory 620. The memory 620 can store computer programs, and the processor 610 can call and run the computer programs from the memory 620 to implement the methods in the embodiments of this application.

[0180] The memory 620 can be a separate device independent of the processor 610, or it can be integrated into the processor 610.

[0181] In some embodiments of this application, such as Figure 6 As shown, the electronic device 600 may also include a transceiver 630, which the processor 610 can control to communicate with other devices. Specifically, it can send information or data to other devices or receive information or data sent by other devices.

[0182] The transceiver 630 may include a transmitter and a receiver. The transceiver 630 may further include antennas, and the number of antennas may be one or more.

[0183] In some embodiments of this application, another electronic device is also provided, wherein the electronic device may include the server 400 as described in any of the foregoing embodiments; or, the electronic device may include the virtual machine 500 as described in any of the foregoing embodiments.

[0184] Figure 7 This is a schematic structural diagram of a chip provided in an embodiment of this application. For example... Figure 7 As shown, chip 700 includes processor 710, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0185] In some embodiments of this application, such as Figure 7 As shown, chip 700 may further include memory 720. Processor 710 can retrieve and run computer programs from memory 720 to implement the methods described in this embodiment.

[0186] The memory 720 can be a separate device independent of the processor 710, or it can be integrated into the processor 710.

[0187] In some embodiments of this application, the chip 700 may further include an input interface 730. The processor 710 can control the input interface 730 to communicate with other devices or chips; specifically, it can acquire information or data sent by other devices or chips.

[0188] In some embodiments of this application, the chip 700 may further include an output interface 740. The processor 710 can control the output interface 740 to communicate with other devices or chips; specifically, it can output information or data to other devices or chips.

[0189] In some embodiments of this application, the chip can be applied to the server in the embodiments of this application, and for the sake of brevity, it will not be described in detail here.

[0190] In some embodiments of this application, the chip can be applied to the virtual machine in the embodiments of this application, and for the sake of brevity, it will not be described in detail here.

[0191] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0192] Figure 8 This is a schematic block diagram of a communication system 800 provided in an embodiment of this application. Figure 8 As shown, the communication system 800 includes a server 810 and a virtual machine 820.

[0193] The server 810 can be used to implement the corresponding functions implemented by the server in the above method, and the virtual machine 820 can be used to implement the corresponding functions implemented by the virtual machine in the above method. For the sake of brevity, further details are omitted here.

[0194] It is understood that the processor in the embodiments of this application may be an integrated circuit chip with information processing capabilities. In implementation, each step of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, 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 application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software modules can be located 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.

[0195] It is also understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memories described herein are intended to include, but are not limited to, these and any other suitable types of memory.

[0196] It is also understood that the above-described memory is exemplary and not a limiting description. For example, the memory in the embodiments of this application may also be Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Dynch Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM), etc. In other words, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0197] This application also provides a computer-readable storage medium for storing computer programs.

[0198] In some embodiments of this application, the computer-readable storage medium can be applied to the server in the embodiments of this application, and when the computer program is executed by at least one processor, it implements the corresponding processes implemented by the server in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.

[0199] In some embodiments of this application, the computer-readable storage medium can be applied to the virtual machine in the embodiments of this application, and when the computer program is executed by at least one processor, it implements the corresponding processes implemented by the virtual machine in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.

[0200] This application also provides a computer program product, including computer program instructions.

[0201] In some embodiments of this application, the computer program product can be applied to the server in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the server in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0202] In some embodiments of this application, the computer program product can be applied to the virtual machine in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the virtual machine in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0203] This application also provides a computer program.

[0204] In some embodiments of this application, the computer program can be applied to the server in the embodiments of this application. When the computer program is run on the computer, it causes the computer to execute the corresponding processes implemented by the server in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0205] In some embodiments of this application, the computer program can be applied to the virtual machine in the embodiments of this application. When the computer program runs on the computer, it causes the computer to execute the corresponding processes implemented by the virtual machine in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0206] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0207] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus and unit can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0208] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0209] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0210] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0211] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0212] It should be noted that, in this application, 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 a process, method, article, or apparatus. Without further limitation, 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.

[0213] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0214] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0215] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0216] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0217] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A firmware loading method, characterized in that, Applied to a server, the method includes: When the virtual machine starts, obtain the configuration information of the first driver of the virtual machine; Based on the configuration information of the first driver, determine the version information of the first firmware; The system iterates through at least two running graphics processing units (GPUs) and, based on the firmware information of the at least two GPUs and the version information of the first firmware, determines which target GPU will load the first firmware.

2. The method according to claim 1, characterized in that, The step of determining whether to load the first firmware on a target GPU among the at least two GPUs based on the firmware information of the at least two GPUs and the version information of the first firmware includes: If the target GPU has loaded the second firmware, and the version information of the second firmware is the same as the version information of the first firmware, then it is determined that the first firmware has been loaded on the target GPU when the remaining resources on the target GPU are greater than or equal to the resources required by the first driver.

3. The method according to claim 1, characterized in that, The step of determining whether to load the first firmware on a target GPU among the at least two GPUs based on the firmware information of the at least two GPUs and the version information of the first firmware includes: If one of the at least two GPUs has a target GPU without firmware loaded, then the first firmware is loaded on the target GPU according to the version information of the first firmware.

4. The method according to any one of claims 1 to 3, characterized in that, When loading the first firmware on the target GPU of the at least two GPUs, the method further includes: The resources required to create the first driver are created on the target GPU.

5. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Send a first indication message to the virtual machine, the first indication message being used to indicate that the first firmware has been successfully loaded on the target GPU.

6. The method according to any one of claims 1 to 3, characterized in that, Before obtaining the configuration information of the first driver of the virtual machine, the method further includes: The second driver for the server has been successfully loaded.

7. The method according to claim 1, characterized in that, When there are more than two virtual machines, at least two of the virtual machines will have different firmware version information.

8. The method according to claim 1, characterized in that, The configuration information of the first driver includes the driver type and / or version information of the first driver.

9. A firmware loading method, characterized in that, Applied to a virtual machine, the method includes: When the virtual machine starts, it sends the configuration information of the first driver to the server; Obtain first indication information from the server, the first indication information being used to indicate that the first firmware has been successfully loaded on the target GPU of at least two graphics processing units (GPUs) running on the server; wherein, the version information of the first firmware is associated with the configuration information of the first driver.

10. The method according to claim 9, characterized in that, The method further includes: In response to the first indication information, it is determined that the first driver was successfully loaded.

11. The method according to claim 9 or 10, characterized in that, Before sending the configuration information of the first driver to the server, the method further includes: Obtain the second indication information of the server, which is used to indicate that the second driver of the server has been successfully loaded.

12. The method according to any one of claims 9 to 11, characterized in that, When there are more than two virtual machines, at least two of the virtual machines will have different firmware version information.

13. The method according to any one of claims 9 to 12, characterized in that, The configuration information of the first driver includes the driver type and / or version information of the first driver.

14. A server, characterized in that, The server includes a first acquisition unit and a first determination unit, wherein: The first acquisition unit is used to acquire the configuration information of the first driver of the virtual machine when the virtual machine starts. The first determining unit is used to determine the version information of the first firmware based on the configuration information of the first driver; The first determining unit is further configured to traverse at least two running graphics processing units (GPUs) and, based on the firmware information of the at least two GPUs and the version information of the first firmware, determine the target GPU among the at least two GPUs to load the first firmware.

15. A virtual machine, characterized in that, The virtual machine includes a second sending unit and a second acquiring unit, wherein: The second sending unit is used to send the configuration information of the first driver to the server when the virtual machine starts; The second acquisition unit is used to acquire first indication information of the server, the first indication information being used to indicate that the first firmware has been successfully loaded on the target GPU of at least two graphics processing units (GPUs) running on the server; wherein, the version information of the first firmware is associated with the configuration information of the first driver.

16. An electronic device, characterized in that, include: A processor and a memory, the memory being used to store a computer program, the processor being used to invoke and run the computer program stored in the memory to perform the method as described in any one of claims 1 to 8; or, to perform the method as described in any one of claims 9 to 13.

17. A chip, characterized in that, include: A processor for retrieving and running a computer program from memory, causing a device on which the chip is mounted to perform the method as described in any one of claims 1 to 8; Alternatively, the method as described in any one of claims 9 to 13 may be performed.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by at least one processor, implements the method as described in any one of claims 1 to 8; or implements the method as described in any one of claims 9 to 13.

Images