Microsoft Technology Licensing, LLC

Muhammad Ashfaq Ahmed

Mallik Bulusu

Neeraj Ladkani

Ravi Mysore Shantamurthy

Tom Long Nguyen

Daini Xie

Mohammad Shabbir Alam

Madhav Himanshubhai Pandya

Pingfan Song

Karunakara Kotary

Sagar Dharia

Bryan David Kelly

Ramakoti R Bhimanadhuni

Thirupathaiah Annapureddy

Subhankar Panda

Akram Hamdy

A platform-independent method of securely resetting a processing device includes detecting a predefined trigger event by a baseboard management controller (BMC) that executes system firmware on behalf of a managed host. In response to the predefined trigger event, the system is booted into a safe mode. While in the safe mode, a central processing system of the managed host is maintained in an off state, and a self-heal agent detects architectural characteristics of the managed host, establishes a connection to a cloud-based firmware catalog service, transmits the architectural characteristics of the managed host to the cloud-based firmware catalog service, and downloads a new version of system firmware from the cloud-based firmware catalog service that is compatible with the architectural characteristics of the managed host. The new version of the system firmware is automatically installed without powering on the central processing system of the managed host.

Platform-independent architecture for secure system reset

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 host computing device includes a host processor, host memory in electronic communication with the host processor, and an auxiliary service controller. The host computing device also includes a communication interface and a messaging interface between the host processor and the auxiliary service controller. A message handler is stored in the host memory. The message handler is executable by the host processor in response to detecting a messaging interface signal on the messaging interface. Execution of the message handler by the host processor causes a firmware update patch to be read from a shared memory region in the auxiliary service controller via the communication interface.

Pushing a firmware update patch to a computing device via an out-of-band path

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

A computing device is provided, including memory storing an instruction storage location. The computing device may further include a processor system including a plurality of processor threads. The processor system may suspend execution of one or more respective processor threads of the plurality of processor threads. The processor system may store one or more respective processor thread contexts of the one or more processor threads in the memory. The processor system may enter a system management mode (SMM). The processor system may determine that the instruction storage location includes a code update instruction. The processor system may perform a code update based on the code update instruction. The processor system may exit the SMM. The processor system may retrieve the one or more processor thread contexts from the memory and resume execution of the one or more processor threads without rebooting the computing device.

Code update in system management mode

A computing system is provided, including a processor and memory storing instructions that, when executed, cause the processor to store a firmware update patch in a runtime buffer included in the memory. The runtime buffer may be accessible by firmware and an operating system of the computing system. The processor may perform a first verification check on the firmware update patch. When the firmware update patch passes the first verification check, the processor may copy the firmware update patch to a system management random access memory (SMRAM) buffer included in the memory. The SMRAM buffer may be accessible by the firmware and inaccessible by the operating system. The processor may perform a second verification check on the copy of the firmware update patch. When the copy of the firmware update patch passes the second verification check, the processor may execute the copy of the firmware update patch.

Firmware update patch

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

A computer system includes a host processor including a hardware interrupt pin. The computer system also includes host firmware including an interrupt handler. The interrupt handler includes a plurality of sets of instructions that are executable by the host processor. The computer system also includes a baseboard management controller (BMC) that is connected to the hardware interrupt pin. The BMC is configured to generate an interrupt signal on the hardware interrupt pin in response to occurrence of a triggering event. The BMC is also configured to provide the host processor with context information that identifies a set of instructions in the host firmware that should be executed in response to the interrupt signal.

Method to overload hardware pin for improved system management

Systems and methods for providing electronic messaging services to multiple users by storing a single copy of an electronic message at a central location and notifying recipients of the stored single copy. An electronic message includes a distribution list and a message content. A distribution list identifying multiple recipients causes prior art systems to duplicate the entire message for each recipient, placing potentially large demands on both processing power and storage space. In contrast, the systems and methods disclosed herein store a single copy or a limited number of copies of an electronic message addressed to multiple recipients and provide each recipient with a relatively small notification. In addition to providing information regarding content and origin, the notification also provides access to the stored message. Furthermore, the methods and systems also aid in organizing replies to electronic messages. Replies are associated with an initial message through a message identifier. The association helps to organize electronic messages by subject and provides context without requiring an author to duplicate the content of the initial message with the reply.

Growing community of inventors

Redmond, WA, United States of America

Muhammad Ashfaq Ahmed