Dismiss
The InnovationQ application will be updated on Sunday, May 31st from 10am-noon ET. You may experience brief service interruptions during that time.
Browse Prior Art Database

Rendezvous & Wakeup Mechanisms for Platform Management Interrupt (PMI) Handler

IP.com Disclosure Number: IPCOM000028737D
Original Publication Date: 2004-May-28
Included in the Prior Art Database: 2004-May-28

Publishing Venue

IBM

Abstract

Intel's Itanium Product Family (IPF) processor architecture uses Platform Management Interrupt (PMI) to handle system management events independent of the Operating System (OS). It is also similar to the System Management Interrupt (SMI) in x86 processor architecture. Intel's System Abstraction Layer (SAL) defines a rendezvous & wakeup mechanisms for Machine Check Exception (MCE) handler. However, Intel doesn't define a rendezvous & wakeup mechanisms for the PMI handler. The rendezvous mechanism is needed to quiesce the system before handling the event, while the wakeup mechanism is needed to resume after handling the event. The rendezvous mechanism that Intel's SAL defines for the MCE handler uses a rendezvous interrupt. However, the OS must register a high priority interrupt as the rendezvous interrupt with the SAL & provide a rendezvous interrupt handler, because it owns all external interrupts. The wakeup mechanism for the MCE handler uses either a wakeup interrupt or a wakeup semaphore. Again, the OS must register with the SAL, either another higher priority interrupt as the wakeup interrupt & provide a wakeup interrupt handler, or the wakeup semaphore location. The SAL provides a SAL_PROC to spin on either the wakeup interrupt or the wakeup semaphore, so that the MCE handler is notified of the success of the rendezvous. However, the OS is responsible calling it from it's rendezvous interrupt handler. The rendezvous spin loop is also often required to ensure that there is no memory, i/o or scalability accesses. So, the use of wakeup interrupt is preferred over the use of wakeup semaphore, because the external interrupts can be polled by reading processors Interrupt Request Registers (IRRs). More details about the same can be found in Itanium Processor Family System Abstraction Layer Specification & Itanium Processor Family Error Handling Guide. Since, the rendezvous & wakeup mechanisms used for the MCE handling are dependent on the OS interfaces define by the SAL, the same mechanisms can not be extended for use by the PMI handler, without defining the additional OS interfaces in the SAL. In addition to the SAL specification changes, it also needs additional rendezvous & wakeup interrupt/semaphore for the PMI handler. Instead, a solution that is independent of the OS is needed for the PMI handler, so that the platform management events can be handled safely, without any dependency on the OS. The idea is to define a rendezvous & wakeup mechanism for the PMI handler, that doesn't use any external interrupts, as well as, is independent of the OS. The PMI handler sends the PMI with rendezvous vector (1, 2 or 3) to all other processors in the system, in order to rendezvous them. However, there is no way to poll for the PMI in the processors, such as the one for the external interrupts. So, the processor that enters the PMI handler as a result of the rendezvous event, spins on a wakeup semaphore. The memory, i/o or scalability accesses are avoided, while in the PMI rendezvous spin loop, by using a local scratch register in each node as the wakeup semaphores, instead of a memory location. Since, the PMI handler is owned by the firmware, no changes are required in the OS. It also doesn't need any additional external interrupts for the rendezvous or wakeup from the OS. The mechanism can also be easily applied to the SMI handler in x86 systems by using the SMI with rendezvous semaphore instead of rendezvous vector, as there is no vector associated with the SMI.