Providing system inventory data from a firmware to a baseboard management controller using an identifier

This application is a continuation of U.S. patent application Ser. No. 18/171,150, filed Feb. 17, 2023, the content of which application is hereby expressly incorporated herein by reference in its entirety.

Managed computing systems commonly include a baseboard management controller (“BMC”) in order to enable platform management. In addition to other types of management functionality, BMCs commonly provide functionality for exposing data describing the inventory of a managed computing system to a management client over an out-of-band (“OOB”) network connection.

In order to provide the functionality described above, a firmware executing on the managed computing system typically performs an inventory of the managed computing system and generates data describing the inventory. The firmware then provides the inventory data to the BMC which, in turn, exposes the inventory data to a management client over an OOB network connection. A system administrator using the management client may view and utilize the inventory data in various ways.

Previous mechanisms for providing inventory data from a firmware to a BMC send separate inventory data for each resource in the managed computing system to the BMC. Because the inventory data for each resource is sent separately using such a mechanism, this process can be very slow. Consequently, this can increase boot time significantly, particularly when a managed computing system has many resources. This also increases the utilization of computing resources by a managed computing system during boot.

It is with respect to these and other considerations that the disclosure made herein is presented.

Technologies are described herein for providing system inventory data from a firmware to a BMC using an identifier. Through implementations of the disclosed technologies, inventory data describing the components of a managed computing system can be provided from a firmware to a BMC in a manner that does not require sending inventory data for each resource in the managed computing system separately. This can speed up the boot process and reduce the utilization of computing resources at boot time by a managed computing system implementing the disclosed technologies. Technical benefits other than those specifically mentioned herein can also be realized through an implementation of the disclosed technologies.

In order to provide the functionality described herein, a firmware driver is executed by a firmware of a managed computing system in one embodiment. During boot time of the managed computing system, the firmware driver generates a request to a BMC for combined inventory data for the managed computing system. For example, the firmware driver may generate a REST Hypertext Transfer Protocol (“HTTP”) request (e.g., a call to the HTTP GET method) to an identifier for the combined inventory data to an interface exposed by a management server in the BMC. The firmware driver receives the combined inventory data for the managed computing system from the BMC in response to the request to the identifier exposed by the BMC.

As discussed briefly above, a BMC is a specialized service processor that monitors the physical state of a computer, network server, or other managed hardware device using sensors, and exposes information to a remote management client through an OOB network connection. BMCs can also provide functionality for exposing data describing the inventory of a managed computing system to a management client via an OOB connection using the technologies disclosed herein.

In an embodiment, the REST HTTP request for the combined inventory data is made to an identifier that is compatible with the REDFISH management standard. REDFISH is a successor to previous manageability interfaces created by the Distributed Management Task Force (“DMTF”). REDFISH is an open industry standard specification and schema for simple, modern, and secure management of scalable platform hardware, such as server computers located in data centers.

The REDFISH specification and schema specifies a REST interface, and utilizes JAVASCRIPT object notation (“JSON”) and the Open Data Protocol (“OData”) to integrate management solutions within existing toolchains. Although the embodiments disclosed herein are described primarily as utilizing an identifier that is compatible with the REDFISH management standard, the REST HTTP requests disclosed herein can be made to identifiers that are defined according to other specifications in other embodiments.

The combined inventory data requested by the firmware driver from the BMC includes data describing the installed components of the managed computing system. For example, the combined inventory data may identify the installed components of the managed computing system including, but not limited to, a memory of the managed computing system, memory domains of the managed computing system, processors of the managed computing system, storage resources of the managed computing system, network adapters of the managed computing system, input/output (“I/O”) controllers of the managed computing system, graphics controllers of the managed computing system, bus slots of the managed computing system, devices present in bus slots of the managed computing system, and media controllers of the managed computing system.

In an embodiment, the firmware driver also performs an inventory of the managed computing system to obtain updated inventory data for the managed computing system. Once the firmware driver has performed the inventory of the managed computing system, the firmware driver determines if the updated inventory data and the combined inventory data are identical. In this manner, the firmware driver can determine if any modifications to the inventory of the managed computing system were made since the last time the firmware driver retrieved the combined inventory data from the BMC.

In an embodiment, the combined inventory data and the updated inventory data are organized into groups. In this embodiment, the firmware driver can determine if the updated inventory data and the combined inventory data are identical by determining if each group of the combined inventory data is identical to a corresponding group in the updated inventory data. Each group of the combined inventory data that is not identical to a corresponding group in the updated inventory data indicates that one or more modifications were made to installed components of the managed computing system.

If the firmware driver determines that the updated inventory data and the combined inventory data are identical, the firmware driver causes control to be passed from the firmware to an operating system executing on the managed computing system. However, if the firmware driver determines that the updated inventory data and the combined inventory data are not identical, the firmware driver generates new combined inventory data for the managed computing system. The new combined inventory data includes new or changed inventory data for groups of the combined inventory data that are not identical to corresponding groups of the updated inventory data.

Once the firmware driver has generated the new inventory data, the firmware driver can post (e.g., by way of a call to an HTTP POST method) the new combined inventory data for the managed computing system to the identifier exposed by the BMC. Following posting of the new combined inventory data for the managed computing system to the identifier exposed by the BMC, the firmware driver can instruct the BMC to begin processing of the new combined inventory data. Thereafter, the firmware driver can cause control to be passed from the firmware to an operating system executing on the managed computing system.

It should be appreciated that the above-described subject matter can also be implemented as a computer-controlled apparatus, a computer process, a computing system, or as an article of manufacture such as a computer-readable medium. These and various other features will be apparent from a reading of the following Detailed Description and a review of the associated drawings.

This Summary is provided to introduce a selection of the technologies disclosed herein in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended that this Summary be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.

The following detailed description is directed to technologies for providing system inventory data from a firmware to a BMC using an original equipment manufacturer (“OEM”)-defined uniform resource identifier (“URI”). As discussed briefly above, implementations of the disclosed technologies enable inventory data for a managed computing system to be provided from a firmware to a BMC in a manner that does not require sending inventory data describing each resource in the managed computing system separately. This can speed up the boot process and reduce the utilization of computing resources by a managed computing system implementing the disclosed technologies. Technical benefits other than those specifically mentioned herein can also be realized through an implementation of the disclosed technologies. Additional details regarding these aspects will be provided below with regard to.

It is to be appreciated that the subject matter presented herein can be implemented as a computer process, a computer-controlled apparatus, a computing system, or an article of manufacture, such as a computer-readable storage medium. While the subject matter described herein is presented in the general context of program modules that execute on one or more computing devices, those skilled in the art will recognize that other implementations can be performed in combination with other types of program modules. Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types.

Those skilled in the art will also appreciate that aspects of the subject matter described herein can be practiced on or in conjunction with other computer system configurations beyond those described herein, including multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, handheld computers, personal digital assistants, e-readers, mobile telephone devices, tablet computing devices, special-purposed hardware devices, network appliances, and the like. The configurations described herein can be practiced in distributed computing environments, where tasks can be performed by remote computing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

In the following detailed description, references are made to the accompanying drawings that form a part hereof, and that show, by way of illustration, specific configurations or examples. The drawings herein are not drawn to scale. Like numerals represent like elements throughout the several figures (which might be referred to herein as a “FIG.” or “FIGS.”).

are software architecture diagrams illustrating aspects of a mechanism disclosed herein for providing system inventory data from a firmware to a BMC using an OEM-defined URI, according to an embodiment. The embodiments disclosed herein are presented in the context of a managed computing systemthat is equipped with a BMC. As discussed briefly above, a BMCis a specialized service processor that monitors the physical state of a computer, such as the managed computing system, using sensors and communicates with a system administrator through an OOB network (not shown in the FIGS.) connected to a management client. BMCs can also provide functionality for exposing data describing the inventory of a managed computing systemto a management clientvia an OOB connection using the technologies disclosed herein.

In order to provide various aspects of its functionality, some of which are described herein, the BMCalso communicates with a firmwareof the managed computing system. The firmwarecan be implemented to be compliant with the Unified Extensible Firm Interface (“UEFI”) Specification. Other types of firmware can be utilized in other embodiments. Additional details regarding the configuration and operation of the firmwarein one embodiment are provided below with regard to.

In order to provide the functionality disclosed herein, the firmwareexecutes a firmware driver, in one embodiment. The firmware driveris a software component that generates a request to the BMCfor combined inventory datafor the managed computing system. As will be described in greater detail below, the combined inventory datais generated by the firmware driverand stored at the BMC. Additionally, and as will also be described in greater detail below, the firmware driveralso generates checksums for the combined inventory data, which are also stored at the BMC.

The combined inventory dataincludes data describing the installed components of the managed computing system. For example, the combined inventory datamay identify the installed components of the managed computing systemincluding, but not limited to, a memory of the managed computing system, memory domains of the managed computing system, processors of the managed computing system, storage resources of the managed computing system, network adapters of the managed computing system, I/O controllers of the managed computing system, graphics controllers of the managed computing system, bus slots of the managed computing system, devices present in bus slots of the managed computing system, and media controllers of the managed computing system. The combined inventory dataidentifies other installed components of the managed computing systemin other embodiments.

As shown in, a management agentexecuting in the BMCstores system inventory datain an appropriate data store. When a request for combined inventory datais received, such as that described above, the management agentmay retrieve the combined inventory datafrom the data store. The management server, in turn, can provide the combined inventory datain response to the request received from the firmware driver. For instance, the management serverprovides a REST HTTP response to the firmware driverthat includes the combined inventory data, in an embodiment. The management servercan also receive and respond to requests for the system inventory datafrom the management clientin a similar fashion. The firmware drivercan also obtain checksums for the combined inventory datafrom the BMCin a similar fashion.

In an embodiment, the firmware drivergenerates a REST HTTP request (e.g., a callto the HTTP GET method) for the combined inventory datato an OEM-defined URIexposed by a management serverin the BMC. The firmware driveralso obtains checksumsfor the combined inventory datafrom the OEM-defined URIexposed by the management serverin the BMC, in an embodiment. The checksumsare included in the combined inventory data, in an embodiment.

The OEM-defined URIis a URI that has been defined by the OEM of the managed computing system. The OEM-defined URIis compatible with the REDFISH management standard, in an embodiment. As discussed briefly above, REDFISH is a successor to previous manageability interfaces created by the DMTF. REDFISH is an open industry standard specification and schema for simple, modern, and secure management of scalable platform hardware, such as server computers located in data centers.

The REDFISH specification and schema specifies a REST interface, and utilizes JSON and OData to integrate management solutions within existing toolchains. Although the embodiments disclosed herein are described primarily as utilizing an OEM-defined URIthat is compatible with the REDFISH management standard, the requests described herein can be made to OEM-defined URIs that are defined according to other specifications in other embodiments.

In an embodiment, the BMCdetermines whether changes were made to the system inventory dataprior to the current reboot, such as by a user of the management client. If no changes to the system inventory datawere made, the BMCdoes not transmit the combined inventory datato the firmware driver. Rather, the BMCtransmits the checksumsfor the previously stored combined inventory datain response to the call to the HTTP GET method received from the firmware driver.

As shown in, the firmware driver, or another component of the firmware, also performs an inventory of the managed computing systemto obtain updated inventory datafor the managed computing system. The firmware driver, or another component of the firmware, also generates checksumsfor the updated inventory data, in an embodiment.

Once the firmware driverhas performed the inventory of the managed computing system, the firmware driverdetermines if the updated inventory dataand the combined inventory dataare identical. In this manner, the firmware drivercan determine if any modifications to the inventory of the managed computing systemwere made since the last time the combined inventory datawas retrieved from the BMC.

