DE102010034555A1 - Provide state memory in a system management mode processor - Google Patents

Abstract

In one embodiment, the present invention includes a processor having an on-die memory, such as an on-die memory. A static random access memory to store an architectural state of one or more threads that are swapped out of the architectural state memory upon entering a system management mode (SMM). In this way, communication of this state information to a system management memory can be avoided, thereby reducing latency associated with entry into SMM. Embodiments may also enable the processor to update a state of executing agents that are either in a long instruction flow or in a system management interrupt (SMI) -locked state to display to the agents within the SMM. Further embodiments are described and claimed.

Description

background

Most processors of a computer system support a special operating mode, called system management mode (SMM). SMM provides its own operating environment that is transparent to the operating system (OS) software. This mode is often used by original equipment manufacturers (OEMs) to perform special tasks, including: a. System management, device, energy and heat management. Server-related reliability, availability and serviceability (RAS) functions are typically implemented using SMM. SMM is typically entered by sending a system management interrupt (SMI) message to the processor. Upon assertion of the SMI, the processor saves the current processor context, also called the processor memory state, in a portion of the system memory specifically assigned to the SMM, called System Management Random Access Memory (SMRAM), and maintains the SMI processing code which is included in SMRAM. When the SMI processor has performed its operations, it executes a special (SMM only) resume command that causes the processor to reload the backed-up processor context from the SMRAM and resume execution of the interrupted task.

In a multiprocessor system, an SMI message is generally sent to all processors. The SMI fabricator selects a processor, called SMM Monarch, to process the event. This processor waits for all other processors within SMM to assemble before processing the SMI event. Non-Monarch processors linger in SMM until the monarch has performed event processing. When the SMM event has been processed, the monarch signals the other processors to exit SMM. This synchronized entry and exit behavior is implemented to avoid any resource conflicts between the two parallel environments (OS and SMM). That is, when some processors are active in the OS environment and the remainder are active in the SMM environment at the same time, they are likely to modify one shared resource and thereby interfere with the other's operations, causing the system to crash. In addition, certain SMM events can only be processed by a specific logic processor or a set of logic processors. A transmission ensures that this condition is always met, since all logic processors enter SMI.

Therefore, SMI processing in a multi-processor system is complex and can consume all system resources, thereby preventing the processing of other useful work, since a processor, while in SMM, is not available to the operating system.

Brief description of the drawings

1 is a block diagram of a processor according to an embodiment of the invention.

2 FIG. 10 is a block diagram of a multiprocessor system according to an embodiment of the invention. FIG.

3 is a flowchart of a method according to an embodiment of the invention.

4 is a flowchart of a method according to an embodiment of the invention.

Detailed description

In various embodiments, on-die memory may be used as an alternative to using external physical memory to store the memory state of individual threads at SMM entry / exit. In contrast, current systems rely on external physical memory to enter and exit SMM. This SMM dependency on system RAM results in scaling, performance and reliability related limitations in mission critical applications, and can be avoided by using an embodiment of the invention. It should be noted that the term "thread" as used herein may also refer to a hardware thread that includes memory in an architectural state processor that is connected to a process (eg, a register file and connected configuration and status registers). As used herein, the term "hardware thread" is used synonymously with the term "logic processor". Each processor core may include a plurality of logic processors, each of which has an associated architectural state memory, but which may have other core resources, such as core resources. As front-end units, execution units and so on, shared.

In various implementations, the on-die memory provided may be the memory state of any active threads during an SMM, an on-the-static RAM (SRAM) or a register file may be in the processor itself to serve as a smaller associated memory for storing the memory state. Some processors may include on-die SRAM for specific tasks such as power management, e.g. B. an OS-managed energy-saving state, such. For example, according to an Advanced Configuration and Power Interface (ACPI) state (eg, C6 state or other power management operations). In such processors, a portion of this SRAM, which is split on a per-thread basis, may be reserved for the SRAM memory state of each thread. As an example, each logic processor may use 1 kilobyte (KB) of SRAM memory for SMM memory state. If a given processor can not emit this amount of SRAM for SMM memory state, an embodiment may be implemented such that it can employ SRAM reserved for C6 operations. In this case, C6 / C7 transactions within SMM may be returned to a lower power-saving state (eg, C3) to ensure mutually exclusive use of the shared SMM memory state SRAM space. Some processors do not implement an associated SRAM for backing up C6 states and instead use part of a Last Level Cache (LLC) to store processor state during a C6 state save. In these processors, the SMM memory state may be stored in the LLC.

Once stored, this internal SMM memory state can be accessed in a variety of ways. For example, the internal state may be accessed using model-specific register (MSR) addressing on a per-thread basis or a backward compatible mechanism. Conventionally, a processor may access an SMM memory state at certain system memory addresses. The backward compatible mechanism includes logic in the processor that captures a logic processor's access to these legacy memory addresses and redirects them to the appropriate SRAM location. Such a redirect can be implemented if absolute backwards compatibility is required with existing basic input / output system (BIOS) software. These MSRs can only be read or written in SMM mode and follow restrictions associated with the SMM memory state. If a logic processor needs access to a memory state of another processor, this can be accomplished via a software protocol.

In some embodiments, an associated processor identifier leaf (eg, a CPUID leaf) or portion thereof or a feature-enabled MSR (Model Specific Register) bit may be used to facilitate use of the internal SRAM. It is referred to 1 showing a block diagram of a processor according to an embodiment of the invention. As in 1 shown, the processor can 100 be a multi-stage pipelined out-of-order processor. processor 100 is shown in a relatively simplified view to illustrate various features used in conjunction with the SMM techniques described herein. As shown, processor can 100 a multi-core processor, including a variety of processor cores 105 , and which may be formed on a single semiconductor die. While doing so with four such cores in the embodiment of 1 however, the scope of the present invention is in no way limited in this respect. As in further 1 can be shown in processor 100 additional components may be present. For example, an integrated memory controller (IMC) 108 be present, along with a static random access memory (SRAM). 106 , As discussed above, in some implementations, this memory may be used to store contextual state according to an embodiment of the invention that would otherwise be stored in SMRAM. Still further can processor 100 a Last Level Cache (LLC) 109 which may be a shared cache shared by all processor cores.

As in 1 shown includes processor 100 Front-end unit 110 which can be used to obtain macro instructions to be executed and prepare them for later use in the kernel. Front-end unit 110 can z. A command prefetcher, a command decoder, and a trace cache along with microcode memory and micro-instruction (μOp) memory. The instruction prefetcher may be e.g. B. Obtain macro instructions from memory and supply them to the instruction decoder to decrypt them into primitive form, ie, μOp for execution by the processor. The trace cache can take decrypted μOp and assemble it into ordered program sequences. It goes without saying that even more components and features in front-end unit 110 can be implemented.

Between the front-end unit 110 and the execution units 120 is an OOO (out of order) engine 115 which can be used to receive the microinstructions and prepare them for execution. More specifically OOO-engine 115 various buffers for the retirement of the microinstruction sequence and the allocation include various resources required for execution, as well as providing the renaming of logical registers in the storage locations within various register files, such as a register file 130a , register file 130 can include separate register files for integer and floating point operations. It should be noted that several register files 130a -N, each for a different logic processor. Additional registers, namely state and configuration registers 135 , may also be present. As shown, each set of registers 135a -N for another logic processor. These various registers can be used to configure a core for different modes of operation, and to provide state information regarding the thread and different instructions being executed.

In the example that is in 1 As shown, such registers may be an SMM memory state register 136 include. In various implementations, a plurality of such registers may be present, each associated with a given thread operating on the core. As discussed above, such a register may include an indicator, e.g. An enable bit, to allow the state of the thread to be stored, e.g. Inside the core even when entering SMM. If this indicator is not enabled, when SMM enters, the context of a thread is instead stored in SMRAM. In some embodiments, this MSR may include other bits that may control other processor features. In some embodiments, this register file may be 135 , which contains the indicator, can only be made changeable in SMM, preventing it from being maliciously altered by a malware component outside of SMM, which increases both the security and the robustness of the system.

As further shown, register file 135 also one or more SMM state indicator registers 138 include. Such indicator registers may be in the form of a bitmap or bit vector, with each logic processor having a location to indicate when the logic processor is prevented from entering an SMM, or whether the logic processor is in a long time Process execution is located. In one embodiment, a separate register may be present for each such display. Alternatively, a single register may be present, and a logically combined indicator may therefore be used to indicate the presence of one of these states for each logic processor. Further details regarding the use of these registers are described below.

With further reference to 1 , can use different resources in execution units 120 in various logic units for integer, floating-point and single-instruction-multiple-data (SIMD) as well as in other specialized hardware. The results can be sent to a return unit 140 which is operated to determine whether executed instructions can be properly retired and the resulting data included in the processor's architectural state, or whether one or more exceptions have occurred to prevent proper retirement of the instructions.

As in 1 shown is the rearrangement unit 140 with a cache memory 150 coupled, which in one embodiment may be a low level cache (eg, an L1 cache), but the scope of the present invention is not limited in this regard. Also execution units 120 can go directly to the cache 150 be coupled (not in 1 shown). From cache memory 150 The data communication can be done with higher level caches, system memory, etc. This high level is in the embodiment in 1 however, this is not intended to limit the scope of the present invention in any way. For example, other embodiments may be implemented in an in-order processor.

By storing the SMM memory state internally in the processor, the reliability and robustness of the system can be improved. That is, the physical memory, which is typically a set of external dynamic random access memory (DRAM) devices on which the SMRAM remains, is susceptible to memory errors. Without an embodiment of the invention, SMM operations run from this external memory and are therefore not reliable under fault conditions. If an embodiment of the invention is used instead, the reliability of SMRAM memory can be improved by running a nonvolatile space SMI processor when processing errors. For example, the SMM processor may run from a more robust memory, such as BIOS flash or external SRAM, while processing memory errors. Also, if SMM memory state is internal to the processor, the architectural state of this memory can only be exposed by external software MSRs. The microarchitectural state of the processor needed to restore machine execution state after SMM code has executed a "resume (RSM)" command need not be disclosed to the outside software, as this is not a legitimate use for has this internal machine state. This also means that malicious software code does not have access to the sensitive microarchitecture state (as it would otherwise if the memory of the backed up data is in SMRAM), making the machine more secure and robust.

Embodiments may also improve performance and latency. Many server applications / operating systems are NUMA (nonuniform memory architecture) optimized, and BIOS typically configures memory so that all SMRAM, which is a contiguous memory area, is mapped to a single socket. Therefore, all SMM memory state / state recovery operations appear as remote write / read accesses for all logic CPUs, except those contained in a socket where the SMRAM is local. Performance analysis for a four socket server configuration, each comprising 12 cores, indicates that SMM memory state writes may be limited by the coupling structure and memory bandwidth and may take up to 5 microseconds. As applications become more NUMA-optimized, processors can allocate fewer buffers for remote traffic. When this happens, SMRAM memory state write and read operations take even more time. Operating systems typically have a limit to how long a CPU can stay in SMM to maintain acceptable real-time performance and to avoid timeouts on high-speed network connections.

Exceeding this limit will affect the OS's responsiveness, application latencies, and may also cause the operating system to malfunction. Accordingly, using an on-die SMM memory state in accordance with one embodiment of the invention reduces latency and therefore allows additional time allocated to an SMM processor to service the SMM event (the useful work of the SMM).

Additionally, embodiments may improve scalability. In a multi-processor system, when an SMI occurs, each thread in the system must store its memory state in its own associated memory state area in external system memory as defined and reserved by the system BIOS during system boot. The total amount of physical memory that is to be reserved as the SMRAM space required to capture all storage states of all threads in the system increases linearly with the number of threads in the system. In a multi-core, multi-socket system with symmetric multi-threading support, the amount of space can be quite large (and may be on the order of about 256 KB in one embodiment). By providing on-die storage for SMM memory state, the need for an ever-growing SMRAM area to accommodate all cores and associated threads thereof can be avoided, thereby simplifying scaling. It also eliminates the need for BIOS to find and map a unique, non-overlapping area in SMRAM for each thread. Still further, this also saves the memory protection areas from being implemented in silicon. For hot plug scenarios, the architecturally defined SMM storage state area in SMRAM is less than 1 MB. Without an embodiment of the invention, BIOS sets a memory protection area and stores data to avoid OS attacks and / or interference as new processors are added. Embodiments eliminate the need to do so because the memory state is no longer stored in the visible OS memory.

It is referred to 2 showing a block diagram of a multiprocessor system according to an embodiment of the invention. As in 2 shown, includes multiprocessor system 200 a variety of processors 2101 - 210n (generally processor 210 ). While doing so with four such processors in the embodiment of FIG 2 is shown, the scope of the present invention is not limited in this regard. As with the implementation in 2 As shown, there is a NUMA (nonuniform memory architecture) system, so system memory 2201 and 2203 the processors 2101 and 2103 via the coupling structure 2171 and 2173 is assigned locally. Therefore requires access to memory through processors 2102 and 210n communication via one of a variety of point-to-point (PTP) coupling structures 215 with one of processors 2101 and 2103 , As with the implementation in 2 shown contains memory 2201 which can be a DRAM, a SMRAM 225 , In this NUMA architecture is SMRAM 225 the system management memory for the entire system. Accordingly, without an embodiment of the invention, each processor must have context in its SMRAM upon SMM entry or exit 225 save / save again. This in turn causes a high consumption of bandwidth on PTP coupling structure 215 and coupling structure 2171 and increasing latency on entry and exit from the SMM.

Accordingly, in various embodiments, each processor 210 SRAM 216 in addition to one or more cores 212 and an integrated memory controller 214 include. In various embodiments, SRAM 216 for storing SMM memory states. That is, when a system management interrupt occurs, the context state may be for the various logic processors of each processor 210 locally in his SRAM 216 which reduces the need for communication of state information with SMRAM 225 is avoided. In other embodiments, this context state may be stored in on-die memory instead of in an associated on-die memory, e.g. A register file or other location, such as a cache memory. While this particular implementation in the embodiment of 2 is shown, the scope of the present invention is not limited in this regard. For example, embodiments may be further used with a unified memory architecture system.

It is referred to 3 showing a flowchart of a method according to an embodiment of the invention. As in 3 shown, can process 300 be executed to process entry into SMM, without access to SMRAM for saving the state information. It should be noted that because of the simplification of the discussion, it is believed that there is only a single hardware thread, although in many implementations, multiple threads may enter SMM together. As in 3 shown, can process 300 by receiving a system management interrupt (block 310 ) kick off. Upon receipt of this interrupt, a current active state (eg of a given hardware thread) may be saved in an on-die memory (block 320 ). As discussed above, this on-die memory may be associated SRAM, SRAM used for a different purpose (eg, power management states), register memory, on-die cache, and so on.

With further reference to 3 , a processor state is modified to match an SMM entry state, e.g. As defined by processor specification (Block 330 ). This state includes values for various control and configuration registers as well as output values for a register file. This determination therefore prepares an SMM execution environment suitable for an SMM processor by loading predetermined values associated with the SMM entry state into the state memory. If the SMM state has been set, control continues to block 340 where SMM is executed using code and data from SMRAM (block 340 ). Accordingly, a desired SMM operation can be performed. While the scope of the present invention is not limited in this regard, examples of SMM operations include power management operations, error processing operations, and so forth.

It can then be determined whether SMM operations have been performed (diamond 350 ). If not, execution in SMM can continue. When executed, the processor executes a resume command (block 360 ). As a result of this command, the previous state may be loaded from the on-die memory back into the registers of the processor (block 370 ). The processor may then resume execution of the thread corresponding to that previous state that has been put back into the active state (block 380 ). While this particular implementation in the embodiment of 3 is shown, the scope of the present invention is not limited in this regard. For example, in some embodiments, instead of performing SMM operations of SMRAM, particularly when the SMM is to process an error, such as an error message. For example, a DRAM error, embodiments instead SMM state information, SMM code and data from a non-volatile memory such. As a flash memory received.

As described above, silicon storage of an active state can reduce SMM latency. Embodiments may further reduce latency by enabling faster entry into SMM in certain situations, as will now be discussed.

SMM latency is defined as the length of time that a single-SMI processor is in the SMM environment. There are two major contributors for complete SMM latency, processor overhead, and OEM BIOS code. This latency must be kept under control to avoid side effects on the OS environment, such as: B. timeouts and clock shifts to avoid. Other requirements require that this latency be reduced, which will be difficult to implement. It is currently mandated that the SMI latency should be below about 190 microseconds. New utility models, such as Internet portal data center and utility computing, expect more predictable application latencies. As a result, OS providers are pushing for further reductions in SMM latency. On the other hand, other technologies have the potential to increase SMI latency over time. For example, the industry's push for multi-core processors means that an SMI fabricator has to assemble a growing number of processor cores. New SMM-based capabilities also put further pressure on SMM latency. For example, high performance RAS capabilities are dependent on SMM. In addition, some OEMs are putting SMM to deliver unique power management capabilities to differentiate their products. Many OEMs are known to produce SMIs that are up to 8 times per second high.

Certain instruction set architectures (ISAs) include instructions such as: For example, a restore and invalidate command (eg, wbinvd) invalidates all cache lines and writes them back to memory. These operations may take a very long time to execute, e.g. In the size range of 10 ³ to 10 ⁷ processor cycles, especially for processors that support large cache sizes. In addition, there are certain processor states where an SMI response may be delayed (eg, C ³ and C ⁶ low processor states). Overall, these command and processor states may be termed "long drain" states, which in the definition means a command or process that may take an unusually long number of cycles to execute (eg, on the order of 10 ³⁾ Bars), and which can delay entry into SMM. In one embodiment, any procedure that delays SMM entry by more than 5 microseconds may be termed a long expiration. With regard to SMM, when one or more logic processors are in a long run, it delays SMM entry.

As explained above, the SMM monarch waits until all expected logic processors have entered SMM. Upon entering SMM, each processor sets its own bit in SMRAM, indicating that it has entered SMM. The monarch waits until all expected processors have set their bits. If one or more logic processors are in a long run and enter SMM late, they will stall the SMM monarch, increasing SMM latency. In addition, there are certain architectural states, such. B. Wait For Startup Interprocessor Interrupt (WFS) and TXT Sleep states, where an SMI event is inhibited. When the OS / BIOS places one or more logic processors in an SMI-inhibited state, it does not enter SMM until the OS / BIOS explicitly releases it from that state. Because an SMI event puts all other processors in SMM, the OS is unable to unmask the SMI. In this scenario, the SMM monarch must rely on a long timeout to determine the presence of an SMI-inhibited processor. These timeouts delay SMM rendezvous and either increase overall SMM latency or decrease the amount of time available for SMM event processing.

In various embodiments, the need for timeouts within SMM can be avoided, even where some logic processors are in a long run. Removing such timeouts can improve the average SMM latency by 10-20% and worst-case SMM latency by at least a few milliseconds.

Embodiments rely on the fact that a processor that is in a long-running or SMI-inhibited state is unlikely to access a shared resource. In addition, such a processor has probably not caused the SMI, and therefore its participation is not necessary for SMI processing. Therefore, the SMM monarch can continue SMM processing before such a processor has entered an SMM.

