CN116578390B

CN116578390B - Communication method, server, graphic processor, equipment and chip for driving

Info

Publication number: CN116578390B
Application number: CN202310808945.5A
Authority: CN
Inventors: 请求不公布姓名
Original assignee: Moore Threads Technology Co Ltd
Current assignee: Moore Threads Technology Co Ltd
Priority date: 2023-07-04
Filing date: 2023-07-04
Publication date: 2023-09-12
Anticipated expiration: 2043-07-04
Also published as: CN116578390A

Abstract

The embodiment of the application provides a driving communication method, a server, a graphic processor, equipment and a chip, wherein the method comprises the following steps: in the process of starting the virtual machine, a first communication protocol is adopted, and first configuration information of the virtual machine, which is sent by a second drive, is stored into a first video memory through a first drive; the configuration information stored in the first video memory is used for version negotiation between the first driver and the firmware; and adopting a second communication protocol, and writing the virtual machine online notification into a second video memory through the first driver to realize the communication between the first driver and the firmware. Thus, decoupling between the drivers can be realized, and reliability and stability between the drivers are improved.

Description

Communication method, server, graphic processor, equipment and chip for driving

Technical Field

The present application relates to the field of computer technologies, and in particular, to a driving communication method, a server, a graphics processor, a device, and a chip.

Background

In the context of graphics processor (Graphics Processing Unit, GPU) virtualization, both Host (Host) and client (Guest) systems each need to run drivers, and each driver needs to communicate with Firmware (Firmware) in the GPU hardware to complete the scheduling of various hardware resources of the GPU.

In the related art, the Guest driver is responsible for maintaining a protocol for communication between the driver and the firmware, and the Host driver needs to strictly adhere to the communication protocol maintained by the Guest driver. In the actual running process, the Host driver is responsible for loading the firmware and completing initialization. When the Guest driver is loaded, the same communication protocol as the Host driver is required to be adopted to communicate with the firmware so as to finish the issuing of the GPU task.

Since both the Host driver and the Guest driver need to communicate with the firmware, the Guest driver, the Host driver, and the firmware need to use the same communication protocol. Therefore, the Host driver, the Guest driver and the firmware have strong coupling, so that the reliability and stability among the drivers are poor.

Disclosure of Invention

The embodiment of the application provides a communication method, a server, a graphic processor, equipment and a chip for driving, which can improve the decoupling between driving programs and improve the reliability and stability between the driving programs.

The technical scheme of the application is realized as follows:

in a first aspect, an embodiment of the present application provides a method for communication between a driver and a server, where the server runs a first driver and a virtual machine, and the virtual machine runs a second driver, and the method includes:

In the process of starting the virtual machine, a first communication protocol is adopted, and first configuration information of the virtual machine, which is sent by a second drive, is stored into a first video memory through a first drive; the configuration information stored in the first video memory is used for version negotiation between the first driver and the firmware;

and adopting a second communication protocol, and writing the virtual machine online notification corresponding to the virtual machine into a second video memory through the first driver to realize the communication between the first driver and the firmware.

In a second aspect, an embodiment of the present application provides a communication method of a driver, applied to a graphics processor, where the graphics processor runs firmware; the method comprises the following steps:

in the process of starting the virtual machine, a second communication protocol is adopted, and first configuration information of a second driver is obtained through firmware in response to a virtual machine online notification written in a second video memory by the first driver;

based on the first configuration information, a third communication protocol is adopted to send resources of virtual equipment created for the virtual machine to the server so as to realize virtual tasks; the first configuration information is stored in a first video memory adopting a first communication protocol by a first driver; the first configuration information is sent to the first drive by the second drive; the configuration information stored in the first video memory is used for version negotiation between the first driver and the firmware.

In a third aspect, an embodiment of the present application provides a server, including: a driving unit; the driving unit is used for storing first configuration information of the virtual machine, which is sent by the second drive, into the first video memory through the first drive by adopting a first communication protocol in the process of starting the virtual machine; the configuration information stored in the first video memory is used for version negotiation of the first driver and the firmware by adopting a first communication protocol; and writing the virtual machine online notification into a second video memory by adopting a second communication protocol, so as to realize the communication between the first driver and the firmware.

In a fourth aspect, an embodiment of the present application provides a graphics processor, including: a firmware unit; the firmware unit is used for responding to the virtual machine on-line notification written in the second video memory by the first driver by adopting a second communication protocol in the process of starting the virtual machine, and acquiring first configuration information of the second driver; based on the first configuration information, a third communication protocol is adopted to send resources of virtual equipment created for the virtual machine to the server so as to realize virtual tasks; the first configuration information is stored in a first video memory adopting a first communication protocol by a first driver; the first configuration information is sent to the first drive by the second drive; the first video memory is used for version negotiation between the first drive and the firmware.

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 and executing the driving communication method in the first aspect or the second aspect.

In a sixth aspect, an embodiment of the present application provides a chip for implementing the driving communication 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 communication method of the drive 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 which, when executed by at least one processor, implements the driven communication method of the first or second aspect.

In an eighth aspect, an embodiment of the present application provides a computer program product comprising computer program instructions for causing a computer to perform the driven communication method of the first or 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 driven communication method of the first or second aspect described above.

The embodiment of the application provides a driving communication method, a server, a graphic processor, equipment and a chip, wherein the method can comprise the following steps: firstly, in the process of starting a virtual machine, a first communication protocol is adopted, and first configuration information of the virtual machine, which is sent by a second drive, is stored into a first video memory through a first drive; and then, adopting a second communication protocol, and writing the virtual machine online notification into a second video memory through the first driver to realize the communication between the first driver and the firmware. Because the configuration information stored in the first video memory is used for version negotiation between the first driver and the firmware by adopting the first communication protocol, the firmware can acquire the related configuration information of the first driver and the second driver through the first video memory, the firmware does not need to acquire the configuration information of the second driver through the first driver, and the firmware directly adopts the first communication protocol to read the configuration information from the first video memory, so that the coupling between the first driver and the second driver is reduced, the decoupling between the first driver and the second driver is realized, and the reliability and the stability between the drivers are improved.

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 schematic diagram of driver communication for a non-virtualized scenario in an alternative related art according to an embodiment of the present application;

FIG. 2 is a schematic diagram of driver communication of a virtualized scenario in an alternative related art according to an embodiment of the present application;

FIG. 3 is a schematic flow chart of an alternative driven communication method according to an embodiment of the present application;

FIG. 4 is a second flow chart of an alternative driven communication method according to an embodiment of the present application;

FIG. 5 is a third flow chart of an alternative driven communication method according to an embodiment of the present application;

FIG. 6 is a schematic flow chart of an alternative driven communication method according to an embodiment of the present application;

fig. 7 is a schematic flow chart of an alternative driven communication method according to an embodiment of the present application;

FIG. 8 is a schematic diagram of driver communication for an alternative virtualized scenario in accordance with an embodiment of the present application;

FIG. 9 is a flowchart of an alternative driven communication method according to an embodiment of the present application;

fig. 10 is a schematic diagram of an optional server according to an embodiment of the present application;

FIG. 11 is a schematic diagram of an alternative graphics processor according to an embodiment of the present application;

fig. 12 is a schematic structural diagram of an electronic device according to an embodiment of the present application;

FIG. 13 is a schematic block diagram of a chip according to an embodiment of the present application;

fig. 14 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.

When a driver (Host driver, guest driver) communicates with firmware, both parties of communication are required to use the same (or version compatible) data format (hereinafter referred to as a communication protocol). This is because, in the GPU virtualization scenario, the Guest driver and the firmware communicate through the Host driver, the Guest driver needs to send a request to the Host driver, the Host driver needs to send a request to the firmware, and the firmware needs to allocate a computing task to the GPU hardware, so if the communication protocols of the three are different, problems such as communication errors, computing task failure, and the like are caused.

That is, the communication protocol and data format between the Guest driver and the Host driver are often unstable and may change with the change of the driver version.

In the traditional implementation method, the Guest driver is responsible for maintaining a protocol for communication between the driver and the firmware, and the Host driver strictly adheres to the communication protocol maintained by the Guest driver. In the actual running process, the Host is responsible for loading the firmware and completing the initialization of the firmware, and when the Guest drives the loading, the Host communicates with the firmware by adopting the same communication protocol so as to complete the issuing of the GPU task. Since both Host and Guest need to communicate with firmware, the communication protocols used by the three in this mode are exactly the same. Therefore, in the prior art, there is strong coupling between the Host driver, the Guest driver and the firmware, and the communication protocol versions of the Host driver, the Guest driver and the firmware must be completely consistent. If the two types of the data are inconsistent, the loading failure of the firmware, the loading failure of the Host driver, the black screen of the Guest and the like can be caused. Is very unfriendly to drive upgrades.

For example, in a GPU virtualization scenario, when a Guest driven version changes, new features, functions, or known problems may be introduced, but at the same time some compatibility issues may be introduced. If the Host driver and the firmware version are not compatible with the Guest driver version, the Guest driver may not access the GPU resource correctly, so that the GPU application may not work normally, and problems such as black screen may occur.

The following describes a communication method between a Guest driver (second driver), a Host driver (first driver), and Firmware in the related art.

1. Related art 1:

fig. 1 is a schematic diagram of driver communication in a non-virtualized scenario in an alternative related art according to an embodiment of the present application, where, as shown in fig. 1, the non-virtualized driver and firmware share a Local Memory (Local Memory), and the non-virtualized driver and firmware communicate using a agreed communication protocol. In a non-virtualized environment, since each host runs only one non-virtualized driver, firmware and non-virtualized drivers are in one-to-one relationship. Under the scene, the non-virtualized driver and the Firmware adopt a mode of sharing memory for communication due to simple structure.

For example, non-virtualized drivers and firmware may communicate using communication protocol a.

2. Related art 2:

fig. 2 is a schematic diagram of driver communication of a virtualized scene in an alternative related art according to an embodiment of the present application, as shown in fig. 2, in the virtualized scene, a plurality of virtual GPU (vGPU) instances exist, where each vGPU instance corresponds to a Guest OS (Guest operating system). A second driver (shown as "second driver 1", "second driver 2", … … "second driver n" in fig. 2) of the vGPU is running in each Guest OS, and implementation of the non-virtualized scenario is used at this time, each Guest driver (second driver) shares a section of memory with Firmware (shown as "local store 1", "local store 2", … … "local store n" in fig. 2), and communication between each Guest driver and Firmware is performed using the communication protocol a. While the Host driver (first driver) is a special existence, it is necessary to manage Firmware, and thus it is also necessary to share a piece of memory (shown as "local store 0" in fig. 2) with Firmware. Therefore, strong coupling of communication protocols among Host drive, guest drive and Firmware is formed, and any one of the three can cause communication failure through adjustment, so that vGPU service on Host is affected, and reliability and stability among drivers are poor.

