Intel Corporation

Other

Sk Hynix Nand Product Solutions Corp.

Mohan J Kumar

Murugasamy K Nachimuthu

Sarathy Jayakumar

Theodros Yigzaw

Ashok Raj

Debendra Das Sharma

James B Crossland

Shivnandan D Kaushik

Raj K Ramanujan

Mahesh S Natu

Sergiu D Ghetie

Mrittika Ganguli

Narayan Ranganathan

Vincent J Zimmer

Linda J Rankin

Shay Gueron

Sujoy Sen

Robert Charles Swanson

Ron Gabor

Kai Cheng

Francesc Guim Bernat

Glenn J Hinton

Karthik Kumar

Rajat Agarwal

George Vergis

Ernie F Brickell

Michael Mishaeli

David Zimmerman

Ganapati Srinivasa

Michael A Rothman

Zeev Sperber

Robert G Blankenship

Mark A Schmisseur

Suraj Prabhakaran

Victor B Lortz

Russell Jerome Fenger

Shlomo Raikin

Ehud Cohen

Yadong Li

Gilbert A Neiger

Rajesh Poornachandran

Rajesh M Sankaran

Rahul Khanna

Yen-Cheng Liu

Koichi Yamada

James A Sutton, Ii

Ioannis T Schoinas

Susanne M Balle

Tessil Thomas

Michael Orr

Jiewen Yao

Kenneth C Creta

Andrew J Fish

Brian S Morris

Ramamurthy Krithivas

David M Durham

Kshitij Arun Doshi

Ravi L Sahita

Efraim Rotem

Eliezer Weissmann

Gyan Prakash

Krishnakanth Venkata Sistla

Paul S Diefenbaugh

Baiju V Patel

Richard A Uhlig

Thomas Willhalm

Hong C Li

Ravishankar Iyer

Michael Lemay

Andrew J Herdrich

Alon Naveh

Arvind A Kumar

Sara S Baghsorkhi

Prashant Sethi

Xiao Liang Hu

Michael T Crocker

Jr-Shian Tsai

Sanjay Kumar

Stephen S Pawlowski

Jeremy J Shrall

Guy M Therien

Joseph Nuzman

Robert E Gough

Vadim Sukhomlinov

Gary A Solomon

Dean A Mulla

Alexander Bachmutsky

Lihu Rappoport

Andrew W Martwick

Mingqiu Sun

Sridhar Muthrasanallur

Aaron Gorius

Shahrokh Shahidzadeh

Robert S Chappell

Vasudevan Srinivasan

Mark Doran

Ashish Gupta

Lily Pao Looi

Ian M Steiner

Sailesh Kottapalli

A first die has a port to couple the first die to a second die over a die-to-die interconnect. The port includes circuitry to implement a physical layer of the die-to-die interconnect, send first protocol identification data over the physical layer to identify a first protocol in a plurality of protocols, send first data over the interconnect to the second die, wherein the first data comprise data of the first protocol, send second protocol identification data over the physical layer to identify a different second protocol in the plurality of protocols, and send second data over the interconnect to the second die, wherein the second data comprise flits of the second protocol.

Sharing memory and I/O services between nodes

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

An apparatus and method are described for detecting and correcting data fetch errors within a processor core. For example, one embodiment of an instruction processing apparatus for detecting and recovering from data fetch errors comprises: at least one processor core having a plurality of instruction processing stages including a data fetch stage and a retirement stage; and error processing logic in communication with the processing stages to perform the operations of: detecting an error associated with data in response to a data fetch operation performed by the data fetch stage; and responsively performing one or more operations to ensure that the error does not corrupt an architectural state of the processor core within the retirement stage.

Apparatus and method for detecting and recovering from data fetch errors

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

Embodiments are generally directed apparatuses, methods, techniques and so forth determine an access level of operation based on an indication received via one or more network links from a pod management controller, and enable or disable a firmware update capability for a firmware device based on the access level of operation, the firmware update capability to change firmware for the firmware device. Embodiments may also include determining one or more configuration settings of a plurality of configuration settings to enable for configuration based on the access level of operation, and enable configuration of the one or more configuration settings.

Techniques to control system updates and configuration changes via the cloud

Technologies for providing latency-aware consensus management in a disaggregated system include a compute device. The compute device includes circuitry to determine latencies associated with subsystems of the disaggregated system. Additionally, the circuitry is to determine, as a function of the determined latencies, a time period in which a configuration change to the disaggregated system is to reach a consistent state in the subsystems.

Technologies for providing latency-aware consensus management in a disaggregated architecture

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

Technologies for composing a managed node with multiple processors on multiple compute sleds to cooperatively execute a workload include a memory, one or more processors connected to the memory, and an accelerator. The accelerator further includes a coherence logic unit that is configured to receive a node configuration request to execute a workload. The node configuration request identifies the compute sled and a second compute sled to be included in a managed node. The coherence logic unit is further configured to modify a portion of local working data associated with the workload on the compute sled in the memory with the one or more processors of the compute sled, determine coherence data indicative of the modification made by the one or more processors of the compute sled to the local working data in the memory, and send the coherence data to the second compute sled of the managed node.

Cloud-based scale-up system composition

Examples include updating firmware for a persistent memory module in a computing system during runtime. Examples include copying a new version of persistent memory module firmware into an available area of random-access memory (RAM) in the persistent memory module, and transferring processing of a current version of persistent memory module firmware to the new version of persistent memory module firmware during runtime of the computing system, without a reset of the computing system and without quiesce of access to persistent memory media in the persistent memory module, while continuing to perform critical event handling by the current version of persistent memory module firmware. Examples further include initializing the new version of persistent memory module firmware; and transferring processing of critical event handling from the current version of persistent memory module firmware to the new version of persistent memory module firmware when initializing the new version of persistent memory module firmware is completed.

Memory device firmware update and activation without memory access quiescence

Technologies for fast boot-up of a compute device with error-correcting code (ECC) memory are disclosed. A basic input/output system (BIOS) of a compute device may assign memory addresses of the ECC memory to different processors on the compute device. The processors may then initialize the ECC memory in parallel by writing to the ECC memory. The processors may write to the ECC memory with direct-store operations that are immediately written to the ECC memory instead of being cached. The BIOS may continue to operation on one processor while the rest of the processors initialize the ECC memory.

Technologies for fast booting with error-correcting code memory

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

Embodiments of systems, apparatuses and methods provide enhanced function as a service (FaaS) to users, e.g., computer developers and cloud service providers (CSPs). A computing system configured to provide such enhanced FaaS service include one or more controls architectural subsystems, software and orchestration subsystems, network and storage subsystems, and security subsystems. The computing system executes functions in response to events triggered by the users in an execution environment provided by the architectural subsystems, which represent an abstraction of execution management and shield the users from the burden of managing the execution. The software and orchestration subsystems allocate computing resources for the function execution by intelligently spinning up and down containers for function code with decreased instantiation latency and increased execution scalability while maintaining secured execution. Furthermore, the computing system enables customers to pay only when their code gets executed with a granular billing down to millisecond increments.

Function as a service (FaaS) system enhancements

Systems, apparatuses and methods may provide for technology that exchanges activation information between system firmware and an operating system (OS), wherein the activation information includes one or more of status information, activation state information, capability information, activation time information or quiesce time information. The technology also conducts a runtime upgrade of the device firmware based on the activation information, wherein the runtime upgrade bypasses a reboot of the computing system.

Interface and warm reset path for memory device firmware upgrades

Embodiments are generally directed apparatuses, methods, techniques and so forth to receive a sled manifest comprising identifiers for physical resources of a sled, receive results of an authentication and validation operations performed to authenticate and validate the physical resources of the sled, determine whether the results of the authentication and validation operations indicate the physical resources are authenticate or not authenticate. Further and in response to the determination that the results indicate the physical resources are authenticated, permit the physical resources to process a workload, and in response to the determination that the results indicate the physical resources are not authenticated, prevent the physical resources from processing the workload.

Techniques to verify and authenticate resources in a data center computer environment

Mechanisms for out-of-band (OOB) management of Field Programmable Gate Array (FPGA) bitstreams and associated methods, apparatus, systems and firmware. Under a first OOB mechanism, a management component, such as a baseband management controller (BMC) is coupled to a processor including an agent in a compute node that includes an FGPA. An FPGA bitstream file is provided to the BMC, and the agent reads the file from the BMC and streams the FPGA bitstream contents in the file to the FPGA to program it. Under second and third OOB mechanisms, a pointer to an FPGA bitstream file that identifies the location of the file that is accessible via a network or fabric is provided to the BMC or other management entity. The BMC/management entity forwards the pointer to BIOS running on the compute node or an agent on the processor. The BIOS or agent then uses the pointer to retrieve the FPGA bitstream file via the network or fabric, as applicable, and streams the FPGA bitstream to the FPGA to program it.

Out-of-band management of FPGA bitstreams

Growing community of inventors

Aloha, OR, United States of America

Mohan J Kumar