In an embodiment, the combined inventory dataand the updated inventory dataare organized into groups. In this embodiment, the firmware drivercan determine if the updated inventory dataand the combined inventory dataare identical by determining if each group of the combined inventory datais identical to a corresponding group in the updated inventory data.

For instance, and as discussed briefly above, in an embodiment, the firmware drivergenerates checksums(e.g., CRC32 checksums) for groups in the updated inventory data. In this embodiment, the firmware driverobtains checksumsfor the combined inventory datafrom the BMCin the manner described above with respect to. The firmware driverthen compares the checksumsthat it calculated to the checksumsreceived from the BMCto identify those groups in the updated inventory datathat are different than the corresponding groups in the combined inventory data.

Table 1, set forth below, shows the structure of the combined inventory datain an embodiment. In this example, the combined inventory datahas been organized into various groups, including groups corresponding to memory, memory domains, processors, storage, etc. In this embodiment, checksumsmight be generated for some or all of these groups and compared to checksumsfor corresponding groups in the updated inventory datato identify those groups in the updated inventory datathat are different than the corresponding groups in the combined inventory data.

If the firmware driver determines that the updated inventory dataand the combined inventory dataare identical, the firmware drivercauses control to be passed from the firmwareto an operating system executing on the managed computing system. However, if the firmware driverdetermines that the updated inventory dataand the combined inventory dataare not identical, the firmware drivergenerates new combined inventory datafor the managed computing system. The new combined inventory dataincludes new or changed inventory data for groups of the combined inventory datathat are not identical to corresponding groups of the updated inventory data. In an embodiment, the firmware driveralso generates checksums for the new combined inventory data.

As shown in, once the firmware driverhas generated the new inventory data, the firmware drivercan post (e.g., by way of a callto an HTTP POST method) the new combined inventory datafor the managed computing systemto the OEM-defined URIexposed by the BMC. In response thereto, the management servergenerates a REST HTTP responseto the callsuch as, for example, a responseincluding data indicating that processing of the REST HTTP POST request was successful. The responseis compatible with the REDFISH management standard in embodiments disclosed herein. In an embodiment, the firmware driveralso posts the checksums for the new combined inventory datato the to the OEM-defined URIexposed by the BMCin a similar fashion. As discussed above, the firmware driverretrieves the checksums when it retrieves the corresponding combined inventory data, in an embodiment.

Following posting of the new combined inventory datafor the managed computing systemto the OEM-defined URIexposed by the BMC, the firmware drivercan instruct the BMCto begin processing of the new combined inventory data. For instance, in the embodiment shown in, the firmware driverhas made an HTTP PATCH callto the OEM-defined URIto instruct the BMCto begin processing of the new combined inventory data. In response thereto, the management agentcan store the new combined inventory dataand any associated checksums in the data store. Additionally, the management servergenerates a REST HTTP responseto the callsuch as, for example, a responseincluding data indicating that the callwas received successfully. The responseis compatible with the REDFISH management standard in embodiments disclosed herein. Thereafter, the firmware drivercan cause control to be passed from the firmwareto an operating system executing on the managed computing system.

In an embodiment, the firmwarealso provides functionality for generating updated checksums for system inventory datastored in the data storethat is changed. For instance, a user of the management clientmight make changes to security certificates or other types of system inventory datafor the managed computing system. In this scenario, the management servercan notify the firmware driverof the change. In response thereto, the firmware drivercan generate new checksums and provide the new checksums to the BMCfor storage and utilization in the manner described above. In an embodiment, the firmware driversets the value of the new checksumsto zero. In this embodiment, the firmware drivercomputes new checksumsfor the combined inventory datawhen it receives checksums from the BMChaving a value of zero. The firmware drivercomputes new checksumsfor the combined inventory dataprior to performing the comparison between the checksumsand.