However, before proceeding, the SMM monarch must be able to reliably determine which processors are in a long-running and / or SMI-inhibited state. In order to determine processors that are busy in a long-running or SMI-inhibited state, embodiments may provide indicators for these states, such as: B. by bitmaps. In one embodiment, such indicators may be provided via globally visible configuration registers called LONG_FLOW_INDICATION and SMI_INHIBITED_INDICATION. In this embodiment, one bit may be allocated to each logic processor in a socket. As an example, the registers of register 138 from 1 being represented. In implementations where processor microcode is involved in entry and exit from long runs and SMI inhibited states, the microcode / hardware may populate these register bits. Some of the long runs may last longer than 5 microseconds and therefore the ability to not wait for these processors in these states can provide significant savings in SMM latency. Future processors may require more than 5 microseconds for SMM microcode entry process and may themselves be considered a long process. The SMM monarch can wait for all processors to be expelled, that is, they either join the SMM or are reported to be in a long expiration or SMI-inhibited state. In order to assist in such determination, one or more tables, such as those shown in FIG. B. bitmaps stored in SMRAM can be used as described below.

In one implementation, the monarch processor saves its state and runs the SMM header code before performing a check on the indicator registers. These steps can easily be more than 0.5 microseconds claim. This duration is much longer than the runtime for any in-flight disruption, ensuring that there is no race between SMI delivery to a core and reading its indicator registers. If the delay is lower in certain configurations, the Monarch processor can use a small delay loop to compensate for this.

It is referred to 4 showing a flowchart of a method according to another embodiment of the invention. In particular shows 4 a flowchart for processing an entry and exit from SMM when all logic processors do not have to come together in the SMM state. In this way, the latency associated with waiting for all logic processors prior to performing SMM operations can be avoided. As in 4 shown, can process 400 by generating an SMI event (block 410 ). This SMI event can be propagated to all threads. It should be noted that in order to facilitate the discussion, it is believed that the threads of 4 with a single processor socket, although implementations can be used to aggregate SMM across multiple sockets.

Next, an indicator may be set in an SMM indicator memory map for each thread entering an SMM Rendezvous state (Block 420 ). It goes without saying that first of all, various preparatory measures for entry into SMM are executed by the threads, e.g. For example, securing the condition as described above with reference to FIG 3 described. Each thread that enters the SMM Rendezvous state can set an indicator in an SMM indicator memory map that can be stored in SMRAM. In one embodiment, this memory map may be a bitmap in which each logic processor is connected to a bit of the memory map, and where logic processors of each socket may be split into different segments of the memory map. Therefore, if a given thread enters the SMM, its corresponding bit in the bitmap can be set. One of the threads within the SMM can then be selected as a monarch or executing thread (Block 430 ). In various embodiments, the determination of which thread is the executing thread may vary. For example, the monarch may be predetermined (eg, Logic Processor 0 on socket 0) or dynamically selected via a dial mechanism.

With further reference to 4 , each thread can then determine whether it has been selected as a monarch (diamond 435 ). If not, the thread may enter a sleep state where it waits for the monarch thread to signal execution (Block 470 ).

Accordingly, control for the monarch thread continues to block 440 , There it can determine an ACCOUNTED state for all threads. In one embodiment, this status may be based on various configuration registers, the SMM indicator memory map, in addition to a thread present memory map, which may also be present in SMRAM. This present memory map may be a bitmap similar to that of the SMM indicator memory map, and may be set during SMM initialization to indicate the threads present in the system. In one embodiment, the determination at block 440 a bitwise OR operation as follows: OR (LONG_FLOW_INDICATION, SMI_INHIBITED_INDICATION, IN_SMM_INDICATION) where LONG_FLOW_INDICATION is obtained from a status register storing a bit vector, each bit of which indicates whether a corresponding thread is in long-duration operation SMI_INHIBITED_INDICATION is obtained from a status register storing a bit vector, each bit of which indicates whether a corresponding thread is in an SMI inhibited state, and IN_SMM_INDICATION is the SMM indicator memory map. The result of the bitwise OR, ACCOUNTED, can be stored in a bitmap, e.g. In SMRAM. After this analysis, the controller continues to rhombic 450 where it can be determined if the ACCOUNTED state is active for all existing threads (diamond 450 ). This can be determined based on a comparison between the result of the ACCOUNTED operation and the existing memory map. If not, the controller continues to block 440 , Otherwise, the control continues to block 455 where the SMI event can be processed. The monarch thread can thus execute the desired SMM code. Upon completion of the SMM executed by the Monarch thread, control continues to block 460 , At block 460 the ACCOUNTED state and the SMM indicator memory map can be reset (block 460 ). That is, the monarch thread can reset the values in both of these bitmaps. Subsequently, the monarch thread can signal other logic processors that they can return from SMI (Block 465 ). This frees the other threads from their hold. Accordingly, all threads at block 475 return from SMM. While this particular implementation in the embodiment of 4 is shown, the scope of the present invention is not limited in this regard.

