Specifications

AMD Geode™ GeodeROM Functional Specification 215
System Management Mode Software
32087C
15.7.3 Nested SMIs
VSA2 makes full use of nested SMIs. SMI nesting is enabled at all times, with the following exceptions:
• Within a critical section of a VSM
• Within the System Manager
• While handling virtual register accesses from VSMs
The effect of SMI nesting is largely transparent to a VSM. Except for the small time-slice taken to record the event in the
appropriate message queue, the interrupted VSM is unaffected. Control is normally returned to the interrupted VSM imme-
diately. The two exceptions are event priorities and virtual registers.
Since it is possible for a VSM to be interrupted, it must guard certain sections of code as a critical section. The most com-
mon example is when a VSM accesses an index/data I/O pair. It is possible for the VSM to be interrupted after writing the
index, but before writing the data. If an interrupting VSM accesses the same index/data pair, it corrupts the index from the
first VSM. To prevent this, BEGIN_CRITICAL_SECTION and END_CRITICAL_SECTION macros must surround such sec-
tions of code.
A VSM that accesses a virtual register expects the effects of that access to occur immediately. In order for this to happen,
the VSM handling the accessed virtual register must be dispatched immediately. This dispatch occurs as follows: An
EVENT_VIRTUAL_REGISTER message is entered at the beginning of the VSM message queue. That VSM is given con-
trol until the message is retrieved and serviced. Control is then returned to the VSM that accessed the virtual register.
15.8 Virtual Support Modules
Each major functional component of the SMM software is implemented as a separately compiled VSM. This architectural
feature is the key to the adaptability of GeodeROM VSA2 technology. Concatenating the modules with the desired function-
ality produces a customized VSA2 image. For example, if a platform does not require the XpressAUDIO subsystem, the
XpressAUDIO subsystem VSM is excluded from the VSA2 image. Furthermore, if VSA2 functionality is dependent on a
platform-specific feature, the VSM writer has the freedom to implement these details in a custom VSM without requiring
support from AMD.
A VSM consists of three major components: VSM header, VSM library, and a message handler. The first two components
are supplied by AMD. The third, the message handler, is the code that determines the functionality of a VSM.
Typically, a VSM writer modifies only three fields in the VSM header file: VSM_Type, VSM_Version, and EntryPoint; fields
that are unique to each VSM. The default values for the other fields are sufficient for most applications and are initialized by
the VSA2 installation code.
Each VSM must be linked to the VSM library file. This library contains the code for the system calls that comprise the API to
the System Manager.
The VSM message handler implements the functionality of the VSM with respect to messages sent by the System Man-
ager. It typically consists of an infinite loop that receives messages, parses each message and any parameter(s), and dis-
patches to routines within the VSM to handle the messages. When there are no more messages waiting for the VSM,
control is returned to the System Manager via the process of retrieving the next message. The VSM then goes dormant
until an event occurs that results in a message being entered into its queue. A sample message handler is as follows: