CN116880921A - Firmware loading method, server, virtual machine, device, chip and storage medium - Google Patents

Firmware loading method, server, virtual machine, device, chip and storage medium Download PDF

Info

Publication number
CN116880921A
CN116880921A CN202310813100.5A CN202310813100A CN116880921A CN 116880921 A CN116880921 A CN 116880921A CN 202310813100 A CN202310813100 A CN 202310813100A CN 116880921 A CN116880921 A CN 116880921A
Authority
CN
China
Prior art keywords
firmware
server
information
virtual machine
version information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310813100.5A
Other languages
Chinese (zh)
Inventor
张子健
王琎
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Moore Threads Technology Co Ltd
Original Assignee
Moore Threads Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Moore Threads Technology Co Ltd filed Critical Moore Threads Technology Co Ltd
Priority to CN202310813100.5A priority Critical patent/CN116880921A/en
Publication of CN116880921A publication Critical patent/CN116880921A/en
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G06F9/44526—Plug-ins; Add-ons
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G06F9/4451—User profiles; Roaming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44536—Selecting among different versions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances

Abstract

The embodiment of the application provides a firmware loading method, a server, a virtual machine, equipment, a chip and a storage medium, wherein the method comprises the following steps: when a virtual machine is started, acquiring configuration information of a first drive of the virtual machine; determining version information of the first firmware according to the configuration information of the first driver; traversing the running at least two graphics processor GPUs, and determining to load the first firmware on a target GPU of the at least two GPUs based on firmware information of the at least two GPUs and version information of the first firmware. Thus, not only the flexibility of resource allocation is improved, but also the utilization rate of resources is improved.

Description