The driving communication method provided by the embodiment of the application is executed by the server, the graphic processor and the electronic equipment, wherein the electronic equipment comprises the server and the graphic processor, and the server and the graphic processor are connected through a hardware interface. In addition, the server and the graphics processor may be stored in the electronic device as a software functional model, or may be integrated in the electronic device as a hardware functional module, or the server and the graphics processor may be combined with the electronic device in software and hardware to implement a driven communication method, which is not limited in any way by the present application.

In the embodiment of the present application, the electronic device may be a terminal device, which may be a mobile phone, a tablet personal computer (tablet personal computer, TPC), a media player, a smart television, a notebook computer (LC), a personal digital assistant (personal digital assistant, PDA), a personal computer (personal computer, PC), a camera, a video camera, a smart watch, a Wearable Device (WD), or an autopilot vehicle, which is not limited in the embodiment of the present application.

The embodiment of the application provides a communication method of a drive, which is applied to a server, wherein the server runs a first drive and a virtual machine, and the virtual machine runs a second drive, and the basic idea of the method is as follows: firstly, in the process of starting a virtual machine, a first communication protocol is adopted, and first configuration information of the virtual machine, which is sent by a second drive, is stored into a first video memory through a first drive; and then, adopting a second communication protocol, and writing the virtual machine online notification into a second video memory through the first driver to realize the communication between the first driver and the firmware. Because the configuration information stored in the first video memory is used for version negotiation between the first driver and the firmware by adopting the first communication protocol, the firmware can acquire the related configuration information of the first driver and the second driver through the first video memory, so that decoupling between the first driver and the second driver is realized, and reliability and stability between the drivers are improved.

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. 3 is a schematic flow chart of an alternative driven communication method according to an embodiment of the present application, as shown in fig. 3, including S101 to S102:

S101, in the process of starting a virtual machine, a first communication protocol is adopted, and first configuration information of the virtual machine, which is sent by a second drive, is stored into a first video memory through a first drive; the configuration information stored in the first video memory is used for version negotiation between the first driver and the firmware.

In the embodiment of the present application, the first driver is a Host driver (Host driver), and the second driver is a client driver (Guest driver).

In the embodiment of the application, the communication method of the driver is applied to the server, wherein the server runs a Host machine (Host OS), the server runs a first driver and a virtual machine (Guest OS), and the virtual machine runs a second driver.

In the embodiment of the application, the driven communication method can be applied to a server of the electronic equipment, and the electronic equipment comprises the server and the graphic processor which are connected through a hardware interface so as to complete the process of data interaction.

In the embodiment of the application, in the process of starting the virtual machine, the second driver sends the first configuration information to the first driver, and the first driver stores the received first configuration information into the first video memory by adopting the first communication protocol.

In some embodiments of the present application, the first video memory is used to store first configuration information of the second drive and second configuration information of the first drive.

Illustratively, the 0 th display unit (Entry 0) in the first display memory may store the second configuration information of the first driver, and the i th display unit (Entry 1-n) in the first display memory may store the first configuration information of the second driver; wherein i is a positive integer of 0 or more and n or less.

In the embodiment of the application, the data format of the first configuration information and the second configuration information stored in the first video memory complies with a first communication protocol.

In some embodiments of the application, the first configuration information and the second configuration information comprise at least one of: address information of the video memory, version information of the drive, and type information of the drive.

In the embodiment of the present application, the first configuration information is related configuration information of the second drive, for example, the first configuration information may include: the application is not limited to address information of the video memory, version information of the drive, version information of the protocol, identification information of the drive, capacity information of the video memory, application time information of the video memory, and the like, and can be specifically selected according to actual scenes.

In the embodiment of the application, the configuration information stored in the first video memory is used for version negotiation by the first driver and the firmware by adopting a first communication protocol, the first video memory is a section of shared video memory between the first driver and the firmware, the first driver and the firmware can write the data of the instruction and the response into the first video memory, and the communication between the two parties is realized by reading the related data in the first video memory.

It should be noted that, the data format stored in the first video memory complies with the first communication protocol. Illustratively, the first communication protocol may be protocol M. That is, only if the firmware and the first drive both support the protocol M or satisfy compatibility, the instruction or the data of the response in the first video memory can be correctly read.

In the embodiment of the application, the first communication protocol is an outer layer communication protocol of the first driver, and the outer layer communication protocol completes the works such as version negotiation, management of the inner layer protocol and the like.

In the embodiment of the application, after the first driver acquires the first configuration information sent by the second driver and stores the first configuration information in the first video memory, the first driver generates a virtual machine online notification corresponding to the virtual machine.

It can be understood that the first driver and the firmware can carry out version negotiation by adopting the first communication protocol through the configuration information stored in the first video memory, so that the firmware can communicate with the first driver by adopting the first communication protocol, and the firmware can read the relevant configuration information of the first driver and the second driver in the first video memory, thereby effectively avoiding direct communication between the first driver and the second driver and further eliminating the coupling between the first driver and the second driver. Thus, under the condition of ensuring that the outer layer protocol (namely the first communication protocol) is unchanged, the independent upgrading of the first drive and the second drive can be realized, and the problems of the performance, the safety, the stability and the like of the drive program are solved.

It can be understood that the first configuration information of the client is stored in the first video memory, which is acquired through the first driver, and the firmware can acquire the first configuration information corresponding to the virtual machine in the first video memory by adopting the first communication protocol, so that the firmware does not need to acquire the first configuration information through communication with the first driver, and only needs to read the first configuration information in the first video memory by adopting the first communication protocol. In the process, only the firmware is required to support or be compatible with the first communication protocol, and strong coupling between the communication protocol of the virtual machine driver and the communication protocol of the first driver is not required to be ensured, so that decoupling of the virtual machine driver and the first driver can be realized, and when any one of the virtual machine driver and the first driver carries out protocol version upgrading or updating, the other one is not influenced, so that the flexibility of version upgrading of the virtual machine driver and the first driver is ensured, and the safety and the stability of a driver are improved.

S102, adopting a second communication protocol, and writing the virtual machine online notification corresponding to the virtual machine into a second video memory through the first driver to realize communication between the first driver and the firmware.

In the embodiment of the application, after the virtual machine online notification is acquired, the virtual machine online notification is written into the second video memory by the first driver through the second communication protocol, so that the first driver and the firmware are communicated.

In the embodiment of the application, the second video memory is used for the first driver and the firmware to communicate by adopting a second communication protocol. Illustratively, the second communication protocol may be denoted as a.

In the embodiment of the application, at least two segments of video memories are included between the first driver and the firmware: the first video memory and the second video memory may be shared video memory between the first driver and the firmware. The first driver and the firmware adopt a first communication protocol (M) to realize communication through a first video memory, and the first driver and the firmware adopt a second communication protocol (A) to realize communication through the first video memory. The first communication protocol is different from the second communication protocol.

It should be noted that, the first communication protocol is an outer layer protocol of the first driver, and the second communication protocol is an inner layer protocol of the first driver. The first communication protocol is used for realizing version negotiation, and the second communication protocol is used for realizing communication with the firmware. The first communication protocol is not aware of the specific data format and content of the second communication protocol.

In particular, in a GPU virtualization scenario, the relationship between the outer layer protocol and the inner layer protocol is typically from bottom to top. In particular, the inner layer protocol is responsible for handling the transmission and handling of data, while the outer layer protocol is responsible for version negotiation and data transmission of the management protocol. The outer layer protocol is typically at a higher level and interfaces with the communication interfaces of the host operating system, while the inner layer protocol is at a lower level and interfaces with the communication interfaces of the guest operating systems in the virtualized environment. Therefore, when the version negotiation is performed, the outer layer protocol queries the inner layer protocol for version information supported by the outer layer protocol, and then selects an appropriate inner layer protocol version according to the version information of the client operating system so as to realize correct transmission and processing of data.

In an embodiment of the present application, a driven communication method is provided, and applied to a server, where the method includes: firstly, in the process of starting a virtual machine, a first communication protocol is adopted, and first configuration information of the virtual machine, which is sent by a second drive, is stored into a first video memory through a first drive; and then, adopting a second communication protocol, and writing the virtual machine online notification into a second video memory through the first driver to realize the communication between the first driver and the firmware. Because the configuration information stored in the first video memory is used for version negotiation between the first driver and the firmware by adopting the first communication protocol, the firmware can acquire the related configuration information of the first driver and the second driver through the first video memory, the firmware does not need to acquire the configuration information of the second driver through the first driver, and the firmware directly adopts the first communication protocol to read the configuration information from the first video memory, so that the coupling between the first driver and the second driver is reduced, the decoupling between the first driver and the second driver is realized, and the reliability and the stability between the drivers are improved.

In some embodiments of the present application, the implementation of writing, by the first driver, the virtual machine online notification corresponding to the virtual machine into the second video memory using the second communication protocol in S102 may include: and generating a virtual machine online notification through a first driver by adopting a first communication protocol.

In the embodiment of the application, the virtual machine online notification is used for notifying the firmware to read the first configuration information in the first video memory. That is, when the firmware reads the virtual machine on-line notification in the second video memory, the firmware responds to the virtual machine on-line notification and reads the first configuration information in the first video memory by adopting the first communication protocol.

In the embodiment of the application, the virtual machine online notification can be stored in the first driver in advance, and after the first driver acquires the first configuration information sent by the second driver and stores the first configuration information in the first video memory, the first driver directly calls the pre-stored virtual machine online notification.

In the embodiment of the application, the virtual machine online notification can be generated in real time, and after the first driver acquires the first configuration information sent by the second driver and stores the first configuration information in the first video memory, the first driver calls the related generation instruction and generates the corresponding virtual machine online notification according to the preset communication protocol.

In the embodiment of the application, the communication protocol followed by the online notification of the virtual machine can be the same as or different from the first communication protocol, and when the communication protocol followed by the online notification of the virtual machine is different from the first communication protocol, the online notification of the virtual machine can be subjected to data format conversion through the virtual machine drive to obtain the online notification of the intermediate virtual machine, and at the moment, the communication protocol followed by the online notification of the intermediate virtual machine is the same as the first communication protocol.

