Microsoft Technology Licensing, LLC

Intel Corporation

Tom Long Nguyen

Mallik Bulusu

Ravi Mysore Shantamurthy

Bryan David Kelly

Muhammad Ashfaq Ahmed

Neeraj Ladkani

Madhav Himanshubhai Pandya

Daini Xie

Steven R Carbonari

Karunakara Kotary

Ling Yee Sy

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

A method for targeted repair of a hardware component in a computing device that is part of a cloud computing system includes monitoring a plurality of hardware components in the computing device. At some point, a defective sub-component within the hardware component of the computing device is identified. In addition to the defective sub-component, the hardware component also includes at least one sub-component that is functioning properly and a spare component that can be used in place of the defective sub-component. The method also includes initiating a targeted repair action while the computing device is connected to the cloud computing system. The targeted repair action prevents the defective sub-component from being used by the computing device without preventing sub-components that are functioning properly from being used by the computing device. The targeted repair action causes the spare component to be used in place of the defective sub-component.

Targeted repair of hardware components in a computing device

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

Technologies are described which permit kernel updates or firmware fixes, and include re-initialization of kernel data structures, without losing user context information that has been created by services, virtual machines, or user applications. Tailored code in a server or other computing system sets a kernel soft reset (KSR) indicator and saves the user context to non-volatile storage. When a KSR is underway, boot code skips the power on self-test and similar initializations (thereby reducing downtime), loads a kernel image, initializes kernel data structures, restores the user context, and passes control to the initialized kernel to continue computing system operation with the same user context. Device drivers may also be re-initialized. The loaded kernel may use newly fixed firmware, or may have a security patch installed, for instance. The non-volatile storage may operate at RAM speed, e.g., it may include NVDIMM memory. The kernel may be validated before receiving control.

Kernel soft reset using non-volatile RAM

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

Embodiments of ensuring data integrity in computing devices and associated methods of operations are disclosed therein. In one embodiment, a method includes receiving, at a memory controller, a data request from the persistent storage to copy data from the memory. In response to the received data request, the requested data is retrieved from the memory. The retrieved data contains data bits and corresponding error correcting bits. The method can also include determining, at the memory controller, whether the retrieved data bits contain one or more data integrity errors based on the error correcting bits associated with the data bits. In response to determining that the retrieved data bits contain one or more data integrity errors, the memory controller can write data representing existence of the one or more data integrity errors into a memory location accessible by the processor for ensuring data integrity.

Data error detection in computing systems

In some examples, error recovery in volatile memory regions may include determining, during a save operation that includes saving of data to a primary location, that an error occurred with respect to the save operation. Based on a determination that the error occurred with respect to the save operation, an error location may be determined, and a determination may be made as to whether the error location maps to a volatile memory region. Based on a determination that the error location maps to the volatile memory region, a reserved location may be identified for saving the data. The data may be saved from the primary location to the reserved location. Further, metadata may be updated to indicate usage of the reserved location as the primary location for the saved data.

Error recovery in volatile memory regions

In some examples, error recovery in non-volatile storage partitions may include determining, upon completion of a save operation that includes saving of data to a primary location, that an error occurred with respect to the save operation. Based on a determination that the error occurred with respect to the save operation, a reserved location for saving the data may be identified. The data may be saved to the reserved location. Metadata to indicate usage of the reserved location as the primary location for the saved data may be updated.

Error recovery in non-volatile storage partitions

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

Auburn, WA, United States of America

Tom Long Nguyen