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
Document File: 2 page(s) / 11K

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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

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

     The PMI is a highest priority interrupt in IPF architecture, just like SMI in the x86 architecture. The PMI is disabled upon entry to the PMI handler by the processor to prevent nesting, just like any other regular interrupts. Since, PMI handler has the highest priority, it doesn't need to re-enable the PMI, as soon as possible, after saving interruption resources. So, the nested PMIs are blocked, while the PMI handler is running. All the nested PMIs are seen as a single pending PMI upon reenabling the PMI, to ensure that the subsequent PMI events are not lost. However, in order to safely execute the PMI handler, it is also necessary to ensure that the system is quiesced, so that there is no conflict in accessing the system resources, between the processor running the PMI handler & all other processors in the system. So, a rendezvous & wakeup mechanism is needed for the PMI handler, to ensure that all other processors in the system are in the PMI rendezvous spin loop, while any one of the processors in the system handles the PMI event.

     Following is the pseudo code for the PMI handler for all processors in the system, which highlights the rendezvous & wakeup mechanism for the PMI handler, described in the summary above:
1. The processor enters PMI handler due to some event.
2. Wait until PMI Lock is acquired by the processor, to support simultaneous PMIs in multiple processors.
3. Check if PMI in Progress is set for the processor? If yes,

          Check if PMI was caused by Rendezvous Vector (rv = 1, 2 or 3) or Rendezvous Requested is set for the processor If yes,

spin=true retry=false


spin=false
retry=false Also, set PMI in Progress for all processors in the system.


4. Release the PMI Lock, to allow other processors in the PMI handler to also enter the spin loop below.
5. If spin or retry, Set Rendezvous in Progress for the processor. Wait until PMI in Progress for the pr...