In some embodiments of the present application, in the process of starting the virtual machine in S101, the implementation before storing, by the first driver, the first configuration information sent by the second driver into the first video memory, using the first communication protocol, may include:

When the virtual machine is started, applying for a third video memory through a second drive; the third video memory is used for storing information of the second drive and the firmware for communication by adopting a third communication protocol.

In some embodiments of the application, the second communication protocol and the third communication protocol are compatible with the first communication protocol.

In the embodiment of the application, the second communication protocol and the third communication protocol are compatible with the first communication protocol, specifically, the compatibility between the communication protocols means that the two communication protocols support each other, and normal interaction of data can be ensured.

In the embodiment of the application, the firmware runs a first communication protocol, and the second communication protocol and the third communication protocol are compatible with the first communication protocol, and at least include: the first communication protocol means that the second communication protocol and the third communication protocol cannot exceed the management of the firmware, and the length of the second communication protocol and the third communication protocol cannot be changed during the operation. That is, the second communication protocol and the third communication protocol are to remain compatible with the firmware.

For example, if the second communication protocol requires a change in length during operation, it is indicated that the second communication protocol does not meet the requirements for compatibility with the first communication protocol. For another example, if the protocol length required by the second communication protocol is 100G, and if the management length of the firmware is 50G at this time, it means that the second communication protocol does not meet the requirement of being compatible with the first communication protocol.

It will be appreciated that the third communication protocol corresponding to the second driver may or may not be the same as the second communication protocol corresponding to the first driver, and whether the third communication protocol and the second communication protocol are the same or not, only the third communication information needs to be ensured to be compatible with the first communication protocol. This is because the first communication protocol has a framework nature and does not involve specific traffic, the first communication protocol is less costly to implement compatible than the second communication protocol and the third communication protocol. Therefore, the decoupling of the second communication protocol and the third communication protocol can be realized only by ensuring that the first communication protocol is compatible with the second communication protocol and the third communication protocol, and the first driver and the second driver can be upgraded independently.

In some embodiments of the present application, the first video memory, the second video memory, and the third video memory are independent of each other.

In some embodiments of the application, the first drive and the second drive communicate via separate channels.

In the embodiment of the application, the channel for realizing communication between the first driver and the firmware and the channel for realizing communication between the second driver and the firmware belong to independent channels.

In the embodiment of the present application, a first communication protocol (such as protocol M) is used for version negotiation between the first driver and the firmware through the first video memory; a second communication protocol (such as protocol a) is used for the first driver and the firmware to communicate through the second video memory; a third communication protocol (e.g., protocol a) is used for the second driver to communicate with the firmware via the third memory.

In the embodiment of the application, the first video memory, the second video memory and the third video memory are mutually independent, and the first video memory, the second video memory and the third video memory can be continuous storage units, discontinuous storage units or partial continuous storage units.

For example, the first and second memories may be consecutive memory locations, while the first and second and third memories are non-consecutive memory locations.

In some embodiments of the present application, the implementation of writing, by the first driver, the virtual machine online notification corresponding to the virtual machine into the second video memory using the second communication protocol in S102 may include S1021 to S1022:

s1021, converting a data format of a virtual machine online notification corresponding to the virtual machine through a first drive by adopting a second communication protocol to obtain an intermediate virtual machine online notification; the data format of the on-line notification of the intermediate virtual machine conforms to a second communication protocol;

s1022, writing the online notification of the intermediate virtual machine into the second video memory through the first driver, so that the firmware responds to the online notification of the intermediate virtual machine to read the first configuration information in the first video memory, and communication between the first driver and the firmware is achieved.

In the embodiment of the application, when the data format of the online notification of the virtual machine does not follow the second communication protocol, the first configuration information is subjected to data format conversion by adopting the second communication protocol through the first driver, so that the online notification of the intermediate virtual machine is obtained. At this time, the data format of the online notification of the intermediary virtual machine conforms to the second communication protocol. And simultaneously, writing the on-line notification of the intermediate virtual machine into the second video memory through the first drive so as to realize the storage of the on-line notification of the virtual machine into the second video memory.

In the embodiment of the application, when the firmware reads the on-line notification of the intermediate virtual machine from the second video memory, and responds to the on-line notification of the intermediate virtual machine, the firmware reads the first configuration information in the first video memory by adopting the first communication protocol, so that the first driver and the firmware are communicated.

It can be understood that, through the dual-layer communication protocol of the first driver, the firmware can obtain the configuration information of the second driver through the first video memory, so that direct communication interaction between the first driver and the second driver is avoided, decoupling between the first driver and the second driver is realized, and maintainability and reliability of the driver are improved.

In some embodiments of the present application, based on fig. 3, as shown in fig. 4, the step of using a second communication protocol in S102 to write the virtual machine online notification corresponding to the virtual machine into the second video memory through the first driver, implementing the communication between the first driver and the firmware may include S103:

and S103, responding to the online notification of the virtual machine, and adopting a third communication protocol to receive resources of the virtual equipment created by the firmware for the virtual machine based on the first configuration information so as to realize the virtual task.

In the embodiment of the application, after the first driver stores the virtual machine online notification to the second video memory, the receiving firmware is based on the first configuration information, and adopts a third communication protocol to create a virtual device resource (vGPU) for the virtual machine.

In the embodiment of the present application, the resources of the virtual device are resources of the virtual machine, where the resources refer to GPU hardware resources.

In the embodiment of the application, in response to the online notification of the virtual machine, whether the first configuration information of the virtual machine is matched with the firmware is judged by the firmware, and the virtual machine drive is successfully loaded by the characterization virtual machine under the condition that the first configuration information is matched with the firmware, at the moment, the firmware is received based on the first configuration information, and the resources of the virtual equipment created for the virtual machine are adopted by the third communication protocol.

In the embodiment of the application, under the condition that the first configuration information is not matched with the firmware, the virtual machine driver is characterized as failed to load the firmware, and at the moment, the resources of the virtual device created by the firmware for the virtual machine are not received.

In the embodiment of the application, under the condition that the first configuration information is matched with the firmware, the second driver and the firmware are successfully loaded, and at this time, the virtual machine can receive the resources of the virtual device created by the firmware for the virtual machine through the third communication protocol.

It can be understood that, on the one hand, since the virtual machine receives the resources of the virtual device created by the firmware for the virtual machine by adopting the third communication protocol, when the version of the first driver is updated or updated, the process that the virtual machine receives the resources of the virtual device created by the firmware for the virtual machine is not affected, so that the allocation efficiency and reliability of the resources of the virtual device are improved. In yet another aspect, decoupling between the first drive and the second drive is achieved because the first drive and the second drive can communicate with the firmware using different communication protocols. In this way, for the non-virtualized scene and the virtualized scene, the communication protocol under the non-virtualized scene may be used without any modification under the virtualized scene.

In some embodiments of the present application, in response to the virtual machine online notification in S103, receiving, by using a third communication protocol, a resource of a virtual device created by firmware for the virtual machine based on the first configuration information, to implement implementation of a virtual task may include:

and under the condition that the first configuration information is matched with the firmware, a third communication protocol is adopted, and the resources of the virtual equipment created for the virtual machine in response to the virtual machine online notification are received through the first driver.

In the embodiment of the application, the resources of the virtual device created for the virtual machine and sent by the firmware are received through the first driver only when the first configuration information is matched with the firmware.

It should be noted that, the first driver receives, by using the third communication protocol, the resource of the virtual device created for the virtual machine and sent by the firmware.

In the embodiment of the application, the resources of the virtual equipment are resources of GPU hardware acceleration capability provided for the virtual machine in the virtualized environment. By slicing the physical GPU and dividing the slices into different virtual machines, the GPU resources can be used by a plurality of virtual machines simultaneously, so that the utilization rate and performance of the GPU are improved.

In the embodiment of the application, in the process of interaction between a first driver (Host driver), a second driver (Guest driver) and firmware, a first communication protocol is adopted in the process of starting a virtual machine by a server, and first configuration information sent by the second driver is stored into a first video memory through the first driver; then, a second communication protocol is adopted, the virtual machine online notification corresponding to the virtual machine is written into a second video memory through a first driver, and the first driver and the firmware can communicate through the second video memory; and finally, responding to the online notification of the virtual machine, and adopting a third communication protocol to receive the resources of the virtual equipment created for the virtual machine by the firmware through the second driver based on the first configuration information so as to realize the virtual task. In the above process, the first drive and the second drive may communicate with the firmware using different communication protocols, so as to implement decoupling between the first drive and the second drive.

It can be appreciated that, because the virtual machine uses the third communication protocol to receive the resources of the virtual device created by the firmware for the virtual machine, and the first driver uses the second communication protocol to communicate with the firmware, the virtual machine driver and the first driver use different communication protocols to communicate with the firmware, so that when the first driver or the second driver performs version upgrade or version update, a party that is not updated is not affected. Under the condition that the first drive and the second drive are not interfered with each other, the drive program can realize decoupling while maintaining compatibility, so that the dimension cost is reduced, and the reliability is improved. Further, as decoupling is realized between the first drive and the second drive, the process of receiving the resources of the virtual device created by the firmware for the virtual machine by the virtual machine is not affected, and therefore the allocation efficiency and reliability of the resources of the virtual device are improved.

In the embodiment of the application, the method further comprises the following steps:

the first drive reading firmware responds to the third indication information written in the second video memory by the virtual machine on-line notification;

and determining that the first configuration information is matched with the firmware according to the third indication information.

In the embodiment of the application, after the first driver writes the virtual machine online notification into the second video memory, the first driver reads the third indication information written by the firmware in response to the virtual machine online notification in the second video memory.

It should be noted that, the data format adopted by the third indication information complies with the second communication protocol.

In the embodiment of the application, the third indication information is used for indicating that the first configuration information is matched with the firmware.

Illustratively, the third indication information is used to indicate that the communication protocol information and the protocol version information in the first configuration information are compatible or consistent with the firmware.

The third indication information is illustratively 1 or True.

responding to the fourth indication information written in the second video memory by the first drive reading firmware in response to the virtual machine online notification;

and according to the fourth indication information, determining that the first configuration information is not matched with the firmware.

In the embodiment of the application, after the first driver writes the virtual machine online notification into the second video memory, the first driver reads fourth indication information written by the firmware in response to the virtual machine online notification in the second video memory.