It is to be appreciated thatand the other FIGS. have been simplified for discussion purposes, and that many other software and hardware components can be utilized to implement the functionality disclosed herein. For example, and without limitation, various networks and networking components can be utilized to connect the management clientto the BMC. In this regard, it is also to be appreciated that while only a single managed computing systemand a single management clienthave been illustrated in, many such computing systems can be utilized in various configurations.

are flow diagrams showing a routine that illustrates additional aspects of mechanism shown in-ID for providing combined inventory datafrom a firmwareto a BMCusing an OEM-defined URI, according to an embodiment disclosed herein. It is to be appreciated that the logical operations described herein with respect to, and the other FIGS., can be implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system.

The implementation of the various components described herein is a matter of choice dependent on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to variously as operations, structural devices, acts, or modules. These operations, structural devices, acts, and modules can be implemented in software, in firmware, in special purpose digital logic, and any combination thereof. It should also be appreciated that more or fewer operations might be performed than shown in the FIGS. and described herein. These operations can also be performed in parallel, or in a different order than those described herein. These operations can also be performed by components other than those specifically identified.

The routinebegins at operation, where the firmwarebegins execution. The routinethen proceeds to operation, where the firmware drivergenerates a REST HTTP request (e.g., a callto the HTTP GET method) to the OEM-defined URIexposed by the management serverin the BMCto obtain the combined inventory data. This process is illustrated inand described above. The firmware drivercan obtain the combined inventory dataat a boot time of the computing system. As used herein, the term “boot time” refers to the time period after the firmwarebegins executing and before the operating system of the managed computing systemstarts to load.

From operation, the routineproceeds to operation, where the firmware driver, or another component of the firmware, performs an inventory of the managed computing systemto obtain updated inventory datafor the managed computing system. Once the inventory of the managed computing systemhas been taken, the routineproceeds to operation, where the firmware drivercomputes checksums(e.g., CRC32 checksums) for groups in the updated inventory data, in an embodiment. At operation, the firmware driverretrieves the previously-stored checksumsfor the combined inventory dataprovided by the BMCusing the OEM-defined URI, in an embodiment.

From operation, the routineproceeds to operation, where the firmware drivercompares the checksumsandto determine if the updated inventory dataand the combined inventory dataare identical. If the checksumsandare identical, the routineproceeds from operationto operation, where the firmwarepasses control of the managed computing systemto an operating system. The routinethen proceeds from operationto operation, where it ends.

If, at operation, the firmware driverdetermines that the checksumsandare not identical, the routineproceeds from operationto operation. At operation, the firmware drivergenerates new combined inventory datafor groups having non-matching checksums. In this way, new combined inventory datais generated only for items of inventory in the managed computing systemthat have changed. The firmware driveralso generates checksums for the new combined inventory datain the manner described above. The routinethen proceeds from operationto operation.

At operation, the firmware driverposts (e.g., by way of a callto an HTTP POST method) the new combined inventory datafor the managed computing systemgenerated at operationto the OEM-defined URIexposed by the BMC. The firmware driveralso posts the checksums for the new combined inventory datato the OEM-defined URIexposed by the BMC, in an embodiment. In response thereto, the management servergenerates a REST HTTP responseto the callsuch as, for example, a responseincluding data indicating that processing of the REST HTTP POST request was successful.

From operation, the routineproceeds to operation, where the firmware driverinstructs the BMCto begin processing of the new combined inventory data. For instance, in the embodiment shown in, the firmware driverhas made an HTTP PATCH callto the OEM-defined URIto instruct the BMCto begin processing of the new combined inventory data. In response thereto, the management agentstores the new combined inventory datain the data storeat operation. The management agentcan also store the checksums for the new combined inventory datain the data storein a similar fashion. Additionally, the management servergenerates a REST HTTP responseto the callsuch as, for example, a responseincluding data indicating that the callwas received successfully.

From operation, the routineproceeds to operation, where the firmwarecompletes its boot processing and passes control to an operating system executing on the managed computing system. The routinethen proceeds from operationto operation, where it ends.