Intel Corporation

Microsoft Technology Licensing, LLC

Mallik Bulusu

Vincent J Zimmer

Robert Charles Swanson

Michael A Rothman

Tom Long Nguyen

Palsamy Sakthikumar

Robert Bruce Bahnsen

Muhammad Ashfaq Ahmed

Ravi Mysore Shantamurthy

Bryan David Kelly

Neeraj Ladkani

Robert W Cone

Robert S Gittins

Piotr Michael Kwidzinski

Daini Xie

Rahul Khanna

Madhusudhan Rangarajan

Babak B Nikjou

Ramakoti R Bhimanadhuni

John R Lindsley

Daniel Nemiroff

Malay Trivedi

Janusz Jurski

Mariusz Oriol

Eshwari Prasad Komarla

Pawel Szymanski

Madhav Himanshubhai Pandya

Mariusz Stepka

Piotr Sawicki

Pingfan Song

William J O'Sullivan

Sandip M Hiray

Karunakara Kotary

Sagar Dharia

Mahesh S Natu

Stephen S Pawlowski

David Kimbal Dorwin

Andrew J Fish

Kirk D Brannock

Mark Doran

Narayan Ranganathan

Ramamurthy Krithivas

Dimitrios Ziakas

Badriddine Khessib

James Steven Burns

Michael Kinney

David N Lombard

Eric R Wehage

Krishna Kumar Ganesan

Gundrala D Goud

Russell J Wunderlich

C Brendan Traw

Kanivenahalli Govindaraju

Thirupathaiah Annapureddy

Greg P McGrath

Miles F Schwartz

Fernando A Lopez

Brijesh Ramachandran

Ali Hassan Larijani

Devendu Sharma

Subhankar Panda

Michael Alan Kubacki

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

The described technology provides a method including reserving a portion of a volatile memory on a system on chip (SOC) including one or more processors, decompressing at least a portion of the firmware code from a non-volatile memory; programming one or more volatile memory access control registers to remove write access to the reserved portion of the volatile memory, programming a memory activation table (MAT), wherein the MAT includes a set of memory access controller register addresses and values of the memory access controller register addresses, and communicating an address of the reserved portion of the volatile memory and the MAT to a trusted execution engine (TEE) on the SOC.

Processor restart using firmware boot from volatile memory

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

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

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

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

Growing community of inventors

Olympia, WA, United States of America

Mallik Bulusu