In the embodiment of the application, the fourth indication information is used for indicating that the first configuration information is not matched with the firmware.

Illustratively, the fourth indication information is used to indicate that the communication protocol information and the protocol version information in the first configuration information are incompatible or inconsistent with the firmware.

Illustratively, the fourth indication information is 0 or False.

When the version information of the firmware is determined by the first driver, the version information of the firmware is one of the version information of the plurality of firmware that can be supported by the server. That is, the firmware is available to the first driver, which can be loaded by the server on one of the GPUs running.

In some embodiments of the present application, based on fig. 4, as shown in fig. 5, in S101, in the process of starting the virtual machine, using the first communication protocol, the previous implementation of storing, by the first driver, the first configuration information sent by the second driver into the first video memory may include S104 to S105:

s104, applying for the first video memory and the second video memory through the first drive when the server is started.

In the embodiment of the application, when the server is started, the first drive starts to be loaded. In the process of loading the first drive, applying for the first video memory and the second video memory through the first drive.

In the embodiment of the present application, the application order of the first video memory and the second video memory is not limited.

S105, storing second configuration information of the second video memory into the first video memory through the first driver under the condition that the handshake between the first driver and the firmware is successful and the version information of the first driver and the firmware are consistent.

In the embodiment of the application, under the condition that the two conditions of successful handshake and consistent version of the first drive and the firmware are met, the second configuration information of the second video memory is stored into the first video memory through the first drive, so that the first drive is loaded successfully.

In the embodiment of the application, after the first driver applies for the second video memory, the second configuration information of the second video memory is written into the first video memory through the first driver, and at this time, the first driver successfully loads the firmware. Wherein the data format of the second configuration information complies with the first communication protocol.

In the embodiment of the application, whether the handshake between the first drive and the firmware is successful is judged by the first drive, and if the handshake between the first drive and the firmware is successful, whether the version information of the first drive and the version information of the firmware are consistent is continuously judged by the first drive.

In an embodiment of the present application, when the first driver and firmware handshake succeeds, both the first driver and firmware are characterized as supporting a first communication protocol (e.g., M).

In an embodiment of the present application, the version information refers to a version of a communication protocol of the first drive or firmware.

In some embodiments of the present application, in the case that the handshake between the first driver and the firmware is successful and the version information of the first driver and the firmware are consistent in S105, the implementation of storing, by the first driver, the second configuration information of the second video memory into the first video memory may include S1051 to S1053:

s1051, under the condition that the handshake between the first driver and the firmware is successful, writing first indication information into the second video memory through the first driver; the first indication information is used for indicating that the first driver and the firmware handshake succeed.

In the embodiment of the application, under the condition that the first driver and the firmware are judged to be successful in handshake by the first driver, the first indication information is written in the second video memory by the first driver.

Wherein the data format of the first indication information complies with the second communication protocol.

S1052, the version information of the firmware written in the second video memory by the firmware in response to the first indication information is acquired through the first drive.

In the embodiment of the application, the first drive reads the version information of the firmware written in the second video memory by the firmware in response to the first indication information.

S1053, storing the second configuration information of the second video memory into the first video memory through the first driver when the version information of the first driver is consistent with the version information of the firmware.

In the embodiment of the application, whether the version information of the first driver is consistent with the version information of the firmware is judged by the first driver, and the second configuration information of the second video memory is stored into the first video memory by the first driver only under the condition that the version information of the first driver is consistent with the version information of the firmware, so that the first driver is successfully loaded.

In some embodiments of the present application, in the case that the handshake between the first driver and the firmware is successful and the version information of the first driver and the firmware are consistent in S105, the implementation of storing, by the first driver, the second configuration information of the second video memory into the first video memory may further include S1054 to S1056:

s1054, writing the first preset information into the second video memory through the first drive; the data format of the first preset information complies with a first communication protocol.

In the embodiment of the application, the first preset information is information agreed by both the first driver and the firmware.

The first preset information is illustratively 1.

S1055, obtaining second preset information written in the second video memory by the firmware in response to the first preset information through the first drive; the data format of the second preset information complies with a communication protocol specified by the firmware.

In the embodiment of the application, the second preset information is information agreed by both the first driver and the firmware.

The second preset information is illustratively 2.

S1056, determining the first indication information through the first drive when the first preset information and the second preset information meet the preset handshake condition.

In the embodiment of the application, whether the first preset information and the second preset information meet the preset handshake condition or not is judged by the first drive, and the first indication information is determined by the first drive only under the condition that the first preset information and the second preset information meet the preset handshake condition.

In the embodiment of the application, the preset handshake condition is a condition agreed in advance by both the first driver and the firmware.

In some embodiments of the present application, in S105, when the handshake between the first driver and the firmware is successful and the version information of the first driver and the firmware are consistent, the implementation of storing, by the first driver, the second configuration information of the second video memory into the first video memory may further include:

Writing second instruction information into the second video memory through the first drive under the condition that the handshake between the first drive and the firmware fails; the second indication information is used for indicating that the first driver and the firmware handshake fail.

In the embodiment of the present application, the process of handshake and notification interaction between the first driver (Host driver) and the firmware through the shared memory may include the following steps:

step one, starting to load a first drive in the process of starting a server, and applying for a first video memory and a second video memory through the first drive in the process of loading the first drive; the first video memory is used for storing information of the first driver and the firmware which are communicated by adopting a first communication protocol; the second video memory is used for storing information of the first driver and the firmware which are communicated by adopting a second communication protocol; the first video memory and the second video memory are shared memory between the first driver and the firmware.

Step two, the server writes first preset information (such as 1) into a second video memory through a first drive, and obtains second preset information (such as 2) written into the second video memory by the firmware in response to the first preset information through the first drive; wherein the data format of the second preset information conforms to a communication protocol specified by firmware; and under the condition that the server determines that the first preset information and the second preset information meet the preset handshake conditions, determining that the handshake between the first driver and the firmware is successful.

If the handshake between the first driver and the firmware is successful, executing the third step, and if the handshake between the first driver and the firmware is failed, characterizing that the loading of the firmware by the first driver is failed.

Step three, under the condition that the handshake between the first driver and the firmware is successful, the version information of the firmware, which is written in the second video memory by the firmware in response to the first indication information, is obtained through the first driver; and under the condition that the version information of the first driver is consistent with the version information of the firmware, storing second configuration information of the second video memory into the first video memory through the first driver, and at the moment, successfully loading the firmware by the first driver.

Step four, in the process of starting the virtual machine, a first communication protocol is adopted, the server stores first configuration information of the virtual machine, which is sent by the second drive, into a first video memory through the first drive, and a virtual machine online notification is generated through the first drive; the server writes the virtual machine online notification into the second video memory through the first drive, so that the firmware responds to the intermediate virtual machine online notification to read the first configuration information in the first video memory, and the communication between the first drive and the firmware is realized.

It can be appreciated that, since the second memory is used to store information that the first driver and the firmware use the second communication protocol to communicate, and the third memory is used to store information that the second driver and the firmware use the third communication protocol to communicate, the first driver and the second driver can use different communication protocols to communicate with the firmware, so as to realize decoupling between the second driver and the first driver. Therefore, the second driver and the first driver can be independently upgraded, namely, any one of the first driver and the second driver performs operations such as version upgrade or protocol update, and the like, and communication between the other one and the firmware cannot be affected, so that the problems of performance, safety, stability and the like are solved. Therefore, the application can improve the decoupling of the second drive and the first drive, thereby improving the reliability and the stability between the second drive and the first drive.

It can be understood that, because the configuration information stored in the first video memory is used for version negotiation between the first driver and the firmware by adopting the first communication protocol, the firmware can acquire the related configuration information of the first driver and the second driver through the first video memory, the firmware does not need to acquire the configuration information of the second driver through the first driver, and the firmware directly adopts the first communication protocol to read the configuration information from the first video memory, so that the coupling between the first driver and the second driver is reduced, the decoupling between the first driver and the second driver is realized, and the reliability and the stability between the drivers are improved.

In the embodiment of the present application, in the server, M virtual machines, where M is a positive integer greater than or equal to 1, in S101, in a process of starting the virtual machines, a first communication protocol is adopted, and previous implementation of storing, by a first driver, first configuration information sent by a second driver into a first video memory may include:

in the process of starting an ith virtual machine, storing the ith first configuration information of the ith virtual machine, which is sent by an ith second drive, into an ith video memory unit in a first video memory through a first drive, and generating an ith virtual machine online notification corresponding to the ith virtual machine; wherein i is a positive integer greater than or equal to 1; the data format of the ith first configuration information stored in the ith display unit conforms to a first communication protocol;

Continue to drive ith by first drive1 th (i) th (of) second drive transmission>1 th i +.>In 1 video memory unit, and generate the i +.>1 th +.>1 virtual machine on-line notification until i +.>1/>M, thereby obtaining a first video memory storing first configuration information of M virtual machines.

In the embodiment of the application, a plurality of virtual machines can be run in the server.

In the embodiment of the application, each virtual machine corresponds to a virtual machine on-line notification, and the first configuration information of each virtual machine is stored in the corresponding video memory unit.

In some embodiments of the present application, the second driver and firmware communicate via a third communication protocol, and the communication state of the second driver and firmware includes a virtualized state or a non-virtualized state.

In the embodiment of the application, the communication method of the drive is applied to a non-virtualized scene and a virtualized scene; wherein, in both the non-virtualized scenario and the virtualized scenario, the second driver and the firmware may communicate via a third communication protocol.

The second drive in the non-virtualized state is also referred to as a non-virtualized drive.

It can be understood that, because the second driver and the firmware in the non-virtualized state communicate through the third communication protocol in the non-virtualized scene, the second driver and the firmware in the virtualized state can also communicate through the third communication protocol in the virtualized scene, so that the drivers in the virtualized scene and the non-virtualized scene can be unified to a high degree, further, repeated development of the drivers is not required, and the maintenance cost is reduced.

In the embodiment of the application, the same hardware interface is adopted between the second drive and the firmware in the non-virtualized state and the second drive and the firmware in the virtualized state.

It will be appreciated that since drivers in virtualized and non-virtualized scenarios may be highly unified, there is no need to separately design firmware for virtualized and non-virtualized scenarios, thereby reducing the amount of duplication. In addition, the communication protocol in the non-virtualized scene can be used without any modification in the virtualized scene, so that the interfaces of the driver and the hardware can be completely consistent, and the maintainability and the reliability of the driver can be fully guaranteed.

In some embodiments of the application, S101 may include S1011 to S1012:

s1011, receiving first configuration information sent by a second driver through a first driver;

s1012, converting the data format of the first configuration information through a first driver to obtain intermediate first configuration information, and writing the intermediate first configuration information into a first video memory; the data format of the intermediate first configuration information complies with the first communication protocol.

In the embodiment of the application, the second driver can send the first configuration information of the second driver to the first driver through a preset communication channel.

In the embodiment of the application, the communication protocol adopted by the first configuration information is agreed in advance for a preset communication channel. That is, the data format of the first configuration information may conform to or be compatible with the first communication protocol, or the data format of the first configuration information may not conform to the first communication protocol, which is not limited by the present application.

In the embodiment of the application, when the data format of the first configuration information does not conform to the first communication protocol, the first configuration information is subjected to data format conversion by adopting the first communication protocol through the first driver, so as to obtain intermediate first configuration information. At this time, the data format of the intermediate first configuration information complies with the first communication protocol. Meanwhile, the first configuration information in the middle is written into the first video memory through the first driver, so that the first configuration information is stored into the first video memory.

The embodiment of the application provides a driving communication method which is applied to a graphic processor, wherein the graphic processor runs firmware, and the basic idea of the method is as follows: firstly, in the process of starting a virtual machine, a second communication protocol is adopted, and first configuration information of a second driver is obtained through firmware in response to a virtual machine online notification written in a second video memory by the first driver; and then, based on the first configuration information, adopting a third communication protocol to send the resources of the virtual equipment created for the virtual machine to the server so as to realize the virtual task. In the embodiment of the application, the configuration information stored in the first video memory is used for version negotiation between the first driver and the firmware, so that the firmware can acquire the related configuration information of the first driver and the second driver through the first video memory, and the decoupling between the first driver and the second driver is realized, thereby improving the reliability and stability between the drivers.

Fig. 6 is a flow chart diagram of an alternative driven communication method according to an embodiment of the present application, as shown in fig. 6, including S201 to S202:

s201, in the process of starting the virtual machine, a second communication protocol is adopted, and in response to the virtual machine on-line notification written in the second video memory by the first driver, first configuration information of the second driver is obtained through firmware.

In an embodiment of the application, the driven communication method is applied to a Graphics Processor (GPU), wherein the graphics processor runs firmware.

In the embodiment of the application, the driven communication method can be applied to the graphic processor of the electronic equipment, and the electronic equipment comprises a server and the graphic processor which are connected through a hardware interface so as to complete the process of data interaction.

In the embodiment of the application, the second video memory is used for storing information that the first driver and the firmware communicate by adopting a second communication protocol. Illustratively, the second communication protocol may be denoted as a.

In some embodiments of the present application, implementation of S201 may include S2011 to S2013:

s2011, reading an on-line notification of the intermediate virtual machine in a second video memory through firmware by adopting a second communication protocol; the intermediate virtual machine online notification is obtained by converting the data of the virtual machine online notification by the host virtual machine, and the data format of the intermediate virtual machine online notification conforms to a second communication protocol.

S2012, determining drive identification information corresponding to the first drive through firmware according to the on-line notification of the intermediate virtual machine; the drive identification information has a correspondence relationship with the second drive.

In the embodiment of the application, the drive identification information has a corresponding relation with the second drive, and the drive identification information is unique identification information of the second drive corresponding to each virtual machine. That is, there is a one-to-one correspondence between the drive identification information and the second drive.

Illustratively, the drive identification information is 1, which is used to represent the second drive of the 1 st virtual machine.

S2013, reading first configuration information of the second driver corresponding to the driver identification information in the first video memory through firmware by adopting a first communication protocol.

In the embodiment of the application, the firmware reads the drive identification information corresponding to the drive identification information in the first video memory, thereby obtaining the first configuration information of the second drive.

In some embodiments of the present application, the above-described driven communication method is applied to non-virtualized scenes and virtualized scenes; under the non-virtualized scene, the second driver and the firmware in the non-virtualized state realize communication through a third communication protocol; in the virtualized scenario, the second driver in the virtualized state communicates with the firmware via a third communication protocol.

It can be understood that, because the second driver and the firmware can communicate through the third communication protocol in the non-virtualized scene and the virtualized scene, the drivers in the virtualized scene and the non-virtualized scene can be unified to a high degree, and further, the drivers do not need to be repeatedly developed, so that the maintenance cost is reduced.

In some embodiments of the present application, the same hardware interface is employed between the second driver and firmware in the non-virtualized state and the second driver and firmware in the virtualized state.

S202, based on the first configuration information, adopting a third communication protocol to send resources of virtual equipment created for the virtual machine to a server so as to realize a virtual task; the first configuration information is stored in a first video memory adopting a first communication protocol by a first driver; the first configuration information is sent to the first drive by the second drive; the configuration information stored in the first video memory is used for version negotiation between the first driver and the firmware.

In some embodiments of the present application, S202 may include:

and in response to the virtual machine online notification, transmitting resources of the virtual device created for the virtual machine to the first driver through the firmware by adopting a third communication protocol under the condition that the first configuration information is matched with the firmware.

In the embodiment of the application, the second driver and the firmware are successfully loaded under the condition that the first configuration information is matched with the firmware, and at this time, the firmware can send the resources of the virtual device created for the virtual machine to the server through the third communication protocol.

In the embodiment of the application, under the condition that the first configuration information is not matched with the firmware, the virtual machine driver is characterized as failed to load the firmware, and at this time, the firmware will not create resources of the virtual device for the virtual machine.

In some embodiments of the application, the method further comprises:

in response to the virtual machine online notification, determining third indication information under the condition that the first configuration information is matched with the firmware;

and writing the third indication information into the second video memory through the firmware.

In the embodiment of the application, after the firmware reads the virtual machine on-line notification written into the second video memory by the first driver, the firmware responds to the virtual machine on-line notification to write the third indication information into the second video memory under the condition that the first configuration information is matched with the firmware.

The third indication information is illustratively 1 or True.

In some embodiments of the application, the method further comprises:

in response to the virtual machine online notification, determining fourth indication information under the condition that the first configuration information is not matched with the firmware;

and writing fourth indication information into the second video memory through the firmware.

In the embodiment of the application, after the firmware reads the virtual machine on-line notification written into the second video memory by the first driver, the firmware responds to the virtual machine on-line notification to write the fourth indication information into the second video memory under the condition that the first configuration information is not matched with the firmware.

Illustratively, the fourth indication information is 0 or False.

It should be noted that, the data format adopted by the fourth indication information complies with the second communication protocol.

In some embodiments of the application, the method further comprises:

writing second preset information in the second video memory through the firmware in response to the first preset information written in the second video memory by the first driver; the data format of the first preset information conforms to a first communication protocol; the data format of the second preset information complies with a communication protocol specified by the firmware.

The first preset information is illustratively 1.

The second preset information is illustratively 2.

In some embodiments of the application, the method further comprises:

reading first indication information written in a second video memory by a first driver through firmware; the first indication information is used for indicating that the handshake between the first driver and the firmware is successful;

and responding to the first indication information, and writing own version information into the second video memory through the firmware.

In some embodiments of the application, the method further comprises: reading second indication information written in the second video memory by the first driver through the firmware; the second indication information is used for indicating that the first driver and the firmware handshake fail.

In the embodiment of the application, whether the first preset information and the second preset information meet the preset handshake condition or not is judged by the first driver, and only if the first preset information and the second preset information meet the preset handshake condition, the first indication information written in the second video memory by the first driver is read by the firmware.

In the embodiment of the application, the version information of the firmware is written into the second video memory through the firmware in response to the first indication information written into the second video memory by the first driver; it should be noted that, the data format of the version information of the firmware complies with the second communication protocol.

In an embodiment of the present application, a communication method for driving is provided, and the method is applied to a graphics processor, and includes: firstly, in the process of starting a virtual machine, a second communication protocol is adopted, and first configuration information of a second driver is obtained through firmware in response to a virtual machine online notification written in a second video memory by the first driver; and then, based on the first configuration information, adopting a third communication protocol to send the resources of the virtual equipment created for the virtual machine to the server so as to realize the virtual task.

On the one hand, because the configuration information stored in the first video memory is used for version negotiation between the first driver and the firmware by adopting the first communication protocol, the firmware can acquire the related configuration information of the first driver and the second driver through the first video memory, the firmware does not need to acquire the configuration information of the second driver through the first driver, and the configuration information is directly read from the first video memory by adopting the first communication protocol, so that the coupling between the first driver and the second driver is reduced, and the decoupling between the first driver and the second driver is realized.

On the other hand, the first driver realizes communication through the second video memory and the firmware adopting the second communication protocol, and the second driver realizes communication through the third video memory and the firmware adopting the third communication protocol, and because the first driver and the second driver can adopt different communication protocols to communicate with the firmware, the operation of version application or protocol updating and the like of any one of the first driver and the second driver can not influence the communication between the other party and the firmware, thereby realizing decoupling between the drivers and improving the reliability and the stability between the drivers.

In still another aspect, the resources of the virtual device created for the virtual machine are sent to the server by adopting the third communication protocol, so that when the version of the first driver is updated or updated, the process that the virtual machine receives the resources of the virtual device created for the virtual machine by the firmware is not affected, and the allocation efficiency and reliability of the resources of the virtual device are improved.

In the embodiment of the present application, fig. 7 is a schematic flow chart of an alternative method for communication of drivers, as shown in fig. 7, where the method for communication of drivers may be applied to a server, and the method for communication of drivers may also be applied to a graphics processor, where the server is connected to the graphics processor through a hardware interface, and a first driver (host driver) and a second driver (Guest driver) are running in the server, and the graphics processor runs firmware.

As shown in fig. 7, the communication method of the drive may include S301 to S308:

s301, applying for a first video memory and a second video memory through a first drive when the server is started.

In the embodiment of the application, the server applies for the first video memory and the second video memory by running the first driver.

S302, under the condition that the handshake between the first driver and the firmware is successful and the version information of the first driver and the firmware are consistent, storing second configuration information of the second video memory into the first video memory through the first driver, and realizing successful loading of the first driver.

In the embodiment of the application, under the condition that the handshake between the first driver and the firmware is successful and the version information of the first driver is consistent with that of the firmware, the server realizes the successful loading of the first driver by storing the second configuration information of the second video memory into the first video memory.

In the application embodiment, S302 may include S3021 to S3022:

s3021, writing first preset information into a second video memory through a first drive; the data format of the first preset information conforms to a first communication protocol; acquiring second preset information written in a second video memory by the firmware in response to the first preset information through the first driver; the data format of the second preset information conforms to a communication protocol specified by firmware; determining first indication information through a first drive under the condition that the first preset information and the second preset information meet preset handshake conditions;

s3022, under the condition that the handshake between the first driver and the firmware is successful, writing first indication information into the second video memory through the first driver; the first indication information is used for indicating that the handshake between the first driver and the firmware is successful; the method comprises the steps that version information of firmware written in a second video memory by the firmware in response to first indication information is obtained through a first driver; and under the condition that the version information of the first driver is consistent with the version information of the firmware, storing second configuration information of the second video memory into the first video memory through the first driver, so as to realize successful loading of the first driver.

S303, applying for a third video memory through a second drive when the virtual machine is started.

S304, the second configuration information is sent to the first driver through the second driver.

S305, in the process of starting the virtual machine, a first communication protocol is adopted, first configuration information of the virtual machine, which is sent by the second drive, is stored into a first video memory through the first drive, and a virtual machine online notification corresponding to the virtual machine is generated.

S306, adopting a second communication protocol, and writing the virtual machine online notification into a second video memory through the first driver.

S307, in the process of starting the virtual machine, a second communication protocol is adopted, and the first configuration information of the second drive is acquired through the firmware in response to the virtual machine on-line notification written in the second video memory by the first drive.

In the application embodiment, S307 may include S3071 to S3073:

s3071, reading an on-line notification of the intermediate virtual machine in a second video memory through firmware by adopting a second communication protocol; the method comprises the steps that an online notification of the intermediate virtual machine is obtained by converting data of the online notification machine of the virtual machine by a first driver, and a data format of the online notification of the intermediate virtual machine conforms to a second communication protocol;

s3072, determining drive identification information corresponding to the first drive through firmware according to the virtual machine online notification; the drive identification information has a corresponding relation with the second drive;

S3073, the first configuration information of the second driver corresponding to the driver identification information is read in the first video memory through firmware by adopting the first communication protocol.

And S308, under the condition that the first configuration information is matched with the configuration information of the firmware, adopting a third communication protocol to send the resources of the virtual equipment created for the virtual machine to the server through the firmware so as to realize the virtual task.

In the communication method of the drive, on the basis of realizing the communication between the first drive and the firmware and between the second drive and the firmware, the decoupling between the first drive and the second drive is realized, so that the reliability and the stability between the driving programs are improved.

In the above-described driving communication method, the execution subject may be a server and a graphics processor, and the above-described driving communication method may include S401 to S408:

s401, the server applies for a third video memory by running a second drive;

s402, the server sends second configuration information to the first driver through the second driver;

s403, when the server starts the virtual machine, the server applies for a third video memory through the second drive;

s404, the server sends second configuration information to the first driver by running the second driver; s405, a first communication protocol is adopted, and a server stores first configuration information of the first configuration information sent by a second driver into a first video memory by running the first driver, and generates a virtual machine online notification corresponding to a virtual machine;

S406, adopting a second communication protocol, and writing the virtual machine online notification into a second video memory by the server through the first drive;

s407, a second communication protocol is adopted, and the server responds to the virtual machine on-line notification written in the second video memory by the first driver, and obtains first configuration information of the second driver through firmware;

and S408, under the condition that the first configuration information is matched with the configuration information of the firmware, adopting a third communication protocol, and sending the resources of the virtual device created for the virtual machine to the server by the graphic processor through operating the firmware so as to realize the virtual task.

The above-described driving communication method is explained in detail in a specific embodiment as follows:

in the related art, for a non-virtualized environment, since each host runs only one driver (referred to herein as a non-virtualized driver), firmware and a non-virtualized driver are in one-to-one relationship. Under the non-virtualized environment, the communication structure is simple, and the non-virtualized driver and Firmware communicate in a shared memory mode.

In the related art, for a virtualized environment, there are multiple vGPU instances, each vGPU instance corresponding to a Guest OS. Each Guest OS runs a vGPU driver (referred to herein as a Guest driver), and at this time, implementation of a non-virtualized scenario is implemented, where each Guest driver (the second driver) shares a piece of memory with Firmware. The Host driver (first driver) is a special existence, and needs to manage Firmware, so that it is also needed to share a piece of memory with Firmware. Thus, strong coupling of communication protocols among the three is formed, and any adjustment among the three can lead to communication failure and influence vGPU service on a Host.

Aiming at the coupling, the embodiment of the application provides a scheme for reducing the coupling, and in order to maximize compatibility with non-virtualized scenes, drivers in two scenes are compatible as far as possible. For the virtualization scenario, a layer of Firmware management protocol (corresponding to a first communication protocol) unique to the Host is added, the type and version of the driver are defined, and information (corresponding to first configuration information) such as a memory address used by actual communication is defined. The Host and the Guest drivers use different types, and Firmware judges the opposite party information of communication according to the type, version and other information, so that the actual data pointed by the pointer in the management protocol is analyzed by using different version protocol formats, and the communication is completed. The data format actually used can be consistent with the non-virtualized scene, so that decoupling of the three is realized while sufficient compatibility is ensured.

It should be noted that, the Host driver is the first driver, and the Guest driver is the second driver.

Fig. 8 is a schematic diagram of driver communication of an alternative virtualized scenario, where multiple vGPU (virtual GPU) instances exist, as shown in fig. 8, where each vGPU instance corresponds to a Guest OS (Guest operating system). A second driver of the vGPU (shown as "second driver 1", "second driver 2" … … "second driver n" in fig. 8) is run in each Guest OS, and implementation of the non-virtualized scenario is used at this time, and each Guest driver shares a piece of memory with Firmware (shown as "local store 1", "local store 2" … … "local store n" in fig. 8). It should be noted that, "local storage 1", "local storage 2" … … "and" local storage n "are equivalent to a third video memory, and the third video memory adopts a third communication protocol (e.g., a). The Host driver is a special one, and needs to manage Firmware, the Host driver (first driver) adopts two-layer communication protocol, the outer layer communication protocol (Firmware management protocol M) (corresponding to the first communication protocol M) completes version negotiation, the local storage corresponding to the outer layer communication protocol stores configuration information (type, version and storage address shown by "entry 1", "entry 2" … … "entry n" in fig. 8) of each driver, the inner layer protocol (communication protocol a) (corresponding to the second communication protocol a) manages and the like, and the inner layer protocol completes specific communication work. It should be noted that the outer layer protocol does not perceive the specific format and content of the inner layer protocol. Wherein entry 0 stores the configuration information (type, version, and storage address) of the first driver itself.

In the embodiment of the present application, as shown in fig. 9, the specific communication process of the Guest driver, host driver and Firmware may include steps S501 to S510:

s501, loading Firmware at the same time as the Host driver (first driver).

In the embodiment of the application, when the Host system of the server is started, firmware is loaded at the same time when the Host driver is loaded. It should be noted that the loading manner of the Host driver and Firmware may be different depending on the hardware platform, the operating system and the driver implementation. The Host driver and Firmware can be loaded simultaneously or separately, and the application is not limited to this, and the corresponding loading mode can be selected according to the actual situation.

For example, when the Host driver and Firmware are loaded separately, the loading procedure for the Host driver may be: the Host driver tries to run the program on the Host operating system, and is mainly used for managing and controlling GPU resources and providing an interface for accessing the GPU. For Firmware loading, the loading process can be: firmware is a special piece of software, typically embedded in a hardware device, that manages the hardware resources of the device and communicates with the Host initiator, where it is loaded into a specific memory address of the GPU device to facilitate access and control of the GPU device by the Host driver.

S502, applying a section of video memory in the first driver program for communication with the firmware by adopting a communication protocol M.

In the embodiment of the application, after the Host driver loads the Firmware at the same time, the Host driver can apply a section of video memory (or memory) to the system for communication with the Firmware through a certain mechanism, and the section of video memory is used for management and allocation (corresponding to the first video memory) by adopting the communication protocol M (corresponding to the first communication protocol).

S503, if the firmware supports the communication protocol M, the handshake between the two parties is successful, the first driver applies a section of video memory for communication with the firmware by adopting the communication protocol A, and the address of the section of video memory is stored in the video memory managed by the communication protocol M.

In the embodiment of the application, if the Firmware supports the communication protocol M, the fact that the handshake between the Firmware and the Host driver is successful is indicated, and the Host driver applies a section of video memory (corresponding to a second video memory) for communicating with the Firmware by adopting the communication protocol A (corresponding to a second communication protocol).

S504, managing the firmware through the communication protocol A.

In the embodiment of the present application, after S503, it indicates that the Host successfully loads Firmware, and management work can be performed on Firmware through the communication protocol a. Specifically, the Host driver can write commands and data to the video memory address allocated to the communication protocol a, which will be read by Firmware and perform the corresponding operation. Meanwhile, the Firmware can also write the response and the data through the video memory address distributed by the communication protocol A, and the response and the data are read by the Host to obtain the execution result of the Firmware. In short, the data exchange between Host drive and Firmware can be realized by sharing the video memory.

S505, when the virtual machine is started, the Guest driver (second driver) needs to load firmware, and applies a section of video memory for communication with the firmware by adopting the communication protocol a.

In the embodiment of the application, because Firmware is an important component required by the Guest driver, the communication and management of the Guest driver and GPU hardware can be realized. Thus, at virtual machine start-up, the Guest driver needs to load Firmware.

Note that, the communication protocol a is different from the communication protocol a.

Further, the Guest driver applies for a section of video memory (corresponding to the third video memory) for communication with the Firmware, and adopts the communication protocol a (corresponding to the third communication protocol), where the video memory can be regarded as a buffer zone between the Guest driver and the Firmware, and the Guest driver can write data into the buffer zone and the Firmware can read data from the buffer zone.

S506, the second driver sends the information such as the video memory address, the driving version, the protocol type and the like applied in S505 to the first driver.

In the embodiment of the application, the Guest driver sends the information (equivalent to the first configuration information) such as the video memory address, the driving version, the protocol type and the like to the Host driver, and the related information is required to be converted by the virtualization technology because the Guest driver and the Host driver run in different virtual machines, and the addresses seen by the Guest driver and the Host driver are different.

S507, the first driver program sends the information of the video memory address, the driving version, the protocol type and the like obtained in S506 to the firmware through the protocol M, and the information is stored in the video memory managed by the protocol M.

