Intel Corporation

Sarathy Jayakumar

Mohan J Kumar

Ashok Raj

Murugasamy K Nachimuthu

Theodros Yigzaw

Jose Andy Vargas

Vincent J Zimmer

Sergiu D Ghetie

Gilbert A Neiger

Rajesh Poornachandran

Jason W Brandt

Robert Charles Swanson

Mahesh S Natu

Narayan Ranganathan

Beeman C Strong

Rupin H Vakharwala

Ido Ouziel

Larisa Novakovsky

Andreas Kleen

Neelam Chandwani

John G Holm

Neeraj S Upasani

Jeff Huxel

Ronald N Story

Ruixia Li

Michael A Rothman

Rahul Khanna

George Vergis

Ron Gabor

Jiewen Yao

Hisham Shafi

Anil S Keshavamurthy

Chuan Song

Siyuan Fu

Efraim Rotem

Eliezer Weissmann

Wei P Chen

Krishnakanth Venkata Sistla

Paul S Diefenbaugh

Jeremy J Shrall

Eugene Gorbatov

Guy M Therien

Robert E Gough

Mingqiu Sun

John S Howard

Mark Doran

Anil Aggarwal

Ying Liu

Andrew D Henroid

Sham M Datta

Palsamy Sakthikumar

Gopinatth Selvaraje

Michael Kinney

Eswaramoorthi Nallusamy

Subhankar Panda

Sreenivas Mandava

Di Zhang

Brett P Wang

Gaurav Porwal

Gopal R Mundada

Salessawi Ferede Yitbarek

Chong Han

Anil Agrawal

Zhi Yong Chen

Zhuangzhi Li

Yi Zeng

Zhi Jin

Thomas Toll

Wenjuan Mao

Bo He

Eswar Konduru

Lin Chen

Adam J Brooks

Jiaxin Wu

Lui He

Guomin Jiang

Xiaojin Yuan

Ron Story

Haiyue Wang

Hemalatha Gurumoorthy

Ruiyu Ni

Yao Jiewen

Jay Lawlor

Charles Holthaus

Michael D Kinney

Techniques and mechanisms for supporting machine check functionality with a handler which is implemented in firmware. In an embodiment, a processor executes first firmware code to implement a machine check event (MCE) detector. The MCE detector detects a hardware error of a platform which includes the processor, and generates a call to invoke an MCE handler which the processor implements by executing second firmware code. The MCE handler is called, outside of a software context, to attempt a recovery from the hardware error. The call is performed independent of any system management interrupt being based on the detected hardware error. In another embodiment, another MCE handler of an operating system is conditionally invoked where it is determined that the attempted recovery by the first MCE handler was unsuccessful.

Firmware first handling of a machine check event

An electronic device is disclosed, including a first set of processor cores including at least one processor core and a second set of processor cores including at least one processor core. The electronic device is configured such that during initialization of the electronic device: the first set of processor cores executes first initialization instructions in a first execution environment, the second set of processor cores executes second initialization instructions in a second execution environment, and the first set and the second set at least one of read or write to a shared register.

Decoupling silicon initialization and bootloader by providing silicon initialization service

Methods, apparatus, systems, and articles of manufacture to perform a pseudo-S3 protocol to update firmware and/or activate new firmware with a warm reset are disclosed. An example apparatus includes an advanced configuration and power interface (ACPI) to: initiate a pseudo-sleep event in response to identifying a firmware update; and assert a power button event, the power button event to cause an operating system (OS) to prepare to enter into a sleep state; a basic input/output system (BIOS) to: initiate a warm reset in response to the OS preparing to enter the sleep state, the warm reset to update firmware according to the firmware update; and transmit a wake vector to the OS to continue operation.

Methods and apparatus to perform a pseudo-S3 protocol to update firmware and/or activate new firmware with a warm reset

A modular microcode (uCode) patch method to support runtime persistent update and associated apparatus. The method enables BIOS uCode patches to be received during platform runtime operations and written to first and second uCode extension regions as uCode images for a firmware device layout that further includes a uCode base region in which a current uCode image is stored. Following a platform reset, the first and second uCode extension regions are inspected to determine if one or more valid and newer uCode images (than the current uCode image) are present. If so, the newest uCode image is booted rather than the current uCode image. Following a successful boot, the newest uCode image is copied to the uCode base region to sync-up the current uCode image to the newest version. In one aspect, received uCode images are written to the first and second uCode extension regions in an alternating manner to support roll-back.

Modular microcode (uCode) patch method to support runtime persistent update

Methods and apparatus for seamless SMM (System Management Mode) global driver update base on SMM Root-of-Trust. Mechanisms are provided to load and replace SMM drivers at runtime in a secure manner, without requiring an SMM firmware update and platform reset. SMM code is executed by BIOS during boot in a hidden area of memory called SMRAM space. Seamless update using an SMM Global Driver Update provides a method to load and replace all SMM drivers (including SMM infrastructure) on an already shipped platform production for purposes such as bug fixes. The principles and teachings may also be applied to update other types of secure execution mode code in addition to SMM code.

Seamless SMM global driver update base on SMM root of trust

Examples described herein provide a central processing unit (CPU) to reserve a region of memory for use to store both a boot firmware code and a second boot firmware code and to perform the second boot firmware code without reboot. The reserved region of memory can be a region that is not configured for access by an operating system (OS). The reserved region of memory comprises System Management Random Access Memory (SMRAM). If a first interrupt handler is not overwritten after a second boot firmware code is stored, the CPU can roll back to use of the first interrupt handler.

Update of boot code handlers

A microcode (uCode) hot-upgrade method for bare metal cloud deployment and associated apparatus. The uCode hot-upgrade method applies a uCode patch to a firmware storage device (e.g., BIOS SPI flash) through an out-of-band controller (e.g., baseboard management controller (BMC)). In conjunction with receiving a uCode patch, a uCode upgrade interrupt service is triggered to upgrade uCode for one or more CPUs in a bare-metal cloud platform during runtime of a tenant host operating system (OS) using an out-of-bound process. This innovation enables cloud service providers to deploy uCode hot-patches to bare metal servers for persistent storage and live-patch without touching the tenant operating system environment.

Microcode(uCode) hot-upgrade method for bare metal cloud deployment

An apparatus and method for processing non-maskable interrupt source information. For example, one embodiment of a processor comprises: a plurality of cores comprising execution circuitry to execute instructions and process data; local interrupt circuitry comprising a plurality of registers to store interrupt-related data including non-maskable interrupt (NMI) data related to a first NMI; and non-maskable interrupt (NMI) processing mode selection circuitry, responsive to a request, to select between at least two NMI processing modes to process the first NMI including: a first NMI processing mode in which the plurality of registers are to store first data related to a first NMI, wherein no NMI source information related to a source of the NMI is included in the first data, and a second NMI processing mode in which the plurality of registers are to store both the first data related to the first NMI and second data comprising NMI source information indicating the NMI source.

Apparatus and method to identify the source of an interrupt

Systems, apparatuses and methods may provide for technology that stores first hardware related data to a basic input output system (BIOS) memory area and generates a mailbox data structure, wherein the mailbox data structure includes a first identifier-pointer pair associated with the first hardware related data. Additionally, the technology may generate an operating system (OS) interface table, wherein the OS interface table includes a pointer to the mailbox data structure. In one example, the technology also stores second hardware related data to the BIOS memory area at runtime and adds a second identifier-pointer pair to the mailbox data structure at runtime, wherein the second identifier-pointer pair is associated with the second hardware related data.

Deployment of BIOS to operating system data exchange

There is disclosed in one example a multi-core computing system configured to provide a hot-swappable CPU0, including: a first CPU in a first CPU socket and a second CPU in a second CPU socket; a switch including a first media interface to the first CPU socket and a second media interface to the second CPU socket; and one or more mediums including non-transitory instructions to detect a hot swap event of the first CPU, designate the second CPU as CPU0, determine that a new CPU has replaced the first CPU, operate the switch to communicatively couple the new CPU to a backup initialization code store via the first media interface, initialize the new CPU, and designate the new CPU as CPUN, wherein N&#x2260;0.

CPU hot-swapping

In an embodiment, a processor for reverse translation includes a plurality of processing engines (PEs) to execute threads and a reverse translation circuit. The reverse translation circuit is to: determine a target module address of a corrupt portion of a memory module; determine a plurality of system physical address (SPA) addresses associated with the memory module; and for each SPA address in the plurality of SPA addresses, translate the SPA address into a translated module address, and in response to a determination that the translated module address matches the target module address, log the SPA address as a result of a reverse translation of the target module address. Other embodiments are described and claimed.

Hardware unit for reverse translation in a processor

Technologies for secure native code invocation include a computing device having an operating system and a firmware environment. The operating system executes a firmware method in an operating system context using a virtual machine. In response to invoking the firmware method, the operating system invokes a callback to a bridge driver in the operating system context. In response to the callback, the bridge driver invokes a firmware runtime service in the operating system context. The firmware environment executes a native code handler in the operating system context in response to invoking the firmware runtime service. The native code handler may be executed in a de-privileged container. The firmware method may process results data stored in a firmware mailbox by the native code handler, which may include accessing a hardware resource using a firmware operation region.

Technologies for secure and efficient native code invocation for firmware services

There is disclosed in one example a processor, including: a protected runtime mode (PRM) module to receive a PRM interrupt and to: suspend operation of a software task executing on the processor; save processor state information; place the microprocessor into PRM; access a PRM handler in a designated PRM memory region, wherein the PRM handler comprises a platform specific task; restore the processor state; and resume operation of the software task.

Protected runtime mode

A processor includes cores to execute instructions, and circuitry to detect a system management interrupt (SMI) event on the processor, direct an indication of the SMI event to an arbiter on a controller hub, and receive an interrupt signal from the arbiter. The processor also includes an SMI handler to take action in response to the interrupt, and circuitry to communicate the interrupt signal to the cores. The cores include circuitry to pause while the SMI handler responds to the interrupt. The interrupt handler includes circuitry to determine that a second SMI event detected on the processor or controller hub is pending, and to take action in response. The interrupt handler includes circuitry to set an end-of-SMI bit to indicate that the interrupt handler has completed its actions. The controller includes circuitry to prevent the arbiter from issuing another interrupt to the processor while this bit is false.

Arbiter based serialization of processor system management interrupt events

Growing community of inventors

Portland, OR, United States of America

Sarathy Jayakumar