Embodiments thus enable execution of SMM processors without memory dependency, thereby improving reliability. This mechanism also addresses performance and scalability issues associated with SMM, so SMI processing can avoid becoming a bottleneck in multi-core / multi-socket systems. Embodiments therefore avoid execution of SMM code with DRAM dependency, thereby enabling high availability utility models in which SMM code diagnoses and corrects memory errors.

Embodiments further allow entry into SMM with reduced latency in the presence of a logic processor that is in a long drain or SMI inhibited state. In contrast, there is currently no reliable mechanism by which SMM code can determine whether one or more processors enter SMM late or are in an SMM inhibited state, and therefore set a timeout that is higher than that longest expiration state. This solution increases SMM latency and reduces OS response in real time, in addition to the fact that it is unreliable and difficult to implement, and can be handled using one embodiment of the invention.

Embodiments may be implemented as code and stored on a storage medium containing instructions that may be used to program a system for executing the instructions. The storage medium may include, but is not limited to, any type of disc, u. a. Floppy Disks, Optical Disks, Solid State Drives (SSDs), Compact Disk Read Only Memories (CD-ROMS), Compact Disk Rewritables (CD-RWs) and Magneto-Optical Disks (MO), Semiconductor Devices, such as Read-Only Memories (ROMS), Random Access Memories (RAMs), such as Dynamic Random Access Memories (DRAMs), Static Random Access Memories (SRAMs), Erasable Programmable Read-Only Memories (EPROMs), Flash Memories, Electrically Erasable Programmable Read-Only Memories (EEPROMs ), magnetic or optical cards or any other type of storage medium suitable for storing electronic commands.

Although the present invention has been described in terms of a limited number of embodiments, those skilled in the art will appreciate that many other modifications and variations thereof are possible. The appended claims are intended to cover all such modifications and variations that are within the spirit and scope of the present invention.

Claims (24)