In the embodiment of the application, after the Host driver receives the information such as the video memory address, the driving version, the protocol type and the like, the relevant information is written into the shared memory of the Firmware and the Host driver through the communication protocol M, namely, the relevant information is stored in the video memory managed by the communication protocol M. Likewise, the video memory managed by the communication protocol M can be regarded as a buffer between Firmware and Host driver, into which Host driver can write data, and Firmware can read data.

S508, the firmware reads the newly added Entry (Entry) from the video memory managed by the protocol M in S507, and obtains the information of the video memory address, the driving version, the protocol type and the like of the second driving program.

And S509, if the firmware judges that the information such as the video memory address, the driving version, the protocol type and the like of the second driving program are matched with the information of the firmware, the second driving program and the firmware are successfully loaded.

S510, if the firmware judges that the information such as the video memory address, the driving version, the protocol type and the like of the second driving program is failed to be matched with the information of the firmware, the loading of the firmware fails, and the loading of the second driving program fails.

In the process, communication protocol a in a non-virtualized scene is adopted between the Guest driver and Firmware to perform communication, and decoupling is realized while compatibility is maintained.

It will be appreciated that through the above process, communications between the Host driver and the Guest driver and Firmware are isolated, such that the Host driver and Guest driver do not need to directly rely on and interact with each other. This decoupled design helps to maintain compatibility because updates and changes to the Host and Guest systems do not affect the Firmware design and implementation, and vice versa. Meanwhile, the decoupling design also improves the flexibility and maintainability of the system, because different system components can be updated and maintained relatively independently, and the maintainability and expandability of the system can be improved while the compatibility is ensured.

It can be understood that although the Firmware and Host driver, and the Firmware and Guest driver need to maintain certain compatibility, direct coupling of the Host driver and Guest driver can be reduced, so that the relationship between different layers is looser, the maintenance and expansion are reduced, meanwhile, communication between different layers can be managed and coordinated through an outer layer protocol, and the reliability and performance of the whole system are improved.

In the related art, in a virtualized scene and a non-virtualized scene, a Host driver and a Guest driver can introduce a coupling problem, so that the Guest driver is difficult to upgrade independently. The solution to the above problem is typically to design Firmware for virtualized and non-virtualized scenarios separately, resulting in a large number of repetitive tasks affecting maintainability and reliability. On one hand, the embodiment of the application can solve the problem that the decoupling of Host driving and Guest driving can not be realized while unified virtualized and non-virtualized driving in the related technology. On the other hand, the embodiment of the application can use the communication protocol under the non-virtualized scene without any modification under the virtualized scene, the interfaces between the driver and the hardware are completely consistent, and the maintainability and the reliability can be fully guaranteed. On the other hand, the embodiment of the application realizes the decoupling between the Host driver and the Guest driver, and the Host driver and the Guest driver can be independently upgraded on the basis of unchanged outer layer protocol, thereby solving the problems of performance, safety, stability and the like.

The driving communication method provided by the embodiment of the application has the following beneficial effects:

1) Aiming at virtualized scenes and non-virtualized scenes, the embodiment of the application keeps consistency of a Guest driver (second driver) to the maximum extent, repeated development is not needed, maintenance cost is reduced, and reliability is improved;

2) The embodiment of the application releases the coupling between the Host driver and the Guest driver, and the Guest driver can be independently upgraded. The safety and stability are improved more flexibly;

the key point of the driving communication method provided by the embodiment of the application is that:

1) The embodiment of the application adopts a mode of a two-layer protocol (a first communication protocol and a second communication protocol) to realize decoupling between a Guest driver (a second driver) and a Host driver (a first driver);

2) The driver program in the virtualized scene and the non-virtualized scene can realize high unification.

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. 10 is a schematic diagram of a composition structure of an optional server according to an embodiment of the present application, where, as shown in fig. 10, the server runs a first driver and a virtual machine, and the virtual machine runs a second driver; the server 10 includes: a drive unit 11; the driving unit includes a first driving unit 111 and a second driving unit 112; the first driving unit 111 is configured to store, by using a first communication protocol, first configuration information of the first driving unit sent by the second driving unit into a first video memory through a first driving unit in a process of starting the virtual machine; the configuration information stored in the first video memory is used for version negotiation between the first driver and the firmware; adopting a second communication protocol, writing a virtual machine online notification corresponding to the virtual machine into the second video memory, and realizing the communication between the first driver and the firmware;

In some embodiments of the present application, the first driving unit 111 is further configured to generate, by using the first communication protocol, the virtual machine online notification through the first driving.

In some embodiments of the present application, the second driving unit 112 is configured to receive, in response to the online notification of the virtual machine, a resource of a virtual device created by the firmware for the virtual machine based on the first configuration information, using a third communication protocol, so as to implement a virtual task.

In some embodiments of the present application, the second driving unit 112 is further configured to apply for a third video memory when the virtual machine is started; and the third video memory is used for storing information of the second drive and the firmware for communication by adopting the third communication protocol.

In some embodiments of the present application, the first driving unit 111 is further configured to perform data format conversion on the online notification of the virtual machine by adopting the second communication protocol, so as to obtain an online notification of the intermediate virtual machine; the data format of the online notification of the intermediate virtual machine conforms to the second communication protocol; and writing the online notification of the intermediate virtual machine into the second video memory, so that the firmware responds to the online notification of the intermediate virtual machine to read the first configuration information in the first video memory, and the communication between the first driver and the firmware is realized.

In some embodiments of the present application, the second driving unit 112 is further configured to, when the first configuration information matches with the configuration information of the firmware, receive, by using the third communication protocol, a resource of a virtual device of the virtual machine that is fed back by the firmware in response to the virtual machine online notification through the first driving unit.

In some embodiments of the present application, the first driving unit 111 is further configured to apply for the first video memory when the server is started; applying for a second video memory under the condition that the handshake between the first driver and the firmware is successful and the version information of the first driver and the firmware is consistent; and storing second configuration information of the second video memory into the first video memory.

In some embodiments of the present application, the first driving unit 111 is further configured to write first indication information in the second video memory if the handshake between the first driving unit and the firmware is successful; the first indication information is used for indicating that the handshake between the first driver and the firmware is successful; acquiring version information of the firmware written in the second video memory by the firmware in response to the first indication information; and applying for the second video memory under the condition that the version information of the first drive is consistent with the version information of the firmware.

In some embodiments of the present application, the first driving unit 111 is further configured to write first preset information into the second video memory; the data format of the first preset information conforms to the first communication protocol; acquiring second preset information written in the second video memory by the firmware in response to the first preset information; the data format of the second preset information conforms to the communication protocol specified by the firmware; and determining the first indication information under the condition that the first preset information and the second preset information meet a preset handshake condition.

In some embodiments of the present application, the second driver and the firmware communicate via a third communication protocol, and the communication state of the second driver and the firmware includes a virtualized state or a non-virtualized state.

In some embodiments of the present application, the first video memory is configured to store first configuration information of the first driver and second configuration information of the second driver.

In some embodiments of the application, the first configuration information and the second configuration information include at least one of: address information of the video memory, version information of the drive, and type information of the drive.

In some embodiments of the present application, the first video memory, the second video memory, and the third video memory are independent from each other.

In some embodiments of the present application, the first driving unit 111 is further configured to receive, by the first driver, the first configuration information sent by the second driver; converting the data format of the first configuration information through the first driver to obtain intermediate first configuration information, and writing the intermediate first configuration information into the first video memory; the data format of the intermediate first configuration information complies with the first communication protocol.

It will be appreciated by those skilled in the art that the above description of the server of an embodiment of the present application may be understood with reference to the description of the communication method of the driver of an embodiment of the present application.

Based on the same inventive concept as the previous embodiment, fig. 11 is a schematic diagram of the composition structure of an alternative graphics processor according to an embodiment of the present application, as shown in fig. 11, where the graphics processor 20 includes a firmware unit 21; the firmware unit 21 is configured to, in a process of starting the virtual machine, obtain first configuration information of the second driver by adopting a second communication protocol in response to an online notification of the virtual machine written in the second video memory by the first driver; based on the first configuration information, a third communication protocol is adopted to send resources of virtual equipment created for the virtual machine to a server so as to realize a virtual task; wherein the first configuration information is stored by the first driver in a first video memory employing a first communication protocol; the first configuration information is sent to the first driver by the second driver; the configuration information stored in the first video memory is used for version negotiation of the first driver and the firmware by adopting a first communication protocol.

In some embodiments of the present application, the firmware unit 21 is further configured to use the second communication protocol to read an online notification of the intermediary virtual machine in the second video memory; the online notification of the intermediate virtual machine is obtained by converting data of the online notification machine of the virtual machine by the first driver, and a data format of the online notification of the intermediate virtual machine conforms to the second communication protocol; determining drive identification information corresponding to the first drive according to the virtual machine online notification; the drive identification information has a corresponding relation with the second drive; and reading the first configuration information of the second driver corresponding to the driver identification information in the first video memory by adopting the first communication protocol.

In some embodiments of the present application, the firmware unit 21 is further configured to send, to the server, the resource of the virtual device created for the virtual machine, using the third communication protocol, if the first configuration information matches the configuration information of the firmware.

In some embodiments of the present application, the firmware unit 21 is further configured to write, in response to the first driver writing first preset information in the second video memory, second preset information in the second video memory; the data format of the first preset information conforms to the first communication protocol; the data format of the second preset information conforms to the communication protocol specified by the firmware.

In some embodiments of the present application, the firmware unit 21 is further configured to read first indication information written in the second video memory by the first driver; the first indication information is used for indicating that the handshake between the first driver and the firmware is successful; and responding to the first indication information, and writing own version information into the second video memory.

In some embodiments of the application, the first information and the second information comprise at least one of: address information of the video memory, version information of the drive, and type information of the drive.

Those skilled in the art will appreciate that the above description of the graphics processor of an embodiment of the present application may be understood with reference to the description of the communication method driven by an embodiment of the present application.

Fig. 12 is a schematic structural diagram of an electronic device 30 according to an embodiment of the present application. As shown in fig. 12, the electronic device 30 includes a processor 31 and a memory 32, the memory 32 may store a computer program, and the processor 31 may call and run the computer program from the memory 32 to implement the method in the embodiment of the present application.

The memory 32 may be a separate device independent of the processor 31 or may be integrated in the processor 31.

In some embodiments of the present application, as shown in fig. 12, the electronic device 30 may further include a transceiver 33, and the processor 31 may control the transceiver 33 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 33 may include a transmitter and a receiver, among others. The transceiver 33 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, wherein the electronic device may comprise the server 10 of any of the previous embodiments; alternatively, the electronic device may comprise a graphics processor 20 as described in any of the previous embodiments.

Fig. 13 is a schematic structural diagram of a chip according to an embodiment of the present application. As shown in fig. 13, the chip 40 includes a processor 41, and the processor 41 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. 13, the chip 40 may also include a memory 42. Wherein the processor 41 may call and run a computer program from the memory 42 for implementing the method in an embodiment of the application.

The memory 42 may be a separate device independent of the processor 41 or may be integrated in the processor 41.

In some embodiments of the application, the chip 40 may also include an input interface 43. The processor 41 may control the input interface 43 to communicate with other devices or chips, and specifically may acquire information or data sent by the other devices or chips.

In some embodiments of the present application, the chip 40 may also include an output interface 44. Wherein the processor 41 may control the output interface 44 to communicate with other devices or chips, 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 the graphics processor 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. 14 is a schematic block diagram of a communication system 50 provided in an embodiment of the present application. As shown in fig. 14, the communication system 50 includes a server 10 and a graphic processor 20.

Wherein the server 10 may be used to implement the corresponding functions implemented by the server in the above-described method, and the graphics processor 20 may be used to implement the corresponding functions implemented by the graphics processor 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 graphics processor 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 graphics processor 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 the graphics processor in the embodiments of the present application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the graphics processor 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 the graphics processor 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 graphics processor in the methods 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.

Claims

1. The communication method of the drive is characterized by being applied to a server, wherein the server runs a first drive and a virtual machine, and the virtual machine runs a second drive; the method comprises the following steps:

in the process of starting the virtual machine, a first communication protocol is adopted, and the first configuration information of the virtual machine, which is sent by the second drive, is stored into a first video memory through the first drive; the configuration information stored in the first video memory is used for version negotiation between the first driver and the firmware;

2. The method of claim 1, wherein after storing the first configuration information thereof transmitted by the second driver in the first memory by the first driver, the method further comprises:

And generating the virtual machine online notification through the first driver by adopting the first communication protocol.

3. The method according to claim 1, wherein the method further comprises:

and responding to the virtual machine on-line notification, and adopting a third communication protocol to receive resources of the virtual equipment created by the firmware for the virtual machine based on the first configuration information so as to realize virtual tasks.

4. The method of claim 1, wherein the employing a first communication protocol, before storing, by the first driver, the first configuration information thereof transmitted by the second driver in the first memory, the method further comprises:

when the virtual machine is started, applying for a third video memory through the second drive; and the third video memory is used for storing information of the second driver and the firmware for communication by adopting a third communication protocol.

5. The method of claim 1, wherein the adopting a second communication protocol to write, by the first driver, a virtual machine online notification corresponding to the virtual machine into a second video memory, and implementing communication between the first driver and the firmware, includes:

Converting a data format of the virtual machine online notification corresponding to the virtual machine through the first driver by adopting the second communication protocol to obtain an intermediate virtual machine online notification; the data format of the online notification of the intermediate virtual machine conforms to the second communication protocol;

and writing the online notification of the intermediate virtual machine into the second video memory through the first driver, so that the firmware responds to the online notification of the intermediate virtual machine to read the first configuration information in the first video memory, and the communication between the first driver and the firmware is realized.

6. The method of claim 3, wherein the receiving, in response to the virtual machine online notification, resources of a virtual device created by the firmware for the virtual machine based on the first configuration information using a third communication protocol, comprises:

and under the condition that the first configuration information is matched with the configuration information of the firmware, the third communication protocol is adopted, and the resources of the virtual equipment of the virtual machine, fed back by the firmware in response to the online notification of the virtual machine, are received through the first driver.

7. The method according to claim 1, wherein the method further comprises:

When the server is started, applying for the first video memory and the second video memory through the first drive;

and under the condition that the handshake between the first driver and the firmware is successful and the version information of the first driver and the firmware is consistent, storing second configuration information of the second video memory into the first video memory through the first driver.

8. The method of claim 7, wherein storing, by the first driver, the second configuration information of the second memory into the first memory if the first driver and the firmware handshake are successful and the first driver is consistent with version information of the firmware, comprises:

writing first indication information in the second video memory through the first driver under the condition that the handshake between the first driver and the firmware is successful; the first indication information is used for indicating that the handshake between the first driver and the firmware is successful;

acquiring version information of the firmware written in the second video memory by the firmware in response to the first indication information through the first driver;

and storing second configuration information of the second video memory into the first video memory through the first driver under the condition that the version information of the first driver is consistent with the version information of the firmware.

9. The method of claim 8, wherein the method further comprises, in the event that the first driver and the firmware handshake succeed, prior to writing, by the first driver, first indication information in the second video memory:

writing first preset information into the second video memory through the first drive; the data format of the first preset information conforms to the first communication protocol;

acquiring second preset information written in the second video memory by the firmware in response to the first preset information through the first driver; the data format of the second preset information conforms to the communication protocol specified by the firmware;

and determining the first indication information under the condition that the first preset information and the second preset information meet a preset handshake condition.

10. The method according to any one of claims 1 to 9, further comprising:

the second driver and the firmware realize communication through a third communication protocol, and the communication state of the second driver and the firmware comprises a virtualized state or a non-virtualized state.

11. The method according to any one of claims 1 to 9, wherein,

The first video memory is used for storing first configuration information of the second driver and second configuration information of the first driver.

12. The method according to any one of claims 1 to 9, wherein,

the first configuration information and the second configuration information include at least one of: address information of the video memory, version information of the drive, and type information of the drive.

13. The method according to any one of claims 1 to 9, wherein the second communication protocol and a third communication protocol are compatible with the first communication protocol.

14. The method of any one of claims 1 to 9, wherein the first video memory, the second video memory, and the third video memory are independent of each other.

15. The method of any one of claims 1 to 9, wherein the first drive and the second drive communicate via separate channels.

16. The method of claim 1, wherein storing, by the first driver, the first configuration information sent by the second driver in the first memory using the first communication protocol, comprises:

receiving the first configuration information sent by the second driver through the first driver;

Converting the data format of the first configuration information through the first driver to obtain intermediate first configuration information, and writing the intermediate first configuration information into the first video memory; the data format of the intermediate first configuration information complies with the first communication protocol.

17. A method of driven communication, applied to a graphics processor running firmware, the method comprising:

in the process of starting the virtual machine, a second communication protocol is adopted, and the first configuration information of the second drive is obtained through the firmware in response to the virtual machine on-line notification written in the second video memory by the first drive;

based on the first configuration information, a third communication protocol is adopted to send resources of virtual equipment created for the virtual machine to a server so as to realize a virtual task; wherein,

the first configuration information is stored in a first video memory adopting a first communication protocol by the first driver; the first configuration information is sent to the first driver by the second driver; the configuration information stored in the first video memory is used for version negotiation between the first driver and the firmware.

18. The method of claim 17, wherein the obtaining, by the firmware, the first configuration information of the second driver in response to the virtual machine online notification written in the second memory by the first driver using the second communication protocol comprises:

Reading an on-line notification of the intermediate virtual machine in the second video memory through the firmware by adopting the second communication protocol; the online notification of the intermediate virtual machine is obtained by converting data of the online notification of the virtual machine by the first driver, and a data format of the online notification of the intermediate virtual machine conforms to the second communication protocol;

determining drive identification information corresponding to the first drive through the firmware according to the virtual machine online notification; the drive identification information has a corresponding relation with the second drive;

and reading the first configuration information of the second driver corresponding to the driver identification information in the first video memory through the firmware by adopting the first communication protocol.

19. The method of claim 17, wherein the sending, based on the first configuration information, the resources of the virtual device created for the virtual machine to the server using a third communication protocol comprises:

and under the condition that the first configuration information is matched with the configuration information of the firmware, adopting the third communication protocol to send the resources of the virtual equipment created for the virtual machine to the server through the firmware.

20. The method of claim 17, wherein the method further comprises:

writing second preset information in the second video memory through the firmware in response to the first preset information written in the second video memory by the first driver; the data format of the first preset information conforms to the first communication protocol; the data format of the second preset information conforms to the communication protocol specified by the firmware.

21. The method of claim 17, wherein the method further comprises:

reading first indication information written in the second video memory by the first driver through the firmware; the first indication information is used for indicating that the handshake between the first driver and the firmware is successful;

22. The method according to any one of claims 17 to 21, further comprising:

23. The method according to any one of claims 17 to 21, wherein the first configuration information and the second configuration information comprise at least one of: address information of the video memory, version information of the drive, and type information of the drive.

24. The method according to any one of claims 17 to 21, wherein the second communication protocol and a third communication protocol are compatible with the first communication protocol.

25. The method of any one of claims 17 to 21, wherein the first video memory, the second video memory, and the third video memory are independent of one another.

26. The method of any one of claims 17 to 21, wherein the first drive and the second drive communicate via separate channels.

27. A server, the server comprising: a driving unit; wherein,

the driving unit is used for storing first configuration information of the virtual machine, which is sent by the second drive, into the first video memory through the first drive by adopting a first communication protocol in the process of starting the virtual machine; the configuration information stored in the first video memory is used for version negotiation between the first driver and the firmware; and writing the virtual machine online notification corresponding to the virtual machine into a second video memory by adopting a second communication protocol, so as to realize the communication between the first driver and the firmware.

28. A graphics processor, the graphics processor comprising a firmware unit; wherein,

The firmware unit is used for responding to the virtual machine on-line notification written in the second video memory by the first driver by adopting a second communication protocol in the process of starting the virtual machine, and acquiring the first configuration information of the second driver by the firmware; based on the first configuration information, a third communication protocol is adopted to send resources of virtual equipment created for the virtual machine to a server so as to realize a virtual task; wherein,

29. 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 driven communication method of any of claims 1 to 16; alternatively, a communication method of driving according to any one of claims 17 to 26 is performed.

30. A chip, comprising: a processor for calling and running a computer program from a memory, so that a device on which the chip is mounted performs the communication method of the drive according to any one of claims 1 to 16; alternatively, a communication method of driving according to any one of claims 17 to 26 is performed.

31. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program which, when executed by at least one processor, implements the driven communication method according to any one of claims 1 to 16; alternatively, a communication method implementing the drive of any one of claims 17 to 26.