Data interaction method and server

Abstract

The invention provides a data interaction method and a server, a management processor in the server is configured with a shared memory space mapped to a main processor, and the shared memory space comprises a first interaction area and a second interaction area; the first firmware running on the main processor sends first request data to the first interaction area, and controls the interaction flag bit to be at a first state value; second firmware running on the management processor monitors that the interaction flag bit is in a first state value, first request data in the first interaction area are obtained, first response data matched with the first request data are obtained based on the first request data, the interaction flag bit is restored to a second state value, and the first response data are sent to the second interaction area; and sending the first response data to the second interaction area, so that the first firmware obtains the first response data matched with the first request data in the second interaction area. Wherein the request data and the response data conform to intelligent platform management interface protocol specifications.

Description

Technical Field

[0001] The present application mainly relates to the field of server communication technology, and more specifically to a data interaction method and a server. Background Art

[0002] In the field of server communication, BMC (Board Management Controller) is usually used to query and manage server hardware. During the server startup phase and system operation phase, information exchange between BMC and BIOS (Basic Input Output System) is realized through IPMI (Intelligent Platform Management Interface) service.

[0003] Among them, the IPMI commands for interaction between the BIOS and BMC in the server band are currently transmitted using the KCS (Keyboard Controller Style) interface of the server hardware. However, the slow I / O transmission method used by the KCS interface increases the interaction time of each IPMI command, affecting the boot speed and system response efficiency. Summary of the invention

[0004] In order to solve the above technical problems, this application provides the following technical solutions:

[0005] A first aspect of the present application provides a data interaction method, which is applied to a first firmware, and the method includes:

[0006] Sending first request data to the first interaction area, controlling the interaction flag to be in a first state value; the interaction flag being in the first state value indicates that the first interaction area stores request data to be processed;

[0007] Acquire first response data matching the first request data in the second interaction area;

[0008] The first firmware runs on the main processor of the server and is used to guide the system startup of the server, and the second firmware runs on the management processor of the server;

[0009] The first interaction area and the second interaction area are shared memory spaces in the management processor that are mapped to the main processor;

[0010] The request data and the response data both comply with the intelligent platform management interface protocol specification.

[0011] In a possible implementation, the method further includes:

[0012] After the control interaction flag is in a first state value, sending at least one second request data to the first interaction area;

[0013] Before the life cycle of the first firmware ends, the step of obtaining first response data matching the first request data in the second interaction area is performed, and second response data matching each of the at least one second request data in the second interaction area is obtained.

[0014] In a possible implementation, the method further includes:

[0015] confirming a first operation mode of a first interaction area;

[0016] If the first operation mode is a first mode value, prohibiting the execution of operations on the first interaction area;

[0017] If the first operation mode is the second mode value, updating the first operation mode to the first mode value, executing the step of sending the first request data to the first interaction area, and restoring the first operation mode to the second mode value;

[0018] confirming a second operation mode of the second interaction area;

[0019] If the second operation mode is the first mode value, prohibiting the execution of operations on the second interactive area;

[0020] If the second operation mode is the second mode value, the second operation mode is updated to the first mode value, the step of obtaining the first response data matching the first request data in the second interaction area is performed, and the second operation mode is restored to the second mode value.

[0021] In a possible implementation, the method further includes at least one of the following:

[0022] If the response flag bit configured in any request data sent by the first firmware is a first state value, after obtaining response data matching the request data in the second interaction area, the next request data is sent to the first interaction area;

[0023] If the response flag bit of any request data sent by the first firmware is a second state value, stop executing the step of obtaining response data matching the request data in the second interaction area, and send the next request data to the first interaction area;

[0024] If the number of request data in the first interaction area is less than the first number threshold, executing the step of sending the first request data or the second request data to the first interaction area to increase the number of request data in the first interaction area;

[0025] If any response data is successfully obtained, the request data matching the response data in the first interaction area and the response data in the second interaction area are deleted to reduce the number of request data in the first interaction area and the number of response data in the second interaction area.

[0026] A second aspect of the present application provides a data interaction method, which is applied to a second firmware, and the method includes:

[0027] It is detected that the interaction flag is in a first state value, and first request data from the first firmware in the first interaction area is obtained;

[0028] Based on the first request data, obtaining first response data matching the first request data;

[0029] Restoring the interaction flag to a second state value, and sending the first response data to a second interaction area;

[0030] The first firmware is deployed on the main processor of the server to guide the system of the server to start and run, and the second firmware is deployed on the management processor of the server;

[0031] The first interaction area and the second interaction area are shared memory spaces in the management processor that are mapped to the main processor;

[0032] The request data and the response data both comply with the intelligent platform management interface protocol specification.

[0033] In a possible implementation, the method further includes:

[0034] In the case where it is detected that the interaction flag is in the first state value, obtaining at least one second request data from the first firmware in the first interaction area;

[0035] Before restoring the interaction flag to the second state value, obtaining second response data that matches each of the at least one second request data based on the at least one second request data;

[0036] If response data matching all acquired request data are obtained, the step of restoring the interaction flag to the second state value, sending the first response data to the second interaction area is performed, and the second response data is sent to the second interaction area.

[0037] In a possible implementation, when it is detected that the interaction flag is in the first state value, obtaining the request data from the first firmware in the first interaction area includes any one of the following:

[0038] If it is detected that the interaction flag is switched from the second state value to the first state value, interrupting the task currently executed by the second firmware and obtaining the request data from the first firmware in the first interaction area;

[0039] If it is detected that the state value of the interaction flag bit has not been switched and is the first state value, obtaining the request data from the first firmware in the first interaction area;

[0040] The request data from the first firmware includes at least one of the first request data and the second request data.

[0041] In a possible implementation, the method further includes at least one of the following:

[0042] If it is confirmed that the response flag bit of any request data is in the first state value, after obtaining the response data matching the request data, directly sending the response data to the second interaction area;

[0043] If it is confirmed that the response flag bits of each request data are in the second state value, to obtain the response data matching the each request data;

[0044] If it is confirmed that the first operation mode of the first interactive area is the second mode value, the first operation mode is updated to the first mode value, the step of obtaining the request data from the first firmware in the first interactive area is performed, and the first operation mode is restored to the second mode value;

[0045] If it is confirmed that the second operation mode of the second interaction area is the second mode value, the second operation mode is updated to the first mode value, and the step of sending the obtained response data to the second interaction area is performed to restore the second operation mode to the second mode value;

[0046] If it is confirmed that the amount of response data in the second interaction area is less than a second amount threshold, executing a step of sending the obtained response data to the second interaction area to increase the amount of response data in the second interaction area;

[0047] If it is confirmed that any request data is successfully obtained from the first interaction area, the request data in the first interaction area is deleted to reduce the amount of request data in the first interaction area.

[0048] A third aspect of the present application provides a server, the server comprising: a main processor, a management processor, a first firmware and a second firmware, wherein:

[0049] The management processor is configured with a shared memory space mapped to the main processor, the shared memory space comprising a first interaction area and a second interaction area;

[0050] The first firmware runs on the main processor, and is used to send first request data to the first interaction area, control the interaction flag to be in a first state value, and obtain first response data matching the first request data in the second interaction area;

[0051] The second firmware runs on the management processor, and is used for detecting that the interaction flag is in a first state value, obtaining the first request data in the first interaction area, obtaining first response data matching the first request data based on the first request data, restoring the interaction flag to a second state value, and sending the first response data to the second interaction area;

[0052] Wherein, the request data and the response data both comply with the intelligent platform management interface protocol specification;

[0053] The interaction flag being in the first state value indicates that the first interaction area stores request data to be processed.

[0054] In a possible implementation, the shared memory space is part of the video memory space of the second firmware;

[0055] Each request data in the first interaction area and each response data in the second interaction area are stored in a queue storage structure;

[0056] The first firmware and the second firmware communicate with each other via a computer peripheral device interconnection bus;

[0057] The interaction flag bit is configured in a flag register. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the accompanying drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and that components and elements are not necessarily drawn to scale.

[0059] Figure 1 This is a schematic diagram of the structure of the server proposed in Example 1 of the present application;

[0060] Figure 2 A schematic diagram of a first firmware and a second firmware in a server applicable to the first embodiment of the present application communicating based on a shared memory space;

[0061] Figure 3 This is a schematic diagram of the structure of the server proposed in Example 2 of the present application;

[0062] Figure 4 A schematic diagram of the signaling flow of the data interaction method proposed in Example 1 of the present application;

[0063] Figure 5 This is a schematic diagram of the signaling flow of the data interaction method proposed in Example 2 of the present application;

[0064] Figure 6 A schematic diagram of an asynchronous communication process applicable to the data interaction method proposed in Embodiment 4 of the present application;

[0065] Figure 7 A schematic diagram of a synchronous communication process applicable to the data interaction method proposed in Embodiment 4 of the present application;

[0066] Figure 8 This is a flow chart of the data interaction method proposed in Example 3 of the present application;

[0067] Fig. 9 This is a schematic diagram of the signaling flow of the data interaction method proposed in Embodiment 4 of the present application;

[0068] Fig.10 A schematic diagram of a storage format of request data applicable to the data interaction method proposed in the fourth embodiment of the present application;

[0069] Fig.11 A schematic diagram of a storage format of response data applicable to the data interaction method proposed in the fourth embodiment of the present application;

[0070] Fig.12 A schematic diagram of data interaction between the first firmware and the second firmware proposed in this application;

[0071] Fig.13 This is a schematic diagram of the structure of the data interaction device proposed in Example 1 of the present application;

[0072] Fig.14 This is a schematic diagram of the structure of the data interaction device proposed in Example 2 of the present application. DETAILED DESCRIPTION

[0073] The embodiments of the present application are described below in conjunction with the drawings in the embodiments of the present application. The terms used in the implementation mode of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application. It is known to those skilled in the art that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0074] In addition, the terms "first", "second" etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and need not be used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, which is only to describe the distinction mode adopted by the objects of the same attributes when describing in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units or modules, but may include other units or modules that are not clearly listed or inherent to these processes, methods, products or equipment.

[0075] Regarding the data interaction method described in the background technology section, during the information interaction process between the server's BMC (Board Management Controller) and BIOS (Basic Input Output System), due to the tight coupling of the interaction through the KCS (Keyboard Controller Style) interface, each IPMI (Intelligent Platform Management Interface) command needs to wait for the response of the BMC before the BIOS can send the next IPMI command, resulting in the interaction time of each IPMI command being as short as 50ms (milliseconds) and as long as hundreds of milliseconds. During the server startup process, the interaction time between the BIOS and the BMC reaches about 20s, accounting for about 10%-25% of the entire system startup time, reducing the startup speed. In addition, during the operation of the operating system, there will be a delay of 50ms or more in recording the system error log, which will cause obvious network delays to the operating system, reduce the response speed, and seriously affect the user experience.

[0076] In order to improve the above problems, it is proposed to use BT (Block Transfer) transmission mode to replace the Byte-based transmission mode to increase the data transmission rate. However, this method is more complicated than IPMI commands in data organization, and its reading and writing nature is still in the form of I / O transmission. The efficiency improvement is very limited, especially for SEL (Selector, a data type that indicates the storage location of the method) data. The write rate remains basically unchanged and cannot meet the needs of efficient data interaction.

[0077] In addition, it is also proposed to adopt the SSIF (SmBus System Interface, System Management Bus Interface) transmission method, that is, SmBus ( The system management bus (SmBus) is used as the transmission medium to realize data interaction. Since the transmission rate in the data interaction process mainly depends on the SmBus protocol, the SmBus supported by the BMS chip and capable of achieving high transmission rate can be used to improve the boot speed. However, since different BMC chips support different protocols and are highly dependent on the cooperation of the host side, the transmission rate improvement effect of this data interaction method is not obvious and cannot meet the needs of efficient interaction.

[0078] In order to solve the above technical problems, an embodiment of the present application proposes a data interaction method, which pre-builds a shared memory space between the processors running the BIOS and BMC of the server, respectively. The shared memory space set by the management processor running the BMC can be mapped to the main processor running the BIOS, and a first interaction area for storing request data and a second interaction area for storing response data are configured in the shared memory space. The request data and the response data both comply with the IPMI protocol specification. Based on this, when the BIOS and the BMC perform information interaction, it can be directly implemented based on the shared memory space, that is, the BIOS can send the request data to the first interaction area for storage, the BMC obtains the request data from the first interaction area, and sends the matching response data obtained based on the request data to the second interaction area. The BIOS can directly obtain the response data from the second interaction area to complete the information interaction. Compared with the traditional I / O transmission method, this transmission method based on the shared memory space does not require kernel copying, has an extremely high data transmission rate, and can even achieve an order of magnitude increase in data transmission rate, greatly shortening the interaction time of each IPMI command, and improving the boot speed and system response efficiency.

[0079] In combination with the above analysis, a server applicable to the data interaction method proposed in this application will be introduced in detail with reference to the accompanying drawings.

[0080] Reference Figure 1 , is a schematic diagram of the structure of the server proposed in Example 1 of the present application, such as Figure 1 As shown, the server may include a main processor 110, a management processor 120, a first firmware 130 and a second firmware 140, wherein:

[0081] The main processor 110 may be a central processing unit (CPU), which is a core component of the server and is usually responsible for executing instructions, processing data, and controlling the operation of the entire system. It has high performance, high reliability, and a multi-core design to meet the server's requirements for computing power, concurrent processing, and data processing efficiency. The present application does not limit the type and internal structure of the main processor 110, which can be determined based on the server's work requirements. For example, for servers with different performance requirements, the main processor 110 may be an Intel Xeon series processor that meets the corresponding performance requirements; for servers in a data center or cloud computing environment, the main processor 110 may be an AMD EPYC series processor, etc.

[0082] The management processor 120 can configure a memory area as a shared memory space mapped to the main processor 110, so that the firmware running on the two processors 120 can directly read and write data therein, without the need to copy data through the system kernel, thereby reducing the overhead of data copying and context switching and improving data transmission efficiency. Among them, the shared memory space includes one or more registers, and the present application does not elaborate on the memory mapping implementation method.

[0083] In the present application embodiment, Figure 2 As shown, the shared memory space configured by the management processor 120 is divided into two interactive areas, namely, a first interactive area and a second interactive area. The first interactive area can be used to store request data that complies with the IPMI protocol specification for reading by the second firmware 140, and the second interactive area can be used to store request data response data that complies with the IPMI protocol specification for reading by the first firmware 130. The implementation process can refer to the description of the data interaction method embodiment below, and this embodiment will not be described in detail here. In this way, corresponding independent channels can be established for the data receiving and sending processes to realize the transmission of corresponding data, which helps to improve the accuracy and reliability of data transmission.

[0084] Need to explain, Figure 2 The IPMI Server and IPMI Main are two important concepts in the IPMI system, and play an important role in server management and monitoring. Among them, IPMI Server can be a hardware-based management function, which can be used to realize remote monitoring and management of the server. In the embodiment of the present application, it can be used to start the IPMI function, and can also access the IPMI management interface, etc., so as to realize access to the shared memory space through the started IPMI function. The access process is not described in detail in this application. IPMI Main is the core module or main program that implements the IPMI function in the BMC, which is responsible for processing IPMI commands (i.e., commands defined by the IPMI protocol), monitoring hardware status, providing remote management functions, and managing user permissions.

[0085] In an embodiment of the present application, the second firmware 140 can receive and process IPMI commands through IPMI Main, such as obtaining request data stored in the first interaction area for processing; the first firmware 130 can write the request data into the first interaction area and read the response data stored in the second interaction area through the IPMI Server. The implementation process is not described in detail in this application.

[0086] In a possible implementation, each request data in the first interaction area and each response data in the second interaction area can be stored in a queue storage structure. Therefore, as shown in 2, the first interaction area can store a request data queue (Request Queue), and the second interaction area can store a response data queue (ResponseQueue). In the data interaction method proposed in this application, the data queues stored in each of the two interaction areas can follow the First In First Out (FIFO) principle, so that the data first written into the corresponding data queue can be returned to the receiving end first, simplifying data reading and writing operations and improving the reliability and security of data transmission. Of course, the data of each of the two interaction areas can also be stored in other types of data structures, such as linked lists, arrays or tables, and are not limited to the data structure of data queues.

[0087] In the embodiment of the present application, the main processor 110 and the management processor 120 can be connected via PCIe (Peripheral Component Interconnect Express) to form a PCIe physical link, which supports the communication between the first firmware 130 and the second firmware 140, greatly improves the IPMI command transmission speed between the two firmwares, and reduces hardware costs. In addition, independent PCIe physical links can be established for the first interactive area and the second interactive area of ​​the shared content space to reduce the impact between data sending and receiving and improve the accuracy and reliability of data transmission. This application does not elaborate on the method of how to implement the PCIe physical link design between the first firmware 130 end and the second firmware 140 end.

[0088] In some embodiments, according to the above analysis, in order to implement the data interaction method proposed in this application, the management processor 120 can first determine the physical address and memory length / size of the shared memory space, such as by configuring the memory controller of the management processor 120 to allocate a memory area as the shared memory space, etc. This application does not limit the method of determining the shared memory space. Afterwards, in the process of configuring the shared memory space mapping, the determined shared memory space can be mapped to the virtual address space of the main processor 110, such as by mapping the mmap system call method to map the shared content space to the virtual address space interface of the process of the main processor 110; the size and starting address of the shared memory space can also be configured through the device tree (Device Tree). This application does not limit the implementation method of the shared memory space mapping, which can be determined in combination with the system architecture adopted by the management processor 120.

[0089] In one possible implementation, during the process of the management processor 120 determining the shared memory space, part of the video memory space can be divided from the video memory space of the second firmware 140 and configured as the shared memory space, so as to be mapped to the main processor 110, so that the first firmware 130 running on the main processor 110 can access all physical addresses of the shared memory space through MMIO (Memory-Mapped I / O, memory mapped I / O), and the second firmware 1140 can also access it through memory mapping to support the implementation of the data interaction method proposed in the present application.

[0090] It should be noted that the configuration method of the shared memory space includes but is not limited to the video memory space of the second firmware 140. As needed, part of the storage space of the management processor 120 can be selected as the shared memory space, etc., to support the first firmware 130 and the second firmware 140 to access the shared memory space, thereby realizing fast and efficient transmission of request data and response data.

[0091] In some embodiments, in order to ensure data consistency in the shared memory space, the main processor 110 and the management processor 120 can share the memory area (i.e., the shared memory space) by setting memory attributes, and support the first firmware 130 and the second firmware 140 running in different processors to read and write the shared memory space respectively, and each firmware can directly access the shared memory space through pointers, etc. In some scenarios, in order to achieve synchronous communication, a synchronization mechanism can be provided for the shared memory space through synchronization means such as semaphores or mutexes, and the implementation process is not described in detail in this application.

[0092] During actual use of the server, the management processor 120 can be used to monitor and manage the hardware status and operation of the server, such as remote monitoring and management, hardware status monitoring, fault diagnosis, power management, logging and event management, virtual media support, security management and independent operation (i.e., a system independent of the main processor 110 and the operating system, so that it can still operate normally and provide management functions when the main processor 110 and the operating system fail). One or more management functions.

[0093] In the embodiment of the present application, the management processor 120 may also be referred to as a BMC chip, such as an ARM chip (i.e., a BMC chip with an ARM architecture), a MIPS (Microprocessor without interlocked piped stagesarchitecture, a processor architecture using a reduced instruction set (RISC)) chip or other microcontrollers, or an ME (Management Engine) microprocessor, or other dedicated processors, etc., which can be determined based on actual conditions. The present application does not impose any restrictions on the type of the management processor 120 and its internal structure.

[0094] The first firmware 130 can run on the main processor 110. The first firmware 130 can be used to send first request data to the first interaction area, control the interaction flag to be in a first state value, and obtain first response data matching the first request data in the second interaction area. The implementation process can refer to the implementation steps of the data interaction method described below from the first firmware 130 side, and the embodiments of the present application will not be described in detail here.

[0095] Among them, the interaction flag bit being in the first state value indicates that the first interaction area stores request data to be processed, and the interaction flag bit being in the second state value indicates that the first interaction area does not store request data, so that the second firmware 140 can determine whether the first interaction area stores request data to be processed by reading the current state value of the interaction flag bit, such as the first state value or the second state value, to achieve effective data reading of the first interaction area. It should be noted that this application does not limit the contents of the first state value and the second state value, such as 1 or 0, etc., and the first firmware 130 and the second firmware 140 need to know in advance the above meanings represented by different state values.

[0096] In one possible implementation, Figure 3As shown, the above-mentioned interaction flag is configured in the flag register 150, and the flag register 150 can be used to record the status information of the first interaction area of ​​the shared memory space, such as whether there is request data to be processed stored, and the corresponding status information can be represented by different status values ​​of the pre-defined interaction flag. In actual applications, after writing the request data to the first interaction area, the status value of the interaction flag can be set to the first status value in time, so that the second firmware 140 can recognize the status value and determine whether the request data can be obtained from the first interaction area for processing. This application does not limit the configuration implementation method of the interaction flag.

[0097] The second firmware 140 can run on the management processor 120, and is used to detect that the interaction flag is in the first state value, obtain the first request data in the first interaction area, obtain the first response data matching the first request data based on the first request data, restore the interaction flag to the second state value, and send the first response data to the second interaction area. The specific implementation process can refer to the implementation steps of the data interaction method described below from the second firmware 140 side, and the embodiment of the present application will not be described in detail here.

[0098] In an embodiment of the present application, the first firmware 130 may be BIOS, or UEFI (Unified Extensible Firmware Interface, also known as EFI) which is used to replace BIOS. The second firmware 140 may be BMC, which may be responsible for managing the interface between system management software and platform hardware, and providing query, control and data transmission functions to the host side through a network, serial or other interface. In actual applications, BMC runs independently of the CPU and operating system of the server, and starts immediately after the server is powered on. Even if the server is in a shutdown state, BMC can be remotely managed through the network. The implementation process is not described in detail in this application.

[0099] Taking the scenario where the first firmware 130 is BIOS and the second firmware 140 is BMC as an example, during the server startup process, the BIOS and BMC are started separately and independently, and the BMC will start before the operating system so as to start monitoring and managing the hardware status of the server before the operating system starts. The BIOS starts when the server is powered on, usually after the BMC starts. The BIOS is the core of the server hardware initialization and is responsible for executing POST (Power On Self Test) to detect whether the hardware devices are working properly. During the server startup process, the BMC can set the BIOS startup options (such as startup sequence, startup device, etc.) through IPMI commands. When the BIOS starts, it can obtain these settings from the BMC through IPMI commands and adjust the startup sequence accordingly. If the BIOS modifies the startup sequence or settings, the modified startup sequence and settings can be synchronized to the BMC through IPMI commands. The data interaction method proposed in this application can be used in this implementation process.

[0100] It should be understood that Figure 1-Figure 3 The structures of the servers shown in each figure do not limit the hardware structure of the server proposed in this application. In actual applications, more devices than those shown in the drawings may be included, such as other processors, memories, or various communication elements, etc., to meet the business processing requirements of the server. This application will not describe them in detail here.

[0101] In combination with the composition structure and functions of the server described in the above embodiments, the data interaction method provided in the embodiments of the present application will be introduced in detail below.

[0102] Reference Figure 4 , which is a signaling flow diagram of the data interaction method proposed in the first embodiment of the present application, can be applied to the server as described above. This embodiment describes the data interaction method between the first firmware and the second firmware of the server. The request data and response data transmitted interactively between the two firmwares comply with the IPMI protocol specification. As analyzed above, the first firmware runs on the main processor of the server and is used to guide the system startup of the server. The second firmware runs on the management processor of the server, and the shared memory space in the management processor that is mapped to the main processor includes the first interaction area and the second interaction area. Based on this, Figure 4 As shown, the data interaction method proposed in this embodiment may include but is not limited to the following steps:

[0103] Step S410, the first firmware sends first request data to the first interaction area, and controls the interaction flag to be in a first state value;

[0104] In the embodiment of the present application, the first request data may be an IPMI command that needs to be processed by the second firmware during the information exchange between the first firmware and the second firmware. For example, during the server startup process, a configuration request for each boot option of the first firmware is made to request to set the boot order or boot device in the POST phase. Figure 2 As shown, the first firmware can send the first request data that needs to be processed by the second firmware to the first interaction area of ​​the shared memory space through the IPMI Server.

[0105] Since the shared memory space has been mapped to the main processor running the first firmware, the first firmware knows the physical address corresponding to the first interaction area in the shared memory space, and can access the first interaction area through MMIO to write the first request data into the first interaction area, such as writing the first request data into a request data queue (Request Queue). The implementation process is not described in detail in this application.

[0106] In order to clarify whether the current first interaction area stores request data to be processed, an interaction flag for the first interaction area can be configured to be represented by different state values ​​of the interaction flag. For example, if the interaction flag is in a first state value (such as 1, etc.), it indicates that the first interaction area stores request data to be processed; if the interaction flag is in a second state value (such as 0, etc.), it indicates that the first interaction area does not store request data to be processed. The present application does not limit the configuration or update implementation method of different state values ​​of the interaction flag.

[0107] Among them, the first request data can be any request data sent by the first firmware. The present application may include but is not limited to various hardware status monitoring requests, system management instructions, event log record query requests and configuration requests for the first request data. The present application does not limit the content of the first request data. It should be noted that the default state value (i.e., the state value after initialization) of the above-mentioned interaction flag can be the second state value. After the first firmware is started, the first request data is sent to the first interaction area for the first time (such as when the first request data is the first time to send the request data) to control the interaction flag from the current second state value to the first state value. The subsequent non-first time request data is sent (such as when the first request data is not the first time to send the request data) to the first interaction area can maintain the interaction flag in the first state value. Of course, the interaction flag can also be set once (such as a set 1 operation) to set the interaction flag to the first state value.

[0108] Step S420: the second firmware detects that the interaction flag is in the first state value, and obtains the first request data in the first interaction area;

[0109] Step S430, the second firmware obtains first response data matching the first request data based on the first request data;

[0110] Combined with the above description of the meaning of the interaction flag being in the first state value, after the second firmware is started, if it is detected that the interaction flag is in the first state value, it is determined that the first interaction area stores request data to be processed, and the request data such as the first request data mentioned above can be obtained. In actual applications, the first interaction area may also store other request data to be processed at this time, and the second firmware can read each request data simultaneously or sequentially. The embodiment of this application only takes the interaction process of the first request data as an example for explanation.

[0111] In some embodiments, during the process of the second firmware acquiring the request data in the first interaction area, for each request data in the first interaction area, a cutting method can be used, that is, when each request data in the first interaction area is read, the request data is directly no longer stored in the first interaction area. Optionally, the second firmware can also delete the request data that has been read in the first interaction area after reading each request data stored in the first interaction area, so as to save storage resources of the first interaction area. Alternatively, the second firmware can also delete the request data stored in the first interaction area after obtaining the response data that matches the read request data. In this way, if an exception occurs in the process of obtaining the response data, the request data can be re-read for processing, thereby improving the reliability of data interaction. The implementation method of how the second firmware of the present application acquires the request data stored in the first interaction area is not limited.

[0112] In the embodiment of the present application, after the second firmware reads the first request data from the first firmware, it can perform corresponding operations based on the request content described by the first request data to obtain the first response data matching the first request data. Exemplarily, based on the hardware status query request from the first firmware, the monitored hardware status information (such as temperature, voltage, or fault alarm information such as overheating / voltage abnormality, etc.) is fed back as response data, so that the first firmware can determine whether to continue to start the hardware or report an error to the hardware, etc.; based on the system restart / shutdown instruction from the first firmware, the system restarts / shutdown is controlled, and the corresponding response data is fed back; based on the configuration request from the first firmware, the version information of the first firmware is read, and after the remote inspection by the management personnel, the inspection result is fed back as response data; based on the firmware update request from the first firmware, the update data of the first firmware is obtained as response data feedback to implement the version update of the first firmware, etc.

[0113] It can be seen that for the first request data with different request contents, the second firmware performs different operations accordingly, and the implementation methods of obtaining the first response data matching therewith are different. This application does not limit the implementation method of step S430, which can be determined according to the circumstances.

[0114] Step S440, the second firmware restores the interaction flag bit to the second state value, and sends the first response data to the second interaction area;

[0115] Step S450: the first firmware obtains first response data matching the first request data in the second interaction area.

[0116] Following the above analysis, after the second firmware successfully obtains the response data that matches the acquired request data, it can promptly restore the status value of the interaction flag from the first status value to the second status value (such as switching from 1 to 0, or directly setting the interaction flag to 0, etc.), so that the status value of the interaction flag can correctly indicate whether there is request data to be processed stored in the first interaction area, and avoid the situation where the second firmware continues to read the request data from the first interaction area based on the identified first status value due to the untimely update of the status value of the interaction flag, but at this time there is no request data to be processed in the first interaction area, resulting in a waste of reading resources and affecting the response speed. If the processed request data is read at this time, it will cause repeated processing and obtain repeated response data, which will interfere with the first firmware.

[0117] After the second firmware obtains the first response data matching the first request data according to the method described above, in order to enable the first firmware to obtain the first response data in a timely and accurate manner, the second firmware may also write the first response data into the second interaction area of ​​the shared memory space, so that the second firmware can quickly and accurately obtain the first response data matching the first request data from the second interaction area, so as to perform subsequent operations.

[0118] It should be noted that the present application does not restrict when the first firmware obtains the first response data matching the first request data from the second interaction area after sending the first request data to the first interaction area for storage. This can be determined based on the business requirements of the server under the current business scenario, or by pre-configured interaction rules of the system.

[0119] In the process of implementing the data interaction method described above, for the interactive information such as various request data and response data transmitted between the first firmware and the second firmware, IPMI command interaction can be realized based on the PCIe physical link design of the shared memory space, so that the first firmware and the second firmware can realize IPMI command transmission through the PCIe physical link. PCIe is an efficient communication mechanism, so that the transmission method of the shared memory space based on the PCIe physical link design proposed in this application greatly improves the IPMI command transmission rate compared to the traditional I / O transmission method, such as an order of magnitude increase in transmission rate, which can reliably meet high bandwidth or low latency scenarios. And there is no need for KCS and BT interfaces, reducing hardware costs.

[0120] Among them, in the case of implementing the data interaction method proposed in this application based on the PCIe communication mode between the first firmware and the second firmware, for the IPMI format data (such as control instructions or data, etc.) sent by the two firmwares to the shared memory space for storage, the IPMI format data to be transmitted can be processed into a data packet that complies with the PCIe bus standard and then sent. This application does not limit the construction process and structural requirements of the data packet, which can be determined according to the situation. In addition, this application uses a PCIe physical link to realize the transmission of IPMI format data, which can not only increase the amount of data (such as realizing the rapid transmission of batch data), but also can use the IPMI protocol to transmit some commands that are not suitable for transmission using the IPMI protocol, such as firmware upgrade packages, etc., thereby improving the universality of IPMI command transmission.

[0121] Reference Figure 5 , which is a signaling flow diagram of the data interaction method proposed in the second embodiment of the present application. In order to shorten the time for the first firmware to wait for the response data matching the request data sent by it and improve the data interaction efficiency, this embodiment proposes to adopt an asynchronous communication mechanism to realize the data interaction between the first firmware and the second firmware, such as Figure 5 As shown, the data interaction method proposed in this embodiment may include:

[0122] Step S510, the first firmware sends first request data to the first interaction area, and controls the interaction flag to be in a first state value;

[0123] Step S520, the first firmware sends at least one second request data to the first interaction area, and controls the interaction flag to be in a first state value;

[0124] In an embodiment of the present application, after the first firmware sends the first request data to the first interaction area, it can directly send at least one second request data to the first interaction area without waiting for the return of the second firmware. The number of second request data and the order in which each request data is sent can be determined based on actual business needs, and this application does not impose any restrictions.

[0125] Among them, combined with the above description of the interaction flag, the interaction flag can be set once each time a second request data is sent. No matter what state value the interaction flag is currently in, it can be directly configured with the first state value set operation. For example, when the first state value is 1, the interaction flag can be set once each time a request data is sent. Of course, for multiple request data that need to be sent continuously, that is, a request data group to be sent, the interaction flag can be set after the request data group is sent. This application does not limit the implementation method of how to control the state value of the interaction flag so that it can correctly indicate whether the first interaction area stores request data to be processed.

[0126] Step S530: the second firmware detects that the interaction flag is in the first state value, and obtains the first request data and the at least one second request data in the first interaction area;

[0127] Step S540, the second firmware obtains first response data matching the first request data based on the first request data, and obtains second response data matching the at least one second request data based on the at least one second request data;

[0128] Step S550: if the second firmware has obtained response data that matches all the acquired request data, the interaction flag is restored to the second state value;

[0129] Step S560, the second firmware sends the first response data and the second response data to the second interaction area;

[0130] Combined with the above analysis, the second firmware can monitor the status value of the interaction flag. If it is detected that the interaction flag is in the first status value, it means that the first interaction area stores request data to be processed. The various request data currently stored in the first interaction area can be directly read, such as the first request data from the first firmware and the at least one second request data. The present application does not limit the implementation method of obtaining request data from the first interaction area.

[0131] Afterwards, the second firmware can obtain response data matching the request data based on each request data read, and after completing the processing of each request data obtained in a sequential / parallel manner, the corresponding response data is sent to the second interactive area for storage. In this process, the second firmware can directly write the response data to the second interactive area for storage each time it obtains response data matching a request data. During the writing operation, based on the next request data obtained, it obtains response data matching the next request data, and then writes it to the second interactive area for storage. This sequential processing ensures that the first firmware first sends the request data to the first interactive area, and the second firmware can first obtain the response data matching the request data, and write the response data to the second interactive area for storage.

[0132] For example, refer to Figure 6 The flowchart of the data interaction method based on the asynchronous communication mechanism is shown in FIG. 1 , in which the first firmware (such as BIOS) sends the first request data (such as Figure 6 After sending the Request1 shown in the figure to the first interactive area, there is no need to wait for the second firmware (such as BMC) to return the matching first response data (such as Figure 6 Response1 shown in the figure), the next request data (recorded as the second request data) can be sent to the first interactive area. Figure 6 Request2 as shown), according to actual business needs, the next request data (recorded as another second request data, which can be expressed as Request3) can continue to be sent to the first interaction area for storage, and n (which can be an integer greater than 2, usually determined according to actual business needs, and this application does not limit the value of n) request data required by the actual business are sent one by one, which can be expressed as Requesti, that is, the i-th request data sent by the first firmware, i=1, 2, ..., n.

[0133] For the second firmware, when it detects that the interaction flag is in the first state value, it can read the request data to be processed from the first interaction area in time. In a possible implementation, as analyzed above, after reading the first request data Request1, it can obtain the first response data Response1 matching Request1 based on Request1, and send Response1 to the second interaction area for storage. During the sending process of Response1, based on the read Request2, Response2 matching Request2 is obtained, and Response2 is sent to the second interaction area for storage. Repeat the process until a Responsen matching the last read Requestn is obtained, and Responsen is sent to the second interaction area for storage.

[0134] It should be noted that the content and content type of each request data sent by the first firmware may be different, including but not limited to request instructions. For example, one or more of the various hardware status query instructions, various system management instructions, configuration requests, etc. in the above examples can be determined based on actual business needs. For request data with different contents, the implementation methods for obtaining matching response data may be different, and this application does not give detailed examples one by one. Of course, the time intervals between adjacent request data sent may be the same or different, and can also be determined based on actual business operation conditions.

[0135] In one possible implementation, after obtaining response data that matches all request data obtained from the first interaction area, such as the above-mentioned first response data and at least one second response data, the second firmware can write these response data into the second interaction area for storage in the order in which they are obtained (that is, the order in which the request data that matches them are obtained / the order in which they are stored in the first interaction area), so that the second interaction area can store them.

[0136] Still Figure 6 Taking the scenario shown as an example, after the first firmware writes all n request data (i.e., Request1, Request2, ..., Requestn, etc.) that need to be sent to the second firmware for processing in the current business scenario into the first interaction area, the second firmware detects that the interaction flag is in the first state value, and can read the n request data stored in the current first interaction area, obtain the response data (i.e., Response1, Response2, ..., Responsen, etc.) matching each request data, and then write these n response data into the second interaction area in sequence for storage.

[0137] It should be noted that during the implementation process in which the second firmware processes the first request data and the at least one second request data obtained from the first interaction area this time, obtains response data matching each request data, and writes it into the second interaction area, it does not affect the first firmware from continuing to send new request data to the first interaction area. At this time, the interaction flag is still set to the first state value, so that the second firmware continues to read the new request data stored in the first interaction area for processing, and obtains response data matching the new request data, until the first firmware no longer sends request data to the first interaction area. If no new request data is read from the first interaction area within a preset time (which can be configured according to actual business needs, and this application does not limit its value), the interaction flag can be restored to the second state value, and the second firmware then sends each response data obtained at this time to the second interaction area for storage.

[0138] In a possible implementation, when the number of request data that the first firmware needs to transmit to the second firmware in the current business scenario is large, the first firmware can use a batch sending method to send multiple request data to the first interaction area for storage. Compared with the sequential sending method described above, the sending time of multiple request data is shortened and the data interaction efficiency is improved. This application does not limit the implementation method of the first firmware sending multiple request data to the first interaction area for storage, which can be determined based on the data transmission requirements in the actual business scenario.

[0139] Step S570: before the life cycle of the first firmware ends, the first firmware obtains the first response data matching the first request data in the second interaction area, and the second response data matching at least one piece of the second request data.

[0140] As analyzed above, in an actual business scenario where the first firmware and the second firmware perform information interaction, if the first firmware needs to send multiple request data in order to complete the business requirements in the business scenario, such as the self-test requirements in the POST stage, in an embodiment of the present application, the first firmware can send all these multiple request data to the first interaction area of ​​the shared memory space for storage according to the method described above. There is no need to wait for the return of the second firmware after sending a request data before sending the next request data, thereby reducing the interval time between two adjacent request data to be sent. Especially when the number of request data is large, even a batch method can be used to quickly send all request data that need to interact with the second firmware to the first interaction area for storage.

[0141] By monitoring the status value of the interaction flag, the second firmware learns that the first interaction area stores request data to be processed, and can directly read each request data stored in the first interaction area without the need to copy data through the system kernel, thereby improving the request data transmission speed and reducing the data copying overhead. According to the above processing method, the second firmware obtains the response data that matches each of the acquired request data, and directly writes the obtained response data to the second interaction area, without the need for the system kernel to copy data, thereby improving the response data writing efficiency.

[0142] In this way, according to the method described above, the processing of all request data required for the current business scenario is completed. After the second interaction area stores the response data matching each request data, the first firmware can directly perform a data reading operation on the second interaction area before the end of its own life cycle, such as before the end of the POST phase, to read all response data stored in the second interaction area, such as the first response data matching the first request data, and the second response data matching at least one second request data. This process does not require the system kernel to copy data, which greatly improves the response data transmission efficiency.

[0143] It can be seen that in the data interaction method proposed in the embodiment of the present application, the first firmware can directly send all request data that need to be transmitted to the second firmware to the first interaction area for storage, and the second firmware can directly read the first interaction area to quickly obtain each request data. After obtaining each matching response data, it can also be directly written into the second interaction area for storage. In this way, before the end of the life cycle of the first firmware, the first firmware directly reads each response data stored in the second interaction area, that is, all response data are obtained at the same time. Compared with the I / O communication method in which the first firmware sends a request data and waits for the second firmware to return before sending the next request data, the asynchronous communication method adopted in the present application greatly shortens the waiting time for the first firmware to wait for the second firmware to return the response data, and the waiting time for the second firmware to wait for the first firmware to send the next request data, that is, the delay is reduced, the data interaction efficiency between the first firmware and the second firmware is greatly improved, and the boot speed is improved. Especially when the system is powered on, the hot restart boot time can be shortened by 25%, and the normal boot time is also shortened by about 10%, thereby improving the user experience.

[0144] Moreover, in the entire data sending and reading process mentioned above in the present application, there is no need to perform system replication through the system kernel, which greatly improves the data transmission efficiency, and does not require KCS and BT interfaces, reducing hardware costs. In addition, data interaction is carried out through independent data sending channels and data receiving channels for different interaction areas, thereby improving the accuracy of data transmission.

[0145] In some embodiments, when the server is in different business scenarios and implements data interaction between the first firmware and the second firmware to meet its business needs, according to the method described above, for each business scenario (such as the POST stage or its various sub-stages, etc.), the first firmware can directly send all request data that meet its business needs to the first interaction area for storage, and the second firmware reads and obtains the response data that matches each request data, and directly sends it to the second interaction area for storage, so that the first firmware directly reads the response data that matches each request data sent from the first interaction area. Then enter the next business scenario and repeat the steps as follows. Figure 6 The data interaction method shown is used to realize the business requirements of multiple business scenarios. The amount of request data that needs to be interacted in each business scenario may be different.

[0146] Optionally, if in certain business scenarios, there is a dependency relationship between different request data that meet their business needs, for example, only after obtaining response data for one or more specified request data can it be determined which one or more request data to send subsequently. In the entire data interaction method, the communication method described above can also be followed. Based on the shared memory space, the first firmware can first transfer the one or more specified request data to the second firmware. After the second firmware writes the obtained response data matching the specified request data into the second interaction area, the first firmware first obtains the response data from the second interaction area according to the data reading time determined based on the business need, and then continues to send other request data that meets the business need to the first interaction area based on the response data, so that the second firmware reads the other request data from the first interaction area, obtains the matching response data and writes it into the second interaction area, so that the first firmware can continue to read the response data matching the other request data from the second interaction area, and repeats the process until the business need is met.

[0147] In some embodiments, the first firmware may also configure corresponding processing priorities for each request data to be sent according to actual business needs, such as configuring corresponding processing priority identifiers, thereby indicating the processing order of the corresponding request data. In this way, after the second firmware obtains each request data currently stored in the first interactive area, it may determine the processing order of each request data obtained according to the identified processing priority identifier, so as to obtain response data matching the request data based on the request data of the current processing order, so that the request data with a higher processing priority can be processed by the second firmware in a timely manner, and the corresponding response data can be obtained in a timely manner and sent to the second interactive area for storage, so that the first firmware can read the response data with priority.

[0148] In this case, in order to promptly complete the business content corresponding to the request data with a higher processing priority, for the request data configured with a processing priority identifier, the second firmware can give priority to obtaining the response data matching the request data, and can even send the response data to the second interaction area when or before processing other request data, so that the first firmware can read the response data matching the request data in the second interaction area in a timely manner based on the processing needs of the request data with a processing priority identifier, without waiting for obtaining the response data matching each of the other request data, and finally read all the response data in the second interaction area together, so as to reliably meet the business needs in specific business scenarios, such as the business scenario in which request data B can be sent based on the response data A only after obtaining the response data A to the request data A.

[0149] In a possible implementation, a response flag (which can be expressed as ResponseRequired, etc.) can be configured in the request data sent by the first firmware, and the state value of the response flag indicates whether the first firmware needs to wait for the second firmware to feedback response data matching the request data before sending the next request data. In this way, if the response flag configured in any request data sent by the first firmware is the first state value, it means that the first firmware needs to wait for the second firmware to return response data matching the request data, and the first firmware can send the next request data to the first interaction area after obtaining the response data matching the request data in the second interaction area.

[0150] If any request data sent by the first firmware is configured with a response flag having a second state value, it indicates that the first firmware does not need to wait for the second firmware to return response data matching the request data. The first firmware can first stop executing the step of obtaining response data matching the request data in the second interaction area, and continue to send the next request data to the first interaction area. That is to say, at this time, the first firmware does not need to wait for the return of the second firmware, and continuously sends request data to the first interaction area. For each request data sent, the state value of the response flag therein can be judged to determine the timing of sending the next request data.

[0151] Based on the above analysis, in some specific business scenarios of the server, refer to Figure 7 As shown in the flowchart, if the first request data needs to wait for the second firmware to return the response data before the first firmware can continue to send the next request data, that is, for the transmission of the first request data and the first response data matching it, the first firmware and the second firmware need to adopt a synchronous communication method to implement it, such as Figure 7 As shown, after the first firmware writes the first request data directly into the first interaction area, it can suspend sending the next request data and wait for the second firmware to directly write the first response data matching the first request data into the second interaction area. After the first firmware directly reads the first response data from the second interaction area, it will continue to send other request data to the first interaction area. The subsequent data interaction process can continue to use the synchronous communication method according to the actual situation, or it can use the following method: Figure 6 The asynchronous communication method shown is implemented as needed.

[0152] The data stored in the first interactive area and the second interactive area can be stored in a data queue structure. If at least one request data stored in the request data queue needs to be stored in a data queue structure, Figure 7In the synchronous communication mode shown, a Loop processing mechanism can be configured between the request data queue and the response data queue to manage the sending of data requests and the acquisition of response data, thereby ensuring the integrity of the interactive data and the communication reliability between the first firmware and the second firmware.

[0153] In one possible implementation, the first firmware can detect whether specific request data in the request data queue (first interaction area) has been processed based on the Loop processing mechanism. If not, the first firmware can continue to detect through the Loop processing mechanism until the request is completed. When the first firmware reads the response data from the response data queue (second interaction area), it can check the queue in a loop until the complete response data is received. In addition, if an error occurs during the data interaction process, the first firmware can also resend the request data through the Loop processing mechanism. In order to avoid infinite loops, the first firmware can set a timeout mechanism for the reading and writing of each data queue. If it is not completed within the timeout period, error handling can be triggered. The implementation process is not described in detail in this application.

[0154] In addition, in Figure 7 In the data reading and writing process shown, the communication between the first firmware and the second firmware based on the shared memory space can adopt the PCIe communication mode (an efficient communication mode), which improves the data interaction efficiency compared with the traditional I / O communication mode. Since the KCS and BT interfaces are not required, the hardware cost is reduced, and the data reading and data writing each have an independent PCIe physical link, which improves the accuracy and reliability of the data reading and writing operations.

[0155] It should be noted that in the data interaction method described in the above embodiments, the second firmware detects that the interaction flag is in the first state value. If the second firmware is currently processing a task, it can interrupt the current processing task and implement data interaction between the first firmware and the second firmware according to the method described above. After completing the data interaction, the interruption is ended and the second firmware can continue the current processing task that was previously interrupted. The present application does not limit how the second firmware interrupts the current processing task based on detecting that the interaction flag is in the first state value.

[0156] Based on this, refer to Figure 8 The flowchart of the data interaction method proposed in the third embodiment of the present application is shown in FIG. Figure 8 As shown, the data interaction method may include but is not limited to:

[0157] Step S810, if it is detected that the interaction flag is switched from the second state value to the first state value, the task currently executed by the second firmware is interrupted;

[0158] Combined with the above analysis, after the second firmware starts running, it monitors that the interaction flag switches from the second state value to the first state value, indicating that the first interaction area begins to store at least one request data to be processed from the first firmware. This embodiment uses the scenario of storing multiple request data as an example to illustrate. In order to improve the efficiency and timeliness of data interaction between the first firmware and the second firmware, the second firmware can generate an interrupt signal based on the monitoring result, or the interaction flag switches from the second state value to the first state value to trigger the generation of an interrupt signal, etc. The second firmware responds to the interrupt signal, interrupts the current execution of the second firmware, and starts data interaction with the first firmware. This application does not limit the interrupt implementation method.

[0159] In actual applications, during the operation of the second firmware, it is monitored that the state value of the interaction flag has not been switched and is the first state value, indicating that the second firmware has performed at least one data interaction operation according to the method described above, such as obtaining response data that matches the at least one request data based on the at least one request data read. At this time, the second firmware does not perform other tasks and does not need to interrupt the current processing task. It can directly obtain the request data from the first firmware in the first interaction area, and then enter step S830 to perform subsequent operations.

[0160] Step S820, obtaining each piece of request data from the first firmware in the first interaction area;

[0161] Step S830, determining that the response flag bit of each piece of request data is in the second state value, and obtaining response data matching each piece of request data based on each piece of request data;

[0162] Referring to the communication method between the first firmware and the second firmware described in the above embodiment, the second firmware can directly obtain each request data stored in the first interactive area. Usually, the second firmware processes the multiple request data in sequence according to the sending time, that is, the request data first written into the first interactive area is first read by the second firmware. In the process of reading subsequent request data, the second firmware can obtain the response data matching the request data in parallel based on the read request data. Or after reading all the request data stored in the first interactive area together, the matching response data is obtained in sequence according to the corresponding writing time. In some scenarios, multiple request data can also be processed in parallel by multiple threads, so that each thread can obtain its matching response data based on the assigned request data, etc. This application does not limit the process of obtaining the matching response data of multiple request data.

[0163] Among them, in order to avoid that request data with a later writing time but a higher processing priority cannot be processed in time, before processing according to the method described above, the status value of the response flag bit of each request data can be confirmed first. Only when they are all in the second status value, that is, each request data obtained from the first interaction area does not require the first firmware to wait for the second firmware to return, and then the matching response data can be obtained according to the method described above.

[0164] If the response flag of any of the request data is in the first state value, in order to improve the timeliness of data interaction, the request data can be given priority. Even if it is written later and is read later, the second firmware can still obtain the matching response data based on the request data first. After that, it no longer waits for the matching response data of other request data, and directly sends the matching response data of the request data with the response flag in the first state value to the second interaction area. At this time, the first firmware will read the response data of the second interaction area in time to promote the subsequent data interaction process.

[0165] Step S840: if the response data matching each of the acquired request data has been obtained, the interaction flag is restored to the second state value;

[0166] Step S850: Send all the obtained response data to the second interaction area, so that the first firmware can obtain multiple response data matching the sent request data from the second interaction area before its life cycle ends.

[0167] It can be seen that in the embodiment of the present application, the first firmware and the second firmware can communicate through the PCIe physical link design of the shared memory space. This efficient communication mechanism solves various problems existing in I / O communication based on KCS or BT interface, and better meets the requirements of low-latency business scenarios. During the communication process, the present application supports both asynchronous communication mode and synchronous communication mode to meet different business needs. This embodiment proposes that when the first firmware sends request data, the status value of the response flag bit is configured in the request data to indicate whether the request data is waiting for the second firmware to return, thereby reliably avoiding the request data that needs to wait for the second firmware to return from not being processed in time by the second firmware, resulting in too long processing time for the request data, such as exceeding the pre-configured timeout period, and triggering error processing of the request data, affecting data interaction efficiency.

[0168] In the actual application of the present application, since the capacity of the shared memory space configured by the management processor is limited, the amount of data that can be stored in the first interaction area and the second interaction area divided therefrom is limited, which can be determined according to their respective memory lengths / sizes, such as storing a maximum of 1024 request data, etc. The amount of data that can be stored in different interaction areas can be the same or different, and the present application does not impose any restrictions on this.

[0169] Based on this, before the first firmware sends each request data to the first interactive area, it can first determine whether the number of request data in the current first interactive area is less than the first number threshold (such as 1024, etc., the present application does not limit the first number threshold, and it can be determined based on its memory length). If it is greater than or equal to the first number threshold, it means that the storage space of the first interactive area is full, and the request data can be stopped from being sent, or the request data can be continued to be sent. At this time, a prompt indicating that the request data failed to be sent will be returned, and it will be resent after waiting for a preset time. If it is less than the first number threshold, it means that the storage space of the first interactive area is not full, and the request data that needs to be sent is sent to the first interactive area for storage, such as executing the step of sending the first request data or the second request data to the first interactive area, and according to the number of request data sent this time, the number of request data in the first interactive area is increased, such as adding 1 to the count mark of the number of request data in the first interactive area, so that the number of request data after the increase is consistent with the number of request data actually stored in the first interactive area.

[0170] Similarly, if the first firmware successfully obtains any response data from the second interaction area, it can delete the response data in the second interaction area and reduce the number of response data in the second interaction area, such as reducing the number of response data by 1; if multiple response data are obtained in batches from the second interaction area, the multiple response data in the second interaction area are deleted, and the number of response data in the second interaction area is reduced according to the number of the multiple response data obtained, so that the reduced number of response data is consistent with the number of response data actually stored in the second interaction area.

[0171] In the above implementation process, the first firmware can also delete the request data matching the response data in the first interaction area after successfully obtaining the response data, and then reduce the number of request data in the first interaction area, thereby avoiding the problem that when the second firmware directly reads the request data in the first interaction area or thereafter deletes the corresponding request data in the first interaction area, an error occurs during the processing of the request data by the second firmware, and the request data can no longer be re-read from the first interaction area, and it is necessary to notify the first firmware to resend the request data, thereby affecting the efficiency of data interaction.

[0172] Of course, in some embodiments, after confirming that any request data has been successfully obtained from the first interaction area, the second firmware may also directly delete the request data in the first interaction area, reduce the amount of request data in the first interaction area, and thereby promptly release the storage resources of the first interaction area, providing sufficient storage space for the first firmware to subsequently send other request data, thereby avoiding the failure to successfully store the subsequently sent request data due to insufficient storage space in the first interaction area, resulting in the loss of request data or the need for the first firmware to wait.

[0173] According to the above analysis, the second firmware can confirm whether the number of response data in the second interactive area is less than the second number threshold (such as 1024, etc., this application does not limit the second number threshold, and it can be determined based on its memory length) before sending each response data or multiple response data to the second interactive area according to the method described above. If it is, it means that the storage space of the second interactive area is not full, and then the obtained response data is sent to the second interactive area, and the number of response data in the second interactive area is increased according to the number of response data sent this time. On the contrary, it means that the storage space of the second interactive area is full, and the response data can be temporarily stopped from being sent, or the response data is still sent, and after receiving feedback that the storage of the response data fails, it is sent again after waiting for a preset time.

[0174] It should be noted that the method for detecting the remaining storage space of the first interaction area and the second interaction area includes but is not limited to the method described above of determining whether the number of request / response data reaches the corresponding number threshold. It is also possible to determine whether the request / response data can continue to be sent by counting whether the amount of data of the request / response data to be sent reaches the available storage capacity of the corresponding interaction area. The implementation process is similar and will not be described in detail in this application.

[0175] Reference Fig. 9 , is a signaling flow diagram of the data interaction method proposed in Example 4 of the present application. Combined with the above analysis, the design of realizing data interaction between the first firmware and the second firmware based on the shared memory space proposed in the present application can support synchronous communication mode and asynchronous communication mode, and the corresponding communication process can refer to but is not limited to the above description. In the communication process, especially in a multi-tasking or concurrent environment, in order to ensure the security of access to the shared memory space and prevent multiple threads or tasks from operating on the same interaction area of ​​the shared memory space at the same time, causing data competition and state inconsistency problems, the embodiment of the present application proposes to realize the above communication process based on a mutex lock mechanism. Based on this, Fig. 9 As shown, the data interaction method proposed in this embodiment may include:

[0176] Step S910, the first firmware confirms that the first operation mode of the first interactive area is the first mode value, and prohibits performing operations on the first interactive area;

[0177] Step S920, the first firmware confirms that the first operation mode of the first interaction area is the second mode value, updates the first operation mode to the first mode value, sends the first request data to the first interaction area, and restores the first operation mode to the second mode value;

[0178] In an embodiment of the present application, in order to achieve mutually exclusive access by the first firmware and the second firmware to the first interactive area and the second interactive area of ​​the shared memory space, the present application can be implemented using a mutex lock, that is, before sending an IPMI command, the firmware first attempts to acquire the mutex lock. If the mutex lock is occupied, wait for the mutex lock to be released before sending the IPMI command, so that multiple threads / tasks corresponding to multiple firmwares access an interactive area at the same time, causing a conflict, thereby protecting the access to the corresponding data queues in the interactive area.

[0179] Based on this, the present application can configure different mode values ​​of the operating mode (which can be expressed as OperatingMode) for each interactive area to indicate whether the current firmware can access the interactive area. The interactive area can only be accessed when the operating mode is in the second mode value (such as 0 or a predefined specified symbol / value, etc.), and interference can be avoided during the access. After obtaining access to the interactive area, the operating mode is promptly switched to the first mode value (such as 1 or another predefined specified symbol / value, etc.) to deny other firmware from accessing the interactive area where the operating mode is in the first mode value.

[0180] Therefore, before the first firmware sends each request data to the first interaction area, it can first detect the first operation mode of the first interaction area. If it is the first mode value at this time, it means that the second firmware is accessing the first interaction area at this time. If the second firmware reads the request data in the first interaction area, the first firmware will be prohibited from sending the request data to the first interaction area, and wait for the first operation mode of the first interaction area to be the second mode value. The first firmware obtains the access right to the first interaction area and promptly updates the first operation mode to the first mode value, indicating that the current first interaction area is being accessed and other firmwares are prohibited from accessing it. At this time, the second firmware cannot perform the request data reading operation on the first interaction area.

[0181] According to the method described above, after the first firmware successfully sends the first request data (i.e., one or more request data currently required to be sent) to the first interaction area, the first operation mode can be restored to the second mode value in a timely manner, releasing the first firmware's access rights to the first interaction area, so that the second firmware can normally access the first interaction area and read the request data to be processed, so as to avoid the first firmware occupying the access rights to the first interaction area for a long time and reducing the data interaction efficiency.

[0182] Step S930, the first firmware controls the interaction flag to be in a first state value;

[0183] Step S940: The second firmware detects that the interaction flag is in the first state value, confirms that the first operation mode of the first interaction area is the second mode value, updates the first operation mode to the first mode value, and obtains the first request data in the first interaction area;

[0184] Step S950, the second firmware obtains first response data matching the first request data based on the first request data;

[0185] Following the above description of different mode values ​​of the first operation mode, before the second firmware accesses the first interaction area and reads the request data to be processed therefrom, it can first determine whether the current first interaction area is being accessed and occupied by the first firmware. This can be achieved by confirming whether the first operation mode of the first interaction area is the first mode value. If it is the first mode value, the second firmware will be prohibited from accessing the first interaction area, waiting for the other party's operation to complete and release the occupation of the first interaction area; if it is the second mode value, it means that the first interaction area shared by the first firmware and the second firmware is not occupied, and the first interaction area can be accessed. In order to avoid interference during the second firmware's access to the first interaction area, the second firmware can update the first operation mode to the first mode value, prohibit other firmware from accessing the first interaction area, and then read the first request data of the first interaction area to obtain matching first response data.

[0186] Step S960, the second firmware restores the interaction flag to the second state value, confirms that the second operation mode of the second interaction area is the second mode value, updates the second operation mode to the first mode value, sends the first response data to the second interaction area, and restores the second operation mode to the second mode value;

[0187] Step S970: the first firmware confirms that the second operation mode is the second mode value, updates the second operation mode to the first mode value, obtains first response data matching the first request data in the second interaction area, and restores the second operation mode to the second mode value.

[0188] Regarding the mutually exclusive access implementation process of the first firmware and the second firmware to the shared second interactive area, similar to the mutually exclusive access implementation process to the first interactive area, the present application pre-configures the second interactive area with a second operating mode. When the second operating mode is the first mode value, it indicates that the second interactive area is currently occupied and new firmware (referring to other firmware other than the firmware currently accessing the second interactive area) is not allowed to access; when the second operating mode is the second mode value, it indicates that the second interactive area is not occupied and access to the second interactive area is allowed. It should be noted that the first operating mode of the first interactive area and the second operating mode of the second interactive area are independent of each other and do not affect each other's operations. The two communicate through an independent PCIe physical link to ensure the accuracy and security of the read data.

[0189] Based on this, when the second firmware confirms that the second operation mode is the second mode value, it is allowed to access the second interaction area. At this time, the second operation mode can be updated to the first mode value in time to avoid interference in the process of the second firmware sending response data to the second interaction area. After all the response data obtained are written into the second interaction area, the occupation of the second interaction area is released in time, and the second operation mode is restored to the second mode value, so that the first firmware can access the second interaction area normally, and read the various response data stored in the second interaction area in time and reliably, thereby improving data interaction efficiency. Among them, after the first firmware completes the reading of the response data of the second interaction area, it will also release the occupation of the second interaction area in time and restore the second operation mode to the second mode value. The implementation process is not limited in this application.

[0190] It can be seen that the present application implements secure access to each interactive area in the shared memory space that the communication between the first firmware and the second firmware depends on by using a mutual exclusion lock mechanism, thereby ensuring the reliability and stability of the communication between the first firmware and the second firmware, effectively avoiding data competition and state inconsistency problems, and improving the efficiency and reliability of data interaction.

[0191] In the data interaction methods described in the above embodiments, each interactive area of ​​the shared memory space can be composed of a corresponding area header (expressed as Header) and an IPMI command of the area (such as request data Request or response data Response). In a possible implementation, the area header can be defined as the following structure:

[0192] typedef struct{

[0193] UINT32 Signature; / / The first interactive area of ​​the request data Request / the second interactive area of ​​the response data Response are marked as IPMR / IPMA respectively;

[0194] UINT32 RegionSize; / / The size of the valid data (including SM_IPMI_HEADER) of the entire first interaction region / second interaction region, that is, the total amount of request data / response data to be read;

[0195] UINT32 SectionCount; / / Number of unprocessed IPMI commands (number of request data stored in the first interaction area / number of response data stored in the second interaction area), the maximum supported is 1024, which is the first number threshold and the second data threshold mentioned above, but is not limited to this;

[0196] UINT16 InitState; / / Region initialization status, used to mark whether the first interactive area / second interactive area has been initialized: 0 can indicate that the corresponding interactive area is not initialized; 1 can indicate that the corresponding interactive area has been initialized; 2 can indicate that POST is completed (BIOS can perform the next initialization after a normal restart);

[0197] UINT16 OperatingMode; / / The first operation mode of the first interactive area / the second operation mode of the second interactive area, set to 1 when accessing the corresponding interactive area, and BIOS / BMC implements mutually exclusive access;

[0198] }SM_IPMI_HEADER;

[0199] Based on this, the storage format of each request data in the first interactive area can be as follows: Fig.10 The IPMI format shown is as follows Fig.10 As shown, each request data can be composed of a fixed 8-byte header and a variable-length payload, where the variables are defined in sequence as follows:

[0200] typedef struct{

[0201] UINT32 Signature; / / First firmware UEFI, marking the start of IPMI command (request data);

[0202] UINT16 Index; / / Mark the index number of the IPMI request data (such as Fig.10 The Idx[1] and Idx[0] shown in the figure have a unique characteristic, so that the first firmware can read the response data Response matching it from the second interactive area according to it, and its index number range can be consistent with the number threshold of the interactive area, such as 1024;

[0203] UINT8 CheckSum; / / Payload part checksum (such as Fig.10 cksum shown), that is, verifying the integrity and correctness of the data to effectively detect whether the request data is modified or damaged during transmission, and ensure the reliability of IPMI communication. This application does not limit the verification method;

[0204] UINT8 NfLun; / / Standard IPMI commands NetFun and Lun: (NetFun << 2) | (Lun & 0x3);

[0205] UINT8 Command; / / Standard IPMI command (such as Fig.10 cmd), which can indicate the specific execution process, for example, 0x0 indicates chassis control commands, 0x02 indicates power control commands, etc.

[0206] UINT8 ResponseRequired; / / Response flag (such as Fig.10 res), indicating whether it is necessary to wait for the second firmware BMC to return / / {0 means no need to wait (NoNeed), corresponding to the above second state value; 1 means need to wait (Pending), corresponding to the above first state value; 2 means response data has been returned (Responsed)};

[0207] UINT8 Size; / / Payload size, i.e. the length of the request content contained in this request data;

[0208] }SM_IPMI_REQUEST;

[0209] It can be seen that each request data, i.e., request IPMI command, can adopt the IPMI command body with the structure defined above, and can be adaptively adjusted according to the requirements of the IPMI protocol, which will not be described in detail in this application.

[0210] Similarly, each response data in the second interaction area, i.e., the response IPMI command, can be stored as follows: Fig.11 The IPMI format shown in the figure is different from the IPMI command format for request data in that: ResponseRequired in the response data is always set to 0 (i.e. Fig.11 The byte content of res shown is 0) and marked as "BMC_" in ASCII code. The definition variable content of other bytes is the same as the request data, and this application does not explain them one by one. It should be noted that the index numbers of the matching request data and response data are the same, so that the first firmware can correctly read the required response data from the second interaction area accordingly.

[0211] Among them, during the request / response IPMI command transmission process, it can be implemented based on the PCIe communication link. Each IPMI command can be defined in the IPMI command format described above, and after obtaining the corresponding data packet, it is sent to the corresponding interaction area to improve data transmission efficiency. The implementation process is not described in detail in this application.

[0212] In combination with the data interaction method described in the above embodiment, the operations for storing data in the first interaction area and the second interaction area are mainly insertion (i.e., writing) and deletion. The interaction areas where the request data and the response data are located will respond to these two operations. The process of obtaining the response data of the second interaction area in the first firmware is not necessarily a necessary operation, that is, GetResponse is not a necessary operation for the BIOS. For IPMI commands that do not need to wait for the BMC to return response data, such as the SEL LOG command sent, the BIOS only needs SendRequest. The BMC records the log data based on the SEL LOG command, and the log data does not need to be fed back to the BIOS.

[0213] For the request data Request stored in the first interactive area, refer to Fig.12 As shown in the data interaction diagram, BMC can read Request to obtain matching response data Response. Take Request1 sent by BIOS as an example. Fig.12 As shown, combined with the data structure of the interactive area described above, when BIOS writes Request1 into the request data queue of the first interactive area, SectionCount of the request data can be increased by 1, that is, the number of request data in the first interactive area is increased by 1. If the SectionCount reaches 1024 (that is, the first number threshold), BIOS will be blocked from sending Request and cannot continue to send it, and directly return failure.

[0214] When the BMC responds to a request data, such as interrupting the current processing task, it reads Request1, subtracts 1 from the SectionCount of the request data, writes the obtained matching Response1 into the second interactive area, and adds 1 to the SectionCount of the response data, that is, the number of response data in the second interactive area is increased by 1. If the SectionCount reaches 1024 (that is, the second number threshold), the BMC will be blocked from sending Response and cannot continue to send, and directly returns failure. The BIOS reads the Response1 in the second interactive area and subtracts 1 from the SectionCount of the response data. Optional, such as Fig.12 As shown, the SectionCount of the requested data may also be reduced by 1 at this time to improve the reliability of data interaction.

[0215] In the communication process between the above-mentioned BIOS and BMC, mutually exclusive access of BIOS and BMC to the same interaction area can be achieved based on the OperatingMode of each interaction area. The implementation process can refer to the description of the corresponding part of the above embodiment, and this embodiment will not be repeated. Among them, when the server is powered on and initialized, the BIOS can initialize the first interaction area and the second interaction area to the default value, and set InitState to 1. When the system POST ends, the BIOS sets InitState to 2. From the perspective of the BMC, when InitState is a non-zero value, this area is in the Ready state, and the corresponding interaction area can be accessed according to the data interaction method described in this application to promote data interaction efficiency.

[0216] Based on the data interaction method applied to the first firmware provided by the embodiment of the present application introduced above, a device for executing the data interaction method on the first firmware side will be introduced below.

[0217] Reference Fig.13 , is a schematic diagram of the structure of the data interaction device proposed in the first embodiment of the present application, and the device can be applied to the first firmware, such as Fig.13 As shown, the data interaction device may include:

[0218] The first request data sending module 131 is used to send the first request data to the first interaction area, and control the interaction flag to be in a first state value; the interaction flag being in the first state value indicates that the first interaction area stores request data to be processed;

[0219] A first response data acquisition module 132, configured to acquire first response data matching the first request data in the second interaction area;

[0220] Among them, the first firmware runs on the main processor of the server and is used to guide the system startup and operation of the server, and the second firmware runs on the management processor of the server; the first interaction area and the second interaction area are shared memory spaces in the management processor that are mapped to the main processor; the request data and the response data both comply with the intelligent platform management interface protocol specifications.

[0221] In some embodiments, the data interaction device may further include:

[0222] A second request data sending module, configured to send at least one second request data to the first interaction area after the control interaction flag is in a first state value;

[0223] A second response data acquisition module is used to acquire second response data matching each of the at least one second request data in the second interaction area when the first response data acquisition module is triggered to acquire first response data matching the first request data in the second interaction area before the life cycle of the first firmware ends.

[0224] In some embodiments, the data interaction device may further include:

[0225] A first operation mode confirmation module, used to confirm a first operation mode of the first interaction area;

[0226] A first prohibition module, configured to prohibit performing operations on the first interaction area if the first operation mode is a first mode value;

[0227] a first restoring module, configured to update the first operating mode to the first mode value if the first operating mode is the second mode value, trigger the first request data sending module to send the first request data to the first interaction area, and restore the first operating mode to the second mode value;

[0228] A second operation mode confirmation module, used to confirm the second operation mode of the second interaction area;

[0229] A second prohibition module, configured to prohibit performing operations on the second interaction area if the second operation mode is the first mode value;

[0230] A second recovery module is configured to update the second operation mode to the first mode value if the second operation mode is the second mode value, trigger the first response data acquisition module to acquire the first response data matching the first request data in the second interaction area, and then restore the second operation mode to the second mode value.

[0231] In some embodiments, the data interaction device may further include at least one of the following modules:

[0232] A first sending module, configured to send next request data to the first interaction area after acquiring response data matching the request data in the second interaction area if the response flag bit configured in any request data sent by the first firmware is a first state value;

[0233] a second sending module, configured to stop executing the step of acquiring response data matching the request data in the second interaction area if the response flag bit of any request data sent by the first firmware is a second state value, and send next request data to the first interaction area;

[0234] a request data quantity increasing module, configured to execute a step of sending the first request data or the second request data to the first interaction area to increase the request data quantity of the first interaction area if the request data quantity in the first interaction area is less than a first quantity threshold;

[0235] The request data quantity reduction module is used to delete the request data matching the response data in the first interaction area and the response data in the second interaction area if any response data is successfully obtained, thereby reducing the quantity of request data in the first interaction area and the quantity of response data in the second interaction area.

[0236] Based on the data interaction method applied to the second firmware provided by the embodiment of the present application introduced above, a device for executing the data interaction method on the second firmware side will be introduced below.

[0237] Reference Fig.14 , is a schematic diagram of the structure of the data interaction device proposed in the second embodiment of the present application, and the device can be applied to the second firmware, such as Fig.14 As shown, the data interaction device may include:

[0238] A first request data acquisition module 141 is used to detect that the interaction flag is in a first state value, and acquire first request data from the first firmware in the first interaction area;

[0239] A first response data obtaining module 142, configured to obtain first response data matching the first request data based on the first request data;

[0240] A first response data sending module 143, configured to restore the interaction flag to a second state value and send the first response data to a second interaction area;

[0241] Among them, the first firmware is deployed on the main processor of the server to guide the system startup and operation of the server, and the second firmware is deployed on the management processor of the server; the first interaction area and the second interaction area are shared memory spaces in the management processor mapped to the main processor; the request data and the response data both comply with the intelligent platform management interface protocol specifications.

[0242] In some embodiments, the above Fig.14 The data interaction device shown may also include:

[0243] A second request data acquisition module, configured to acquire at least one second request data from the first firmware in the first interaction area when the interaction flag is detected to be in the first state value;

[0244] A second response data obtaining module is used to obtain second response data that matches each of the at least one second request data based on the at least one second request data before restoring the interaction flag bit to the second state value;

[0245] The second response data sending module is used to execute the steps of restoring the interaction flag to the second state value, sending the first response data to the second interaction area, and sending the second response data to the second interaction area if the response data matching all the acquired request data have been obtained.

[0246] In some embodiments, the first request data acquisition module 141 may include any of the following units:

[0247] A first acquisition unit is configured to interrupt the task currently executed by the second firmware and acquire the request data from the first firmware in the first interaction area if it is detected that the interaction flag bit switches from the second state value to the first state value;

[0248] A second acquisition unit is configured to acquire request data from the first firmware in the first interaction area if it is detected that the state value of the interaction flag bit is not switched and is the first state value;

[0249] The request data from the first firmware includes at least one of the first request data and the second request data.

[0250] In some embodiments, the above Fig.14 The data interaction device shown may also include at least one of the following modules:

[0251] A response data sending module, configured to directly send the response data to the second interaction area after obtaining response data matching the request data if it is confirmed that the response flag bit of any request data is in the first state value;

[0252] A response data obtaining module, used for obtaining response data matching the respective request data if it is confirmed that the response flag bits of the respective request data are in the second state value;

[0253] A first operation mode processing module is configured to update the first operation mode to the first mode value if it is confirmed that the first operation mode of the first interaction area is the second mode value, execute the step of acquiring the request data from the first firmware in the first interaction area, and restore the first operation mode to the second mode value;

[0254] A second operation mode processing module is used for, if it is confirmed that the second operation mode of the second interactive area is the second mode value, updating the second operation mode to the first mode value, executing the step of sending the obtained response data to the second interactive area, and restoring the second operation mode to the second mode value;

[0255] a response data quantity increasing module, configured to, if it is confirmed that the response data quantity in the second interaction area is less than a second quantity threshold, execute a step to send the obtained response data to the second interaction area, and increase the response data quantity in the second interaction area;

[0256] The response data quantity reduction module is used to delete the request data in the first interaction area if it is confirmed that any request data is successfully obtained from the first interaction area, so as to reduce the quantity of request data in the first interaction area.

[0257] An embodiment of the present application also provides a computer program product including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements any data interaction method provided in the embodiment of the present application.

[0258] A computer-readable storage medium is also provided in an embodiment of the present application. The storage medium carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any data interaction method provided in the embodiment of the present application.

[0259] It should also be noted that the device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, in the drawings of the device embodiments provided by the present application, the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines.

[0260] Through the description of the above implementation methods, in the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments can be implemented in the form of a computer program product. In addition, each embodiment in this specification is described in a progressive or parallel manner, and each embodiment focuses on the differences from other embodiments, and the same and similar parts between the embodiments can be referred to each other. For the device, server, product and medium disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

Claims

1. A data interaction method, applied to a first firmware, comprising: Sending first request data to the first interaction area, and controlling the interaction flag to be in a first state value; The interaction flag being in the first state value indicates that the first interaction area stores request data to be processed; Acquire first response data matching the first request data in the second interaction area; The first firmware runs on the main processor of the server and is used to guide the system startup of the server, and the second firmware runs on the management processor of the server; The first interaction area and the second interaction area are shared memory spaces in the management processor that are mapped to the main processor; The request data and the response data both comply with the intelligent platform management interface protocol specification.

2. The method according to claim 1, further comprising: After the control interaction flag is in a first state value, sending at least one second request data to the first interaction area; Before the life cycle of the first firmware ends, the step of obtaining first response data matching the first request data in the second interaction area is performed, and second response data matching each of the at least one second request data in the second interaction area is obtained.

3. The method according to claim 1 or 2, further comprising: confirming a first operation mode of a first interaction area; If the first operation mode is a first mode value, prohibiting the execution of operations on the first interaction area; If the first operation mode is the second mode value, updating the first operation mode to the first mode value, executing the step of sending the first request data to the first interaction area, and restoring the first operation mode to the second mode value; confirming a second operation mode of the second interaction area; If the second operation mode is the first mode value, prohibiting the execution of operations on the second interactive area; If the second operation mode is the second mode value, the second operation mode is updated to the first mode value, the step of obtaining the first response data matching the first request data in the second interaction area is performed, and the second operation mode is restored to the second mode value.

4. The method according to claim 1 or 2, further comprising at least one of the following: If the response flag bit configured in any request data sent by the first firmware is a first state value, after obtaining response data matching the request data in the second interaction area, the next request data is sent to the first interaction area; If the response flag bit of any request data sent by the first firmware is a second state value, stop executing the step of obtaining response data matching the request data in the second interaction area, and send the next request data to the first interaction area; If the number of request data in the first interaction area is less than the first number threshold, executing the step of sending the first request data or the second request data to the first interaction area to increase the number of request data in the first interaction area; If any response data is successfully obtained, the request data matching the response data in the first interaction area and the response data in the second interaction area are deleted to reduce the number of request data in the first interaction area and the number of response data in the second interaction area.

5. A data interaction method, applied to the second firmware, the method comprising: It is detected that the interaction flag is in a first state value, and first request data from the first firmware in the first interaction area is obtained; Based on the first request data, obtaining first response data matching the first request data; Restoring the interaction flag to a second state value, and sending the first response data to a second interaction area; The first firmware is deployed on the main processor of the server to guide the system of the server to start and run, and the second firmware is deployed on the management processor of the server; The first interaction area and the second interaction area are shared memory spaces in the management processor that are mapped to the main processor; The request data and the response data both comply with the intelligent platform management interface protocol specification.

6. The method according to claim 5, further comprising: In the case where it is detected that the interaction flag is in the first state value, obtaining at least one second request data from the first firmware in the first interaction area; Before restoring the interaction flag to the second state value, obtaining second response data that matches each of the at least one second request data based on the at least one second request data; If response data matching all acquired request data are obtained, the step of restoring the interaction flag to the second state value, sending the first response data to the second interaction area, and sending the second response data to the second interaction area is performed.

7. The method according to claim 5 or 6, wherein when it is detected that the interaction flag is in the first state value, obtaining the request data from the first firmware in the first interaction area comprises any one of the following: If it is detected that the interaction flag is switched from the second state value to the first state value, interrupting the task currently executed by the second firmware and obtaining the request data from the first firmware in the first interaction area; If it is detected that the state value of the interaction flag bit has not been switched and is the first state value, obtaining the request data from the first firmware in the first interaction area; in, The request data from the first firmware includes at least one of the first request data and the second request data.

8. The method according to claim 5 or 6, further comprising at least one of the following: If it is confirmed that the response flag bit of any request data is in the first state value, after obtaining the response data matching the request data, directly sending the response data to the second interaction area; If it is confirmed that the response flag bits of each request data are in the second state value, to obtain the response data matching the each request data; If it is confirmed that the first operation mode of the first interactive area is the second mode value, the first operation mode is updated to the first mode value, the step of obtaining the request data from the first firmware in the first interactive area is performed, and the first operation mode is restored to the second mode value; If it is confirmed that the second operation mode of the second interaction area is the second mode value, the second operation mode is updated to the first mode value, and the step of sending the obtained response data to the second interaction area is performed to restore the second operation mode to the second mode value; If it is confirmed that the amount of response data in the second interaction area is less than a second amount threshold, executing a step of sending the obtained response data to the second interaction area to increase the amount of response data in the second interaction area; If it is confirmed that any request data is successfully obtained from the first interaction area, the request data in the first interaction area is deleted to reduce the amount of request data in the first interaction area.

9. A server, comprising: A main processor, a management processor, a first firmware, and a second firmware, wherein: The management processor is configured with a shared memory space mapped to the main processor, the shared memory space comprising a first interaction area and a second interaction area; The first firmware runs on the main processor, and is used to send first request data to the first interaction area, control the interaction flag to be in a first state value, and obtain first response data matching the first request data in the second interaction area; The second firmware runs on the management processor, and is used for detecting that the interaction flag is in a first state value, obtaining the first request data in the first interaction area, obtaining first response data matching the first request data based on the first request data, restoring the interaction flag to a second state value, and sending the first response data to the second interaction area; Wherein, the request data and the response data both comply with the intelligent platform management interface protocol specification; The interaction flag being in the first state value indicates that the first interaction area stores request data to be processed.

10. The server according to claim 9, wherein the shared memory space is part of the video memory space of the second firmware; Each request data in the first interaction area and each response data in the second interaction area are stored in a queue storage structure; The first firmware and the second firmware communicate with each other via a computer peripheral device interconnection bus; The interaction flag bit is configured in a flag register.

Images