Microsoft Technology Licensing, LLC

Ravi Mysore Shantamurthy

Mallik Bulusu

Tom Long Nguyen

Muhammad Ashfaq Ahmed

Neeraj Ladkani

Madhav Himanshubhai Pandya

Bryan David Kelly

Daini Xie

Ramakoti R Bhimanadhuni

Karunakara Kotary

Sagar Dharia

Devendu Sharma

Subhankar Panda

A computing system that enables data stored in a persistent memory region to be preserved when a processor fails can include volatile memory comprising the persistent memory region, non-volatile memory, and a system on a chip (SoC). The SoC can include a main processor that is communicatively coupled to both the volatile memory and the non-volatile memory. The SoC can also include an auxiliary processor that is communicatively coupled to both the volatile memory and the non-volatile memory. The SoC can also include instructions that are executable by the auxiliary processor to cause the data in the persistent memory region of the volatile memory to be transferred to the non-volatile memory in response to a failure of the main processor.

Systems and methods to flush data in persistent memory region to non-volatile memory using auxiliary processor

A computer implemented method includes creating a cache within system management memory to cache data from a firmware flash memory to allow access to the cache by system firmware, providing a baseboard management controller ownership of the firmware flash memory in a server, updating the firmware in the firmware flash memory via the baseboard management controller, relinquishing baseboard management controller ownership of firmware flash memory upon completion of updating the firmware, and flushing the cache back to the firmware flash memory in response to baseboard management controller relinquishing ownership of the firmware flash memory.

Cache to receive firmware generated data during firmware update

To preserve error context during a reboot of a computing device, firmware within the computing device can be configured to implement a method that includes determining where the error context is stored in volatile memory. The method can also include identifying a plurality of recorder regions in non-volatile memory that have been assigned to store the error context. The plurality of recorder regions can be disaggregated across a plurality of distinct non-volatile memory regions. The method can also include flushing the error context from a plurality of different volatile memory locations to the plurality of recorder regions in response to detecting a trigger. The flushing can occur prior to the reboot of the computing device. The method can also include restoring at least some of the error context to the volatile memory after the computing device has been rebooted.

Preserving error context during a reboot of a computing device

While booting a host computing device on a cloud computing system, system firmware (such as Basic Input/Output System (BIOS) or Unified Extensible Firmware Interface (UEFI)) sends a query to a management subsystem (such as a baseboard management controller (BMC)) for updated configuration data used during a boot of the host computing device. The management subsystem sends the updated configuration data to the system firmware, and boot instructions in the system firmware compare the updated configuration data with configuration data stored on the host computing device. If the respective configuration data match, the boot instructions continue with booting the host computing device. If the configuration data do not match, then the boot instructions update the stored configuration data with the updated configuration data and then proceed to boot the host computing device.

Systems and methods for disaggregating system firmware configuration data into a management subsystem for seamless updates

A computing device, such as a server in a cloud computing system, can be configured to enable error mitigation actions to be performed when the computing device experiences a failure. The computing device includes firmware that can be configured to detect an error indication during a boot sequence of the server, determine at least one desired error mitigation action based at least in part on the error indication, and create a boot error record that identifies the at least one desired error mitigation action. The computing device also includes an operating system that can be configured to obtain the boot error record during the boot sequence and cause the at least one desired error mitigation action that is identified in the boot error record to be performed.

Overloading a boot error signaling mechanism to enable error mitigation actions to be performed

Example techniques for updating a firmware, such as BIOS, are disclosed. Upon receiving an update, it is determined whether a secondary non-volatile memory is defined for the firmware. If the secondary non-volatile memory is defined, the update may be written in the secondary non-volatile memory. Further, to apply the update, a warm reboot of the firmware may be performed. The warm reboot causes an OS of the computing system to restart, while preserving data associated with applications running on the computing system.

Firmware update

Combined operational steps and device characteristics help preserve data against integrity threats. Data is divided into critical data and non-critical data, based on criteria such as customer requirements, workload criticality, or virtual machine criticality. Data may be generated in a compute node for storage in a storage node, for example. Critical data is stored in a battery-backed memory aperture at physical addresses where it will be flushed ahead of the non-critical data due to a flush order imposed by or on the battery-backed memory, e.g., a bottom-up NVDIMM flush order. Redundant copies of the data (especially non-critical data) may also be kept in case it does not get flushed in time. Battery-backed memory apertures are sized and located according to their battery's characteristics, and may be relocated or resized as conditions change. Flush defragging is performed to optimize use of the aperture, especially within the portion that holds critical data.

Data preservation using memory aperture flush order

A computing device including a memory module. The computing device may further include a processor configured to, by executing instructions of an operating system, divide a non-volatile region of the memory module into a first non-volatile storage partition allocated to the operating system and a second non-volatile storage partition allocated to system firmware. The processor may write a globally unique identifier (GUID) to the non-volatile region. The GUID may indicate a location of a boundary between the first non-volatile storage partition and the second non-volatile storage partition. The processor may access the first non-volatile storage partition. By executing instructions of the system firmware, the processor may determine the location of the boundary. The processor may access the second non-volatile storage partition. The operating system may be prevented from accessing the second non-volatile storage partition and the system firmware may be prevented from accessing the first non-volatile storage partition.

Non-volatile storage partition identifier

An error-handling system provides detection of an error on an I/O hardware endpoint, triggering of an operating system interrupt in response to detected error, reception of the interrupt at an operating system component, determination, in response to the received interrupt, whether to handle the error using an operating system handler or a firmware error handler associated with the I/O hardware endpoint, and, if it is determined to handle the error using a firmware runtime error handler associated with the I/O hardware endpoint, triggering of a firmware interrupt associated with the firmware runtime error handler.

System for configurable error handling

A computing device may comprise a processor, a volatile memory and a non-volatile storage device. An operating system or firmware of the device may cause one or more pages of the volatile memory to be treated, by applications executing on the computing device, as non-volatile memory pages. A number of pages that may be treated as non-volatile may be determined based on demand for non-volatile storage by at least one application executing on the computing device.

Growing community of inventors

Bothell, WA, United States of America

Ravi Mysore Shantamurthy