Firmware loading method, server, virtual machine, device, chip and storage medium
Technical Field
The present application relates to the field of computer technologies, and in particular, to a firmware loading method, a server, a virtual machine, a device, a chip, and a storage medium.
Background
The graphics processor (Graphics Processing Unit, GPU) is configured as a high-speed serial computer expansion bus standard (Peripheral Component Interconnect Express, PCIE) Device, and typically determines the GPU model by Vendor ID and Device ID.
In the related art, when multiple GPUs of the same model exist on the same server, since the Vendor IDs and the Device IDs of the GPUs are the same, version information of the loaded Firmware (Firmware) is the same, so that version information of a client (Guest) driver matched with the Firmware is consistent, flexibility of resource allocation is greatly limited, and utilization rate of resources is reduced.
Disclosure of Invention
The embodiment of the application provides a firmware loading method, a server, a virtual machine, equipment, a chip and a storage medium, which can improve the flexibility of resource allocation and the utilization rate of resources.
The technical scheme of the application is realized as follows:
in a first aspect, an embodiment of the present application provides a firmware loading method, which is applied to a server. The method comprises the following steps:
when a virtual machine is started, acquiring configuration information of a first drive of the virtual machine;
determining version information of the first firmware according to the configuration information of the first driver;
traversing the running at least two graphics processor GPUs, and determining to load the first firmware on a target GPU of the at least two GPUs based on firmware information of the at least two GPUs and version information of the first firmware.
In a second aspect, an embodiment of the present application provides a firmware loading method, which is applied to a virtual machine. The method comprises the following steps:
when the virtual machine is started, sending configuration information of a first drive to a server;
acquiring first indication information of a server, wherein the first indication information is used for indicating that a first firmware is successfully loaded on a target GPU (graphics processing unit) in at least two GPU (graphics processing units) running on the server; wherein the version information of the first firmware is associated with configuration information of the first drive.
In a third aspect, an embodiment of the present application provides a server, including a first obtaining unit and a first determining unit, where:
the first acquisition unit is used for acquiring configuration information of a first drive of the virtual machine when the virtual machine is started;
a first determining unit configured to determine version information of the first firmware according to configuration information of the first driver;
the first determining unit is further configured to traverse the running at least two graphics processors GPUs, and determine to load the first firmware on the target GPU of the at least two GPUs based on the firmware information of the at least two GPUs and the version information of the first firmware.
In a fourth aspect, an embodiment of the present application provides a virtual machine, where the virtual machine includes a second sending unit and a second obtaining unit, where:
The second sending unit is used for sending configuration information of the first drive to the server when the virtual machine is started;
the second acquisition unit is used for acquiring first indication information of the server, wherein the first indication information is used for indicating that the first firmware is successfully loaded on a target GPU (graphics processing unit) in at least two GPU (graphics processing units) running on the server; wherein the version information of the first firmware is associated with configuration information of the first drive.
In a fifth aspect, an embodiment of the present application provides an electronic device, including a processor and a memory. The memory is used for storing a computer program, and the processor is used for calling and running the computer program stored in the memory to execute the firmware loading method according to the first aspect or the second aspect.
In a sixth aspect, an embodiment of the present application provides a chip, configured to implement the firmware loading method described in the first aspect or the second aspect.
Specifically, the chip includes: and a processor for calling and running a computer program from the memory, so that the device mounted with the chip executes the firmware loading method described in the first aspect or the second aspect.
In a seventh aspect, an embodiment of the present application provides a computer readable storage medium storing a computer program, where the computer program is executed by at least one processor to implement the firmware loading method according to the first aspect or the second aspect.
In an eighth aspect, an embodiment of the present application provides a computer program product, including computer program instructions, where the computer program instructions cause a computer to perform the firmware loading method according to the first aspect or the second aspect.
In a ninth aspect, an embodiment of the present application provides a computer program, which when run on a computer, causes the computer to perform the firmware loading method described in the first or second aspect above.
The embodiment of the application provides a firmware loading method, a server, a virtual machine, equipment, a chip and a storage medium. Firstly, when a virtual machine is started, a server can acquire configuration information of a first drive of the virtual machine; then, the server may determine version information of the first firmware according to the configuration information of the first driver; finally, the server may traverse the running at least two GPUs, and determine to load the first firmware on the target GPU of the at least two GPUs based on the firmware information of the at least two GPUs and the version information of the first firmware. Thus, the server can flexibly select the version information of the first firmware according to the configuration information of the first driver, and load the first firmware on the target GPU. Therefore, when the configuration information of the first driver is different, the version information of the selected firmware is also different, and the firmware with different version information can be loaded on the plurality of GPU cards, so that the plurality of GPU cards can operate the first drivers with different configuration information, thereby not only improving the flexibility of resource allocation, but also improving the utilization rate of resources.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application as claimed.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application. It is evident that the drawings in the following description are only some embodiments of the present application and that other drawings may be obtained from these drawings without inventive effort for a person of ordinary skill in the art.
The flow diagrams depicted in the figures are exemplary only, and do not necessarily include all of the elements and operations/steps, nor must they be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the order of actual execution may be changed according to actual situations.
Fig. 1 is a flowchart of an alternative firmware loading method according to an embodiment of the present application;
FIG. 2 is a second flowchart of an alternative firmware loading method according to an embodiment of the present application;
FIG. 3 is a detailed flow chart of an alternative firmware loading method according to an embodiment of the present application;
fig. 4 is a schematic diagram of a composition structure of an alternative server according to an embodiment of the present application;
FIG. 5 is a schematic diagram of an alternative virtual machine according to an embodiment of the present application;
fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present application;
FIG. 7 is a schematic block diagram of a chip according to an embodiment of the present application;
fig. 8 is a schematic block diagram of a communication system according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application more apparent, the specific technical solutions of the present application will be described in further detail below with reference to the accompanying drawings in the embodiments of the present application. The following examples are illustrative of the application and are not intended to limit the scope of the application.
Unless defined otherwise, 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 the application only and is not intended to be limiting of the application.
In the following description reference is made to "some embodiments," "this embodiment," "an embodiment of the application," and examples, etc., which describe a subset of all possible embodiments, but it is to be understood that "some embodiments" may be the same subset or different subsets of all possible embodiments and may be combined with one another without conflict.
If a similar description of "first/second" appears in the application document, the following description is added, in which the terms "first/second/third" are merely distinguishing between similar objects and not representing a particular ordering of the objects, it being understood that the "first/second/third" may be interchanged with a particular order or precedence, if allowed, so that embodiments of the application described herein may be practiced otherwise than as illustrated or described herein.
In the embodiment of the present application, the term "and/or" is merely an association relationship describing an associated object, and indicates that three relationships may exist, for example, an object a and/or an object B may be represented: there are three cases where object a alone exists, object a and object B together, and object B alone exists.
In the GPU virtualization scenario, a Host (Host) driver and a Guest driver are required to operate a driver respectively, and the drivers are required to communicate with Firmware in GPU hardware to complete scheduling of various hardware resources of the GPU.
The Host driver is also called a Host driver, a Host driver or a Host driver, runs in a Host operating system (Host OS), and can be responsible for managing communication between GPU hardware on a Host and clients, and divides GPU resources into a plurality of virtual GPUs through a virtualization technology, wherein each virtual GPU corresponds to one client.
Wherein the Guest driver, also referred to as a Guest driver, a client driver, or a client driver, runs in a Guest operating system (Guest OS), may be responsible for managing virtual GPU hardware on the client and sending requests to the host to obtain access rights to GPU resources.
Among these, firmware may be a program written into erasable programmable read-only memory (Erasable Programmable Read Only Memory, EPROM) or charged erasable programmable read-only memory (Electrically Erasable Programmable Read Only Memory, EEPROM). Firmware refers to a device "driver" stored inside the device, through which an operating system can implement operation actions of a specific machine, such as an optical drive, recording, and the like, according to a standard device driver. The Host driver and the Guest driver can interact through an interface provided by Firmware.
As a PCIE Device, a GPU may generally determine a GPU model by using a Vendor ID and a Device ID of a PCIE, where a combination of the Vendor ID and the Device ID indicates a different GPU Device. The server operating system may load the Host driver for the GPU with the Vendor ID and the Device ID as the identifications.
In the conventional mode, when there are multiple GPUs of the same model on the same server, since the Vendor IDs and Device IDs of the GPUs are the same, the version information of the Host driver loaded for the GPUs is also the same. And when the Host driver is loaded, firmware with the same version information is also loaded for the GPUs.
Because of the specificity of the virtualized environment, the Host driver is mainly responsible for the management of software and hardware resources, and the real use of GPU resources is the Firmware and Guest driver. Guest drivers need to use various capabilities of GPU hardware through Firmware, so version information of Firmware has a large impact on the functionality, performance, and stability of the GPU. When Firmware with the same version information is loaded on multiple GPUs of the same server, the same version information must be used by the Guest driver matched with the Firmware, so that flexibility of Virtual GPU (vGPU) resource allocation is greatly limited, and utilization rate of resources is reduced.
Based on the above, the embodiment of the application provides a firmware loading method which is applied to a server. The method comprises the following steps: firstly, when a virtual machine is started, acquiring configuration information of a first drive of the virtual machine; then, determining version information of the first firmware according to the configuration information of the first driver; and finally traversing the running at least two GPUs, and determining to load the first firmware on the target GPU in the at least two GPUs based on the firmware information of the at least two GPUs and the version information of the first firmware.
The embodiment of the application also provides a firmware loading method which is applied to the virtual machine. The method comprises the following steps: when the virtual machine is started, sending configuration information of a first drive to a server; acquiring first indication information of a server, wherein the first indication information is used for indicating that a first firmware is successfully loaded on a target GPU (graphics processing unit) in at least two GPU (graphics processing units) running on the server; wherein the version information of the first firmware is associated with configuration information of the first drive.
Thus, the version information of the first firmware can be flexibly selected according to the configuration information of the first driver, and the first firmware is loaded on the target GPU. Therefore, when the configuration information of the first driver is different, the version information of the selected firmware is also different, and the firmware with different version information can be loaded on the plurality of GPU cards, so that the plurality of GPU cards can operate the first drivers with different configuration information, thereby not only improving the flexibility of resource allocation, but also improving the utilization rate of resources.
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application.
Fig. 1 is a flowchart of an alternative firmware loading method according to an embodiment of the present application, as shown in fig. 1, including S110 to S140:
s110, the virtual machine sends configuration information of the first drive to the server.
It should be noted that, when the virtual machine is started, the virtual machine may send the configuration information of the first driver to the server, so that the server may obtain the configuration information of the first driver.
Wherein the configuration information of the first drive may include a drive type and/or version information of the first drive.
The first driver may be a Guest driver, for example.
It should be understood that, in the embodiment of the present application, the configuration information of the first drive may include a drive type of the first drive, may also include version information of the first drive, and may even include other information of the first drive, which is not limited in the embodiment of the present application.
It should be further noted that, in the embodiment of the present 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.
In some embodiments, before the virtual machine sends the configuration information of the first drive to the server, the method may further include: the virtual machine acquires second indication information of the server, wherein the second indication information is used for indicating that the second drive of the server is loaded successfully.
The second drive may be a Host drive, for example.
Further, after the virtual machine obtains the second instruction information of the server, the method may further include: the virtual machine starts and loads the Guest driver.
Accordingly, in some embodiments, before the server obtains the configuration information of the first driver of the virtual machine, the method may further include: and determining that the second drive of the server is loaded successfully.
S120, the server determines version information of the first firmware according to the configuration information of the first driver.
The first Firmware may be Firmware, for example.
It should be understood that the configuration information of the first driver is matched with the version information of the first firmware, and after the server obtains the configuration information of the first driver, the server may obtain the version information of the first firmware according to the matching relationship between the configuration information of the first driver and the version information of the first firmware.
It should also be understood that the version information of the first firmware matches the configuration information of the first drive, and it is understood that the version information of the first firmware is associated with the configuration information of the first drive.
The server stores version information of a plurality of firmware. After the server acquires the configuration information of the first driver, the server may select version information of the first firmware matching the configuration information of the first driver from among the version information of the plurality of firmware.
When the server determines the version information of the first firmware, the version information of the first firmware is one of the version information of the plurality of firmware that can be supported by the server. That is, the first firmware is available to the server, which may load the first firmware on one of the GPUs that is running.
It should be noted that, the embodiment of the present application relates to three version information: version information of the first drive, version information of the second drive, and version information of the first firmware, wherein: the server can load the second drive according to the version information of the second drive, and acquire the version information of the first drive of the virtual machine after the second drive is successfully loaded; the server may then determine version information of the first firmware based on the version information of the first drive, the version information of the first drive matching the version information of the first firmware.
S130, traversing the running at least two GPUs by the server, and determining to load the first firmware on the target GPU in the at least two GPUs based on the firmware information of the at least two GPUs and the version information of the first firmware.
It should be noted that, the firmware information of the at least two GPUs may be whether the at least two GPUs load firmware, or may also be version information of the firmware on the GPU that has loaded the firmware, which is not limited in the embodiment of the present application.
Based on this, in an embodiment of the present application, the following two possible implementations are possible to determine that the first firmware is loaded on the target GPU.
In one possible implementation, the server determining, 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 of the at least two GPUs may include: 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 may determine that the first firmware has been loaded on the target GPU 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.
That is, the server determines, based on the firmware information of the at least two GPUs and the version information of the first firmware, whether the second firmware is loaded on the target GPU when the first firmware is loaded on the target GPU; secondly, under the condition that the target GPU loads the second firmware, judging 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 can be further determined whether the amount of remaining resources on the target GPU is greater than or equal to the amount of resources required by the first driver; finally, if the amount of remaining resources on the target GPU is greater than or equal to the amount of resources required by the first driver, it may be determined that the first firmware has been loaded on the target GPU.
Illustratively, it is assumed that there are two GPUs, denoted GPU1 and GPU2, respectively. Under the condition that the GPU1 is loaded with 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 is loaded on the GPU1 when the residual resource amount on the GPU1 is greater than or equal to the resource amount required by the first drive; alternatively, in the case where 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 may determine that the first firmware has been loaded on GPU2 when the amount of remaining resources on GPU2 is greater than or equal to the amount of resources required for the first drive.
It should be noted that, when the target GPU has loaded the second firmware, the server may determine that the first firmware has been loaded on the target GPU when the version information of the second firmware is the same as the version information of the first firmware, and the two conditions that the amount of remaining resources on the target GPU is greater than or equal to the amount of resources required for the first drive are satisfied at the same time.
It should be appreciated that the server may create the resources required by the first driver on the target GPU when the amount of resources remaining on the target GPU is greater than or equal to the amount of resources required by the first driver; further, when the version information of the second firmware is the same as the version information of the first firmware, the second firmware is loaded on the target GPU, or the first firmware is loaded on the target GPU.
The embodiment of the application provides a firmware loading method, if a target GPU (graphics processing unit) loads a second firmware, and version information of the second firmware is the same as that of a first firmware, a server can determine that the first firmware is loaded on the target GPU when the residual resource amount on the target GPU is greater than or equal to that required by a first driver. Thus, the flexibility of resource allocation can be improved, and the utilization rate of resources can be improved.
In another possible implementation manner, the determining, by the server, to load the first firmware on the target GPU of the at least two GPUs based on the firmware information of the at least two GPUs and the version information of the first firmware may include: if there is a target GPU with no firmware loaded in the at least two GPUs, the server may load the first firmware on the target GPU according to the version information of the first firmware.
That is, the server determines, based on the firmware information of the at least two GPUs and the version information of the first firmware, whether a target GPU that is not loaded with firmware exists in the at least two GPUs when the first firmware is loaded on the target GPU, and can load the first firmware on the target GPU according to the version information of the first firmware when the target GPU that is not loaded with firmware exists in the at least two GPUs.
Illustratively, it is assumed that there are two GPUs, denoted GPU1 and GPU2, respectively. Under the condition that the GPU1 is not loaded with the firmware, the first firmware can be loaded on the GPU1 according to the version information of the first firmware; alternatively, in the case where GPU2 is not loaded with firmware, the first firmware may be loaded on GPU2 according to version information of the first firmware.
It should be noted that, when the target GPU is not loaded with firmware, the amount of remaining resources on the target GPU may be considered to be greater than or equal to the amount of resources required by the first driver, and thus the server may create the resources required by the first driver on the target GPU.
The embodiment of the application provides a firmware loading method, wherein if at least two GPUs have target GPUs without firmware loading, a server can load first firmware on the target GPU according to version information of the first firmware. Thus, the flexibility of resource allocation can be improved, and the utilization rate of resources can be improved.
Based on the two possible implementations, when the server loads the first firmware on the target GPU in the at least two GPUs, the method may further include: the server creates the resources required for the first driver on the target GPU.
It should be noted that, when the server loads the first firmware on the target GPU of the 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, so that the server can create the resources required by the first driver on the target GPU.
S140, the server sends first indication information to the virtual machine.
Accordingly, the virtual machine may obtain the first indication information of the server.
The first indication information may be used to indicate that the first firmware is successfully loaded on the target GPU.
For example, after obtaining the first indication information, the virtual machine may learn that the first firmware is successfully loaded on the target GPU.
In some embodiments, the method may further comprise: the virtual machine may determine that the first drive loading was successful in response to the first indication information.
By the method, after the virtual machine knows that the first firmware is successfully loaded on the target GPU, the virtual machine can further know that the first driver is successfully loaded. At this time, the resources required for the first driver created on the target GPU can provide normal vGPU functionality.
It should be noted that, in the embodiment of the present application, when the number of virtual machines is more than two, at least two virtual machines have different version information of the respective loaded firmware.
That is, the configuration information of the first driver, which is transmitted to the server by each of the at least two virtual machines, is different from each other, so that the version information of the loaded firmware of each of the at least two virtual machines is also different from each other.
For example, it is assumed that there are two virtual machines, respectively denoted as virtual machine 1 and virtual machine 2, and since the configuration information of the first driver sent to the server by each of virtual machine 1 and virtual machine 2 is different, the version information of the loaded firmware by each of virtual machine 1 and virtual machine 2 is also different.
By the method, at least two virtual machines can be enabled to have different version information of the firmware loaded by each virtual machine, so that the flexibility of resource allocation is improved, and the utilization rate of resources is also improved.
It should be further noted that, in the embodiment of the present application, when the number of virtual machines is more than two, version information of each loading firmware of the more than two virtual machines may be the same.
That is, when the configuration information of the first driver that is transmitted to the server by each of the more than two virtual machines is the same, the version information of the loaded firmware of each of the more than two virtual machines is also the same.
The embodiment of the application provides a firmware loading method. Firstly, when a virtual machine is started, a server can acquire configuration information of a first drive of the virtual machine; then, the server may determine version information of the first firmware according to the configuration information of the first driver; finally, the server may traverse the running at least two GPUs, and determine to load the first firmware on the target GPU of the at least two GPUs based on the firmware information of the at least two GPUs and the version information of the first firmware. Thus, the server can flexibly select the version information of the first firmware according to the configuration information of the first driver, and load the first firmware on the target GPU. Therefore, when the configuration information of the first driver is different, the version information of the selected firmware is also different, and the firmware with different version information can be loaded on the plurality of GPU cards, so that the plurality of GPU cards can operate the first drivers with different configuration information, thereby not only improving the flexibility of resource allocation, but also improving the utilization rate of resources.
In an embodiment of the present application, if the first firmware fails to load on one GPU, the server may take the other GPU as the target GPU and execute one of the two possible implementations 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 is loaded on the target GPU when the residual resource amount on the target GPU is greater than or equal to the resource amount required by the first drive; (2) If there is a target GPU with no firmware loaded in the at least two GPUs, the server may load the first firmware on the target GPU according to the version information of the first firmware. If all GPUs on the server as target GPUs cannot execute the mode (1) and the mode (2), it can be determined that the first firmware fails to be loaded.
That is, based on S110 to S140, the server may determine that the first firmware is loaded successfully based on the firmware information of the at least two GPUs and the version information of the first firmware; accordingly, the server may also determine that the first firmware loading fails based on the firmware information of the at least two GPUs and the version information of the first firmware.
Fig. 2 is a second flowchart of an alternative firmware loading method according to an embodiment of the present application, as shown in fig. 2, the method may include S210 to S240:
S210, the virtual machine sends configuration information of a first drive to a server;
s220, the server determines version information of the first firmware according to the configuration information of the first driver;
s230, traversing the running at least two GPUs by the server, and determining that the first firmware fails to be loaded based on firmware information of the at least two GPUs and version information of the first firmware;
s240, the server sends third indication information to the virtual machine.
The third indication information may be used to indicate that the first firmware fails to be loaded.
In some embodiments, the server traversing the running at least two GPUs, determining that the first firmware loading failed based on the firmware information of the at least two GPUs and the version information of the first firmware may include: when the server traverses the at least two GPUs running, if the at least two GPUs have loaded the second firmware, the server may determine that the loading of the first firmware fails when the version information of the second firmware is different from the version information of the first firmware and/or the amount of remaining resources on the at least two GPUs is less than the amount of resources required by the first driver.
That is, when at least two GPUs have loaded the second firmware, the server may determine that the first firmware fails to be loaded when at least one of two conditions that version information of the second firmware is different from version information of the first firmware and that the amount of remaining resources on the at least two GPUs are smaller than the amount of resources required for the first drive is satisfied.
Illustratively, the at least two GPUs include a target GPU. When the target GPU has loaded the second firmware, if the amount of remaining resources on the target GPU is less than the amount of resources required by the first driver, the amount of remaining resources on the target GPU is insufficient to create the resources required by the first driver on the target GPU, thereby resulting in failure to load the first firmware on the target GPU and failure to load the first firmware.
Illustratively, the at least two GPUs include a 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, the target GPU cannot load other firmware different from the second firmware, thereby causing the loading failure of the first firmware.
After the server sends the third indication information to the virtual machine, the virtual machine may obtain the third indication information accordingly.
For example, after obtaining the third indication information, the virtual machine may learn that the first firmware fails to be loaded.
In some embodiments, the method may further comprise: and responding to the third indication information, and determining that the first drive fails to be loaded.
By the method, after the virtual machine knows that the first firmware fails to be loaded, the virtual machine can further know that the first drive fails to be loaded, so that normal vGPU functions cannot be provided.
Further, after knowing that the first driver fails to be loaded, if there is still a need to load the first driver, the virtual machine may trigger scheduling again, and if there is a GPU that meets the resource requirement of the vGPU at this time, the resource (vGPU resource) required by the first driver may be created on the GPU, so that the first firmware is further loaded on the GPU. That is, if the virtual machine still has a need to load the first driver, the configuration information of the first driver may be continuously sent to the server again, and the related processes in fig. 1 and fig. 2 are executed again until the first driver is loaded successfully.
The embodiment of the application provides a firmware loading method. Firstly, when a virtual machine is started, a server can acquire configuration information of a first drive of the virtual machine; secondly, the server can determine version information of the first firmware according to the configuration information of the first driver; then, the server may traverse the running at least two GPUs, and determine that the first firmware loading fails based on firmware information of the at least two GPUs and version information of the first firmware; finally, the server sends third indication information to the virtual machine, wherein the third indication information can be used for indicating that the first firmware fails to be loaded. Thus, the virtual machine can determine that the first firmware cannot be loaded on the GPU of the server, and at this time, the virtual machine can choose to load the first firmware on the GPUs of other servers, or the virtual machine can choose to send the first driver of other configuration information to the server, so that other firmware can be loaded on the GPUs of the server, thereby not only improving the flexibility of resource allocation, but also improving the utilization rate of resources.
The firmware loading method provided by the above embodiment is described in detail below in connection with a specific application scenario.
The embodiment of the application provides a method for loading Firmware with different version information for each GPU in a multi-GPU card environment, so that a plurality of GPU cards on one server can run Guest drivers (namely the first drivers) with different configuration information, the flexibility of deployment in a cloud environment is improved, and the utilization efficiency of resources is also improved.
In the embodiment of the application, the loading of Firmware can be deferred until the loading of the Guest driver. And checking the configuration information of the Guest driver, selecting version information of a matched Firmware according to the configuration information of the Guest driver, and loading the Firmware with the version information on the GPU. When the virtual machine starts up a Guest driver attempting to load another configuration information, the server selects a Firmware GPU that matches the Guest driver to create vGPU resources (i.e., resources required by the first driver) and provides a running environment. If there is no Firmware GPU that matches the Guest driver and there is a new GPU (a GPU that does not load Firmware), then Firmware that matches the Guest driver is loaded on the new GPU.
In the related art, the Host driver loads Firmware for the GPU synchronously during loading. Compared with the traditional implementation mode, the technical scheme provided by the embodiment of the application does not load Firmware for the GPU when the Host is loaded. When the virtual machine starts the loading of the Guest driver, the Guest driver initialization stage is entered at this time. Specifically, the virtual machine communicates with the server first, the server may obtain the configuration information of the Guest driver, and select version information of the Firmware supported based on the configuration information of the Guest driver, so as to load the Firmware with the version information for the GPU. At this time, firmware is loaded on the GPU which uses the vGPU resource, and other GPUs which do not use the vGPU resource are still in a state of not loading Firmware, and the Firmware is not loaded again until the vGPU resource is used. By the mode, loading of Firmware is postponed from a Host drive initialization stage to a Guest drive initialization stage, so that version information of Firmware can be flexibly selected according to configuration information of Guest drive, firmware of different version information can be further operated between different GPU cards on the same server, and flexibility of GPU resource allocation is effectively improved.
Fig. 3 is a detailed flowchart of an alternative firmware loading method according to an embodiment of the present application. Before the detailed flow, on one hand, ensuring that a Host driver on a server is correctly installed and operated; on the other hand, ensuring that a plurality of GPUs on the server can all run vGPU resources; in yet another aspect, it is ensured that Firmware files stored on the server with support run on hardware.
As shown in fig. 3, the firmware loading method may be applied to a server, the firmware loading method may also be applied to a virtual machine, the server may run the virtual machine, the virtual machine may run a Guest driver, and the server and the GPU may be connected through a hardware interface. The detailed flow may include S301 to S314:
s301, starting a Guest drive by the virtual machine.
Illustratively, the virtual machine initiates a Guest driven load.
S302, the virtual machine sends the Guest drive type and version information to the server.
Accordingly, the server may acquire the Guest driver type and version information.
S303, the server selects version information of one supported Firmware according to the Guest driving type and the version information.
S304, traversing all the current GPUs by the server, and checking the running condition of Firmware on each GPU.
S305, the server determines whether Firmware running the same version information exists on the GPU and whether residual resources exist on the GPU.
If the server determines that there is Firmware running the same as the version information selected in S303 on the GPU and there are remaining resources on the GPU, executing S306 to S307; otherwise, S308 is performed.
S306, the server creates vGPU resources on the GPU.
The server creates corresponding vGPU resources on the GPU selected in S305.
S307, the server sends the Firmware to the virtual machine, and the Firmware is successfully loaded.
The server notifies the virtual machine of the Firmware loading success, and performs S312.
S308, the server determines whether the GPU which is not loaded with Firmware exists.
If the server determines that there is a GPU not loaded with Firmware, executing S309-S310; otherwise, S311 is performed.
S309, the server loads Firmware with the version information on the GPU and creates vGPU resources on the GPU.
The server loads the Firmware selected in S303 on the GPU selected in S308 and creates the corresponding vGPU resource on the GPU.
S310, the server sends Firmware to the virtual machine, and loading is successful.
The server notifies the virtual machine of the Firmware loading success, and performs S312.
S311, the server sends Firmware loading failure to the virtual machine.
It should be noted that, the server sends a Firmware loading failure to the virtual machine, which indicates that Firmware is loaded on all the GPUs currently, and neither Firmware with the same version information as the version information selected in S303 is running, and/or that no resource remains on all the GPUs currently.
The server notifies the virtual machine of the Firmware loading failure, and performs S312.
S312, the virtual machine checks whether the Firmware is loaded successfully.
The virtual machine obtains a loading result of the Firmware, and determines whether the Firmware is loaded successfully or not according to the loading result of the Firmware. If the Firmware loading is successful, then S313 is executed; otherwise, if the Firmware loading fails, S314 is executed.
S313, the Firmware is loaded successfully, and the VGPU operates normally.
It should be noted that, firmware is successfully loaded, and the Guest driver is also successfully loaded, so that the vGPU function can be normally provided.
S314, the Firmware fails to load, and the VGPU cannot operate.
It should be noted that Firmware fails to load, meaning that the Guest driver fails to load as well, and cannot normally provide vGPU functions.
The embodiment of the application provides a firmware loading method. In a multi-GPU card environment, version information of Firmware can be flexibly selected according to configuration information (such as a driving type and version information) of a Guest driver, and Firmware of different version information can be loaded for different GPUs so as to adapt to different Guest drivers. By the method, on one hand, better performance and stability can be provided for the Guest; on the other hand, the flexibility of resource allocation and the utilization rate of resources in the cloud environment can be fully improved.
The preferred embodiments of the present application have been described in detail above with reference to the accompanying drawings, but the present application is not limited to the specific details of the above embodiments, and various simple modifications can be made to the technical solution of the present application within the scope of the technical concept of the present application, and all the simple modifications belong to the protection scope of the present application. For example, the specific features described in the above embodiments may be combined in any suitable manner, and in order to avoid unnecessary repetition, various possible combinations are not described further. As another example, any combination of the various embodiments of the present application may be made without departing from the spirit of the present application, which should also be regarded as the disclosure of the present application. For example, on the premise of no conflict, the embodiments described in the present application and/or technical features in the embodiments may be combined with any other embodiments in the prior art, and the technical solutions obtained after combination should also fall into the protection scope of the present application.
It should be understood that, in the various method embodiments of the present application, the sequence number of each process described above does not mean that the execution sequence of each process should be determined by its functions and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.
Based on the same inventive concept as the foregoing embodiments, fig. 4 is a schematic diagram of a composition structure of an optional server according to an embodiment of the present application, as shown in fig. 4, a server 400 may include a first obtaining unit 410 and a first determining unit 420, where:
a first obtaining unit 410, configured to obtain configuration information of a first driver of the virtual machine when the virtual machine is started;
a first determining unit 420, configured to determine version information of the first firmware according to the configuration information of the first driver; and traversing the running at least two graphics processor GPUs, and determining to load the first firmware on a target GPU of the at least two GPUs based on the firmware information of the at least two GPUs and the version information of the first firmware.
In some embodiments of the present application, the first determining unit 420 is further configured to determine that the first firmware is loaded on the target GPU 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 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.
In some embodiments of the present application, the first determining unit 420 is further configured to determine, if there is a target GPU that is not loaded with firmware in the at least two GPUs, to load the first firmware on the target GPU according to the version information of the first firmware.
In some embodiments of the present application, as shown in fig. 4, the server 400 may further include a creation unit 430, wherein:
and a creating unit 430, configured to create, on the target GPU, the resources required by the first driver.
In some embodiments of the present application, as shown in fig. 4, the server 400 may further include a first transmitting unit 440, wherein:
the first sending unit 440 is configured to send first indication information to the virtual machine, where the first indication information is used to indicate that the first firmware is successfully loaded on the target GPU.
In some embodiments of the present application, the first determining unit 420 is further configured to determine that the second driver of the server is loaded successfully.
In some embodiments of the present application, when the number of virtual machines is more than two, there is at least two virtual machines each loading version information of firmware that is different.
In some embodiments of the application, the configuration information of the first drive includes drive type and/or version information of the first drive.
The embodiment of the application provides a server. Firstly, when a virtual machine is started, a server can acquire configuration information of a first drive of the virtual machine; then, the server may determine version information of the first firmware according to the configuration information of the first driver; finally, the server may traverse the running at least two GPUs, and determine to load the first firmware on the target GPU of the at least two GPUs based on the firmware information of the at least two GPUs and the version information of the first firmware. Thus, the server can flexibly select the version information of the first firmware according to the configuration information of the first driver, and load the first firmware on the target GPU. Therefore, when the configuration information of the first driver is different, the version information of the selected firmware is also different, and the firmware with different version information can be loaded on the plurality of GPU cards, so that the plurality of GPU cards can operate the first drivers with different configuration information, thereby not only improving the flexibility of resource allocation, but also improving the utilization rate of resources.
Those skilled in the art will appreciate that the above description of the server of the embodiments of the present application may be understood with reference to the description of the firmware loading method of the embodiments of the present application.
Based on the same inventive concept as the foregoing embodiments, fig. 5 is a schematic diagram of a composition structure of an optional virtual machine according to an embodiment of the present application, as shown in fig. 5, a virtual machine 500 may include a second sending unit 510 and a second obtaining unit 520, where:
a second sending unit 510, configured to send configuration information of the first driver to the server when the virtual machine is started;
the second obtaining unit 520 is configured to obtain first indication information of the server, where the first indication information is used to indicate that the first firmware is successfully loaded on a target GPU of the at least two graphics processor GPUs running on the server; wherein the version information of the first firmware is associated with configuration information of the first drive.
In some embodiments of the present application, as shown in fig. 5, the virtual machine 500 may further include a second determining unit 530, wherein:
the second determining unit 530 is configured to determine that the first drive loading is successful in response to the first indication information.
In some embodiments of the present application, the second obtaining unit 520 is configured to obtain second indication information of the server, where the second indication information is used to indicate that the second drive of the server is loaded successfully.
In some embodiments of the present application, when the number of virtual machines is more than two, there is at least two virtual machines each loading version information of firmware that is different.
In some embodiments of the application, the configuration information of the first drive includes drive type and/or version information of the first drive.
The embodiment of the application provides a virtual machine. When the virtual machine is started, sending configuration information of a first drive to a server; acquiring first indication information of a server, wherein the first indication information is used for indicating that a first firmware is successfully loaded on a target GPU (graphics processing unit) in at least two GPU (graphics processing units) running on the server; wherein the version information of the first firmware is associated with configuration information of the first drive. Thus, when the configuration information of the first drive sent by the virtual machine to the server is different, if the first firmware is loaded successfully, the version information of the first firmware associated with the configuration information of the first drive is also different. Therefore, the first firmware of different version information is loaded on the GPU cards, so that the GPU cards can operate the first drivers of different configuration information, the flexibility of resource allocation is improved, and the utilization rate of resources is also improved.
Those skilled in the art will appreciate that the above description of a virtual machine according to an embodiment of the present application may be understood with reference to the description of a firmware loading method according to an embodiment of the present application.
Fig. 6 is a schematic structural diagram of an electronic device 600 according to an embodiment of the present application. As shown in fig. 6, the electronic device 600 includes a processor 610 and a memory 620, the memory 620 may store a computer program, and the processor 610 may call and run the computer program from the memory 620 to implement the method in the embodiment of the present application.
The memory 620 may be a separate device from the processor 610 or may be integrated into the processor 610.
In some embodiments of the present application, as shown in fig. 6, the electronic device 600 may further include a transceiver 630, and the processor 610 may control the transceiver 630 to communicate with other devices, and in particular, may transmit information or data to other devices, or receive information or data transmitted by other devices.
The transceiver 630 may include a transmitter and a receiver, among others. Transceiver 630 may further include antennas, the number of which may be one or more.
In some embodiments of the present application, the present application also provides a composition of another electronic device, where the electronic device may include the server 400 of any of the foregoing embodiments; alternatively, an electronic device may comprise a virtual machine 500 as described in any of the preceding embodiments.
Fig. 7 is a schematic structural diagram of a chip according to an embodiment of the present application. As shown in fig. 7, a chip 700 includes a processor 710, and the processor 710 may call and run a computer program from a memory to implement the method in the embodiment of the present application.
In some embodiments of the application, as shown in FIG. 7, chip 700 may also include memory 720. Wherein the processor 710 may call and run a computer program from the memory 720 to implement the method in an embodiment of the application.
Wherein the memory 720 may be a separate device from the processor 710 or may be integrated into the processor 710.
In some embodiments of the application, the chip 700 may also include an input interface 730. The processor 710 may control the input interface 730 to communicate with other devices or chips, and in particular, may obtain information or data sent by other devices or chips.
In some embodiments of the application, the chip 700 may further include an output interface 740. The processor 710 may control the output interface 740 to communicate with other devices or chips, and in particular, may output information or data to other devices or chips.
In some embodiments of the present application, the chip may be applied to the server in the embodiments of the present application, and for brevity, will not be described herein.
In some embodiments of the present application, the chip may be applied to a virtual machine in the embodiments of the present application, and for brevity, will not be described herein.
It should be understood that the chips referred to in the embodiments of the present application may also be referred to as system-on-chip chips, or the like.
Fig. 8 is a schematic block diagram of a communication system 800 provided by an embodiment of the present application. As shown in fig. 8, the communication system 800 includes a server 810 and a virtual machine 820.
Wherein the server 810 may be used to implement the corresponding functions implemented by the server in the above-described method, and the virtual machine 820 may be used to implement the corresponding functions implemented by the virtual machine in the above-described method. For brevity, the description is omitted here.
It will be appreciated that the processor of an embodiment of the application may be an integrated circuit chip having information processing capabilities. In implementation, the steps of the above method embodiments may be implemented by integrated logic circuits of hardware in a processor or instructions in software form. The processor may be a general purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), an off-the-shelf programmable gate array (Field Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be embodied directly in the execution of a hardware decoding processor, or in the execution of a combination of hardware and software modules in a decoding processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory, and the processor reads the information in the memory and, in combination with its hardware, performs the steps of the above method.
It will also be appreciated that the memory in embodiments of the application can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable EPROM (EEPROM), or a flash Memory. The volatile memory may be random access memory (Random Access Memory, RAM) which acts as an external cache. By way of example, and not limitation, many forms of RAM are available, such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (Double Data Rate SDRAM), enhanced SDRAM (ESDRAM), synchronous DRAM (SLDRAM), and Direct RAM (DR RAM). It should be noted that the memory described herein is intended to comprise, without being limited to, these and any other suitable types of memory.
It is further understood that the above memory is exemplary but not limiting, and for example, the memory in the embodiments of the present application may be Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), direct Rambus RAM (DR RAM), and the like. That is, the memory in embodiments of the present application is intended to comprise, without being limited to, these and any other suitable types of memory.
The embodiment of the application also provides a computer readable storage medium for storing a computer program.
In some embodiments of the present application, the computer readable storage medium may be applied to a server in an embodiment of the present application, and when the computer program is executed by at least one processor, the corresponding flow implemented by the server in each method in the embodiment of the present application is implemented, which is not described herein for brevity.
In some embodiments of the present application, the computer readable storage medium may be applied to the virtual machine in the embodiments of the present application, and when the computer program is executed by at least one processor, the corresponding flow implemented by the virtual machine in each method in the embodiments of the present application is implemented, which is not described herein for brevity.
The embodiment of the application also provides a computer program product comprising computer program instructions.
In some embodiments of the present application, the computer program product may be applied to a server in the embodiments of the present application, and the computer program instructions cause a computer to execute corresponding processes implemented by the server in the methods in the embodiments of the present application, which are not described herein for brevity.
In some embodiments of the present application, the computer program product may be applied to a virtual machine in the embodiments of the present application, and the computer program instructions cause the computer to execute corresponding processes implemented by the virtual machine in the methods in the embodiments of the present application, which are not described herein for brevity.
The embodiment of the application also provides a computer program.
In some embodiments of the present application, the computer program may be applied to a server in the embodiments of the present application, and when the computer program runs on a computer, the computer is caused to execute corresponding processes implemented by the server in the methods in the embodiments of the present application, which are not described herein for brevity.
In some embodiments of the present application, the computer program may be applied to a virtual machine in the embodiments of the present application, and when the computer program runs on a computer, the computer is caused to execute corresponding processes implemented by the virtual machine in each method in the embodiments of the present application, which are not described herein for brevity.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the apparatus and units described above may refer to corresponding procedures in the foregoing method embodiments, which are not described herein again.
In the several embodiments provided by the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.
The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
It should be noted that, in the present application, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The foregoing embodiment numbers of the present application are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments.
The methods disclosed in the method embodiments provided by the application can be arbitrarily combined under the condition of no conflict to obtain a new method embodiment.
The features disclosed in the several product embodiments provided by the application can be combined arbitrarily under the condition of no conflict to obtain new product embodiments.
The features disclosed in the embodiments of the method or the apparatus provided by the application can be arbitrarily combined without conflict to obtain new embodiments of the method or the apparatus.
The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (18)

1. A firmware loading method, applied to a server, the method comprising:
when a virtual machine is started, acquiring configuration information of a first drive of the virtual machine;
determining version information of the first firmware according to the configuration information of the first driver;
traversing the running at least two graphics processor GPUs, and determining to load the first firmware on a target GPU of the at least two GPUs based on firmware information of the at least two GPUs and version information of the first firmware.
2. The method of claim 1, wherein the determining to load the first firmware on the target GPU of the at least two GPUs based on the firmware information of the at least two GPUs and the version information of the first firmware comprises:
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, determining that the first firmware is loaded on the target GPU when the residual resource amount on the target GPU is greater than or equal to the resource amount required by the first driver.
3. The method of claim 1, wherein the determining to load the first firmware on the target GPU of the at least two GPUs based on the firmware information of the at least two GPUs and the version information of the first firmware comprises:
and if the target GPU which is not loaded with the firmware exists in the at least two GPUs, loading the first firmware on the target GPU according to the version information of the first firmware.
4. A method according to any one of claims 1 to 3, wherein when loading the first firmware on a target GPU of the at least two GPUs, the method further comprises:
resources required by the first driver are created on the target GPU.
5. A method according to any one of claims 1 to 3, further comprising:
and sending first indication information to the virtual machine, wherein the first indication information is used for indicating that the first firmware is successfully loaded on the target GPU.
6. A method according to any one of claims 1 to 3, wherein prior to obtaining configuration information of the first drive of the virtual machine, the method further comprises:
and determining that the second drive of the server is loaded successfully.
7. The method of claim 1, wherein when the number of virtual machines is more than two, at least two virtual machines have different version information of each loaded firmware.
8. The method of claim 1, wherein the configuration information of the first drive includes drive type and/or version information of the first drive.
9. A firmware loading method, applied to a virtual machine, the method comprising:
when the virtual machine is started, sending configuration information of a first drive to a server;
acquiring first indication information of the server, wherein the first indication information is used for indicating that a first firmware is successfully loaded on a target GPU (graphics processing unit) in at least two GPU (graphics processing units) running on the server; wherein version information of the first firmware is associated with configuration information of the first driver.
10. The method according to claim 9, wherein the method further comprises:
And responding to the first indication information, and determining that the first drive is loaded successfully.
11. The method of claim 9 or 10, wherein prior to sending the configuration information of the first drive to the server, the method further comprises:
and acquiring second indication information of the server, wherein the second indication information is used for indicating that the second drive of the server is loaded successfully.
12. The method according to any one of claims 9 to 11, wherein when the number of virtual machines is more than two, there are at least two virtual machines each having different version information of the loaded firmware.
13. The method according to any of claims 9 to 12, wherein the configuration information of the first drive comprises drive type and/or version information of the first drive.
14. A server, comprising a first acquisition unit and a first determination unit, wherein:
the first obtaining unit is used for obtaining configuration information of a first drive of the virtual machine when the virtual machine is started;
the first determining unit is configured to determine version information of a first firmware according to configuration information of the first driver;
The first determining unit is further configured to traverse the running at least two GPUs, and determine to load the first firmware on a target GPU of the at least two GPUs based on firmware information of the at least two GPUs and version information of the first firmware.
15. The virtual machine is characterized by comprising a second sending unit and a second obtaining unit, wherein:
the second sending unit is used for sending configuration information of the first drive to the server when the virtual machine is started;
the second obtaining unit is configured to obtain first indication information of the server, where the first indication information is used to indicate that a first firmware is successfully loaded on a target GPU in at least two graphics processor GPUs running on the server; wherein version information of the first firmware is associated with configuration information of the first driver.
16. An electronic device, comprising: a processor and a memory for storing a computer program, the processor for invoking and running the computer program stored in the memory, performing the method of any of claims 1 to 8; alternatively, the method of any one of claims 9 to 13 is performed.
17. A chip, comprising: a processor for calling and running a computer program from a memory, causing a device on which the chip is mounted to perform the method of any one of claims 1 to 8; alternatively, the method of any one of claims 9 to 13 is performed.
18. A computer-readable storage medium, characterized in that the computer storage medium stores a computer program which, when executed by at least one processor, implements the method of any one of claims 1 to 8; alternatively, the method of any one of claims 9 to 13 is implemented.
CN202310813100.5A 2023-07-04 2023-07-04 Firmware loading method, server, virtual machine, device, chip and storage medium Pending CN116880921A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310813100.5A CN116880921A (en) 2023-07-04 2023-07-04 Firmware loading method, server, virtual machine, device, chip and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310813100.5A CN116880921A (en) 2023-07-04 2023-07-04 Firmware loading method, server, virtual machine, device, chip and storage medium

Publications (1)

Publication Number Publication Date
CN116880921A true CN116880921A (en) 2023-10-13

Family

ID=88262773

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310813100.5A Pending CN116880921A (en) 2023-07-04 2023-07-04 Firmware loading method, server, virtual machine, device, chip and storage medium

Country Status (1)

Country Link
CN (1) CN116880921A (en)

Similar Documents

Publication Publication Date Title
CN106970810B (en) Firmware burning method and system
US11188347B2 (en) Virtual function driver loading method and server using global and local identifiers corresponding to locations of the virtual functions
US11853767B2 (en) Inter-core data processing method, system on chip and electronic device
CN114201268B (en) Data processing method, device and equipment and readable storage medium
CN112765084B (en) Computer device, virtualization acceleration device, data transmission method, and storage medium
CN104731635A (en) Virtual machine access control method and virtual machine access control system
CN116028455A (en) Data processing method and device, storage medium and electronic equipment
CN111078353A (en) Operation method of storage equipment and physical server
CN112015476B (en) Display card driving method and device, electronic equipment and storage medium
CN108984270B (en) Memory allocation method and device for virtual machine
US20200249986A1 (en) Methods and apparatus for virtual machine rebalancing
CN114780465A (en) Method and device for creating sharable remote direct data access link
CN107797843B (en) Method and device for enhancing function of container
CN110990116B (en) Method, device and system for transmitting data between intelligent network card and virtual machine
CN116880921A (en) Firmware loading method, server, virtual machine, device, chip and storage medium
CN113064655B (en) BIOS network starting method and device and computer readable storage medium
CN114035901B (en) Method and device for constructing container for running process and electronic equipment
CN115883022A (en) DMA (direct memory access) transmission control method and device, electronic equipment and readable storage medium
CN112860595B (en) PCI (peripheral component interconnect express) equipment or PCIE (peripheral component interconnect express) equipment, data access method and related assembly
CN111666579B (en) Computer device, access control method thereof and computer readable medium
CN110704163A (en) Server and virtual storage method and device thereof
CN116578390B (en) Communication method, server, graphic processor, equipment and chip for driving
CN110990122A (en) Virtual machine migration method and device
EP4307131A1 (en) Flash memory access method and apparatus
WO2022199560A1 (en) Memory management method and device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination