Hardware support for hot-add memory in Windows Server
This topic discusses hardware support for hot-add memory in Windows Server.
This information applies to:
- Windows Server 2008 R2, Enterprise Edition and Datacenter Edition
- Windows Server 2008, Enterprise Edition and Datacenter Edition
- Windows Server 2003, Enterprise Edition and Datacenter Edition
To support hot-add memory in hardware, system manufacturers must:
- Implement a mechanism for adding physical memory regions to an operating system instance without requiring a system power operation.
- Design the BIOS to describe hot-add memory accurately to the operating system.
Hardware mechanisms for adding physical memory regions
Hot-add memory can be made available to the operating system in the following ways:
- Installing additional memory modules. The memory controller must support the ability to physically install memory modules without disrupting simultaneous access to existing memory, including any required power boundary management.
- Changing the hardware-defined partition that the operating system runs in to include additional memory ranges. The server must support hardware-enforced partitioning. The operating system runs on a subset of the hardware resources that are contained in the server. The administrator can add memory ranges to such a partition by changing the hardware partition boundaries. Such partition boundary changes are often managed from a dedicated service processor that is included in the server product.
The operating system does not distinguish between memory modules that are physically added to a computer that is designed to support that operation, and memory that materializes in an operating system instance through some combination of service processor and management console technology.
Describe hot-add memory to the operating system
The BIOS must accurately describe hot-add memory to the operating system by providing the following information:
- Provide a Static Resource Affinity Table (SRAT) to indicate where memory might potentially be hot-added
- Define memory device objects in the ACPI 2.0 namespace to describe hot-add memory ranges
- Report physical memory that is present on the system through the E820 mechanism
Note
To support hibernate/resume successfully, the BIOS must perform the POST configuration of PCI devices on resume from hibernate as it did in the previous boot, even though there will be additional physical memory in the computer.
Provide an SRAT
The Static Resource Affinity Table (SRAT) indicates where memory might potentially be hot-added (or hot-removed). At a minimum, the SRAT must contain memory affinity structures that define which ranges of memory can be hot plugged. If the system does not have NUMA properties, the proximity ID of the all affinity structures should be set to 0.
This information is used to determine the size of data structures that are used by the operating system and to determine whether the loader should put the computer into PAE mode in anticipation of future hot-added memory with physical addresses above 4 GB.
For information about the SRAT, see Static Resource Affinity Table, which contains an example of how memory that can be hot plugged is described by using the SRAT.
Define memory device objects
Starting with Windows Server 2003, Enterprise Edition and Datacenter Edition, the operating system supports describing memory as a device, as defined in section 10.12 of the ACPI 2.0 Specification. The ACPI 2.0 memory device object represents ranges of physical memory. Representing memory as a device allows the operating system to use existing Plug and Play and ACPI mechanisms to detect specific memory ranges that are added to the operating system instance.
Hot-add memory ranges must be described through ACPI 2.0 memory device objects. If memory ranges can be hot-added independently, they should be described by separate memory device objects. It is not necessary to support the full ACPI 2.0 namespace definition to define ACPI 2.0 memory device objects.
ACPI memory device objects have the same semantics as other ACPI objects with the following exceptions:
- Memory ranges described in the _CRS and _PRS objects represent physical memory that they make available to the operating system.
- The memory descriptors provided in the _CRS and _PRS methods must be less than 4GB in length, even if they are described by a QwordMemory descriptor.
- If a memory device object must describe more than 4GB of memory, the object must contain multiple ranges of less than 4GB that describe the hot-added memory.
The following example ASL code fragment defines an ACPI 2.0 memory device object that describes two memory regions:
- A 512MB region starting at 0x10000000 and ending at 0x2fffffff
- A 256MB region starting at 0x30000000 and ending at 0x3fffffff
Scope(\_SB){
Device(MEM0) {
Name(_HID, EISAID("PNP0C80"))
Name(_CRS, ResourceTemplate() {
QwordMemory(ResourceConsumer,
,
MinFixed,
MaxFixed,
Cacheable,
ReadWrite,
0xfffffff,
0x10000000,
0x2fffffff,
0,
,,)
QwordMemory(ResourceConsumer,
,
MinFixed,
MaxFixed,
Cacheable,
ReadWrite,
0xfffffff,
0x30000000,
0x3fffffff,
0,
,,)
}
}
}
Report physical memory at POST
The BIOS must use the E820 mechanism to report any memory that is present in the system at POST, even if that memory is also described by an ACPI memory device object. This ensures platform compatibility with earlier operating systems. Memory that the E820 mechanism describes can overlap memory that an ACPI memory device object describes.
The BIOS is not required to dynamically update the E820 information to reflect the hot-added memory. Because the operating system accesses E820 information during bootstrap only, there is no benefit to having E820 calls to reflect memory that is hot-added after boot.
Related topics
Hot-Add Memory Support in Windows Server
Static Resource Affinity Table