Apparatus comprising: a processor core to execute instructions and to enter a system management mode (SMM), where upon entering the SMM the processor core is to store an active state present in a state memory of the processor core into a memory unit of the processor core , and set an SMM execution environment by entering values associated with the SMM into the state memory. The apparatus of claim 1, wherein the processor core is to disclose information stored in the memory unit as machine specific registers (MSRs) that are accessible only by SMM code. The apparatus of claim 1, further comprising a first state register for storing an indicator to indicate that the processor core is capable of storing the active state in the memory device and not in a system management random access memory , SMRAM). The apparatus of claim 3, wherein the first state register can be updated only by an agent executing in the SMM. The apparatus of claim 3, wherein the processor core is to execute SMM code stored in the SMRAM. The apparatus of claim 5, wherein if the SMM is to clear a memory error, the processor core should receive a recovery SMM code from a non-volatile memory and should not receive the SMM code from the SMRAM. The apparatus of claim 3, further comprising a second state register for storing an indicator to indicate that a logic processor of the processor core is in a long expiration operation. The apparatus of claim 7, further comprising a third state register for storing an indicator to indicate that a processor processor logic processor is in a system management interrupt (SMI) inhibited state. The apparatus of claim 8, further comprising an SMM indicator memory map to store an indicator of each logic processor of the processor core that has entered SMM. The apparatus of claim 8, wherein the first, second, and third state registers are non-writable outside of SMM. The apparatus of claim 1, further comprising a monarch processor to execute the SMM without all the logic processors of the processor core merging into the SMM. The apparatus of claim 11, wherein the monarch processor is to access a first status register indicating that a processor processor of the processor core is in a long expiration operation, a second status register indicating that a logic processor of the processor core is in an SMI inhibited state, and an SMM indicator memory map indicating that each logic processor of the processor core has entered SMM and based on determining to perform a requested SMM operation without all logic processors have come together. The apparatus of claim 12, wherein the monarch processor is to perform the requested SMM operation without all of the logic processors merging when each logic processor of the processor core has entered SMM, in a long expiration operation, or in an SMI-inhibited state. Method, comprising: Determining whether all threads executing on a processor have entered a system management mode (SMM) rendezvous state responsive to a system management interrupt (SMI) event are; and if not, determining if the remaining threads are performing a long expiration operation or in an SMI inhibited state, and if so, using a Monarch thread to process the SMI event while the remaining threads execute the long expiration operation or are in the SMI inhibited state, otherwise waiting for the remaining threads to enter the SMM rendezvous state before processing the SMI event. The method of claim 14, further comprising setting an indicator in an SMM indicator memory map for each thread entering the SMM Rendezvous state. The method of claim 15, further comprising: Setting an indicator of a first status register of the processor to indicate that a thread is in a long expiration operation; and Setting an indicator of a second state register of the processor to indicate that a thread is in an SMI inhibited state; and The method of claim 16, wherein the determining comprises performing a bitwise OR operation between the SMM indicator memory map, the first state register, and the second state register. The method of claim 14, wherein upon entering the SMM, the monarch thread is to store an active state present in a state memory of the processor into a memory unit of the processor and store an SMM state in the state memory. System comprising: a first processor, comprising a first kernel for executing instructions, and entering a system management mode (SMM), a first indicator for indicating whether a thread executing on the first kernel is in one long expiration operation, a second indicator to indicate whether the thread is in a system management interrupt (SMI) inhibited state, and a storage device, where upon entry into the SMM, the first core one is to store an active state present in a state memory of the first core into a memory unit and store an SMM execution state in the state memory, the memory device being associated with the memory of the active state during the SMM; a second processor comprising a second core for executing instructions and entering the SMM, a first indicator for indicating whether a second thread being executed on the second core is in a long expiration operation, a second indicator Indicator to indicate whether the second thread is in the SMI inhibited state, and a second memory unit, wherein when entering the SMM, the second core has an active state present in a state memory of the second core in the second one Store memory unit and store an SMM execution state in the state memory, wherein the second memory unit is associated with the memory of the active state during the SMM; a dynamic random access memory (DRAM) coupled to the first and second processors, wherein a portion of the DRAM is a system management random access memory (SMRAM) for the system. The system of claim 19, wherein the DRAM is coupled to a non-uniform memory architecture (NUMA), the second processor to communicate with the DRAM via the first processor. The system of claim 19, wherein the second processor is not to store the active state in the SMRAM responsive to an SMI signal and instead to store the active state in the second memory device. The system of claim 19, wherein the first processor includes a monarch processor to perform an SMM operation after an SMM rendezvous condition, wherein at least one of the first and second processor logic processors does not enter the SMM rendezvous state , The system of claim 22, wherein the at least one logic processor is in a long drain operation or in an SMI inhibited state. The system of claim 22, wherein the monarch processor is to access a first bitmap indicating whether any logic processor of the first processor is in a long expiration operation, a second bitmap indicating whether any logic processor the first processor is in an SMI inhibited state and a third bitmap indicating whether each logic processor of the first processor has entered the SMM rendezvous state and based on determining whether the SMM operation is in progress when the at least one logic processor does not enter the SMM Rendezvous state.

Images