How to update the RSDT/XSDT

If the WPBT is published by the core firmware, then the firmware should pre-allocate space in the RSDT/XSDT for the WPBT physical address pointer and pre-reserve memory in an ACPI memory region for the WPBT table. When the WPBT is initialized, the RSDT/XSDT is initialized to point to the WPBT.

Platform design does not always allow for the RSDT/XSDT to be pre-allocated to include the WPBT. In that case, more complex steps must be followed. An extensible firmware component must allocate physical memory for the WPBT and it must additionally publish the table in a newly allocated RSDT/XSDT that gets exposed to Windows. The process to accomplish the publishing task is outlined in the following subsections.

UEFI

UEFI firmware explicitly provides the RSDT/XSDT to an operating system through the EFI system table. The system table contains an array of configuration tables, one of which is the RSDT/XSDT and is identified by the table GUID EFI_ACPI_TABLE_GUID. On a 64-bit UEFI system, the RSDT/XSDT is always an XSDT. In this section, XSDT will be exclusively used for correctness.

During its initialization, an operating system walks the configuration table list to obtain the root of the ACPI tables. Firmware that complies with UEFI 2.1 or later supplies the boot service, InstallConfigurationTable(), which enables an extensible firmware component to modify the XSDT that is exposed to an operating system.

To modify the XSDT, an extensible firmware component must allocate a new XSDT buffer that is large enough for the original table contents as well as an additional entry for the WPBT. A firmware component must obtain the original XSDT the same way that an operating system would obtain the root ACPI table. The firmware must walk the list of configuration tables in the EFI system table, finding the XSDT by locating the table with the GUID EFI_ACPI_TABLE_GUID. The firmware must allocate a new buffer that is large enough for at least one new physical address pointer. An XSDT contains an array of 64-bit physical addresses of each ACPI table. A firmware component that allocates a new XSDT would need to allocate a buffer at least 8 bytes larger than the current size (which can be obtained by the Length field in the original table’s header). The firmware must copy the original table to the new table’s buffer, update the new table’s size, add the pointer to the WPBT at the end of the table, and update the XSDT checksum.

After a new XSDT is initialized, the firmware would call InstallConfigurationTable() with EFI_ACPI_TABLE_GUID and the new table address as parameters. After the table is updated using the InstallConfigurationTable() service, Windows will obtain the updated table when it performs its search for the table.

BIOS

The ACPI specification defines a Root System Description Pointer (RSDP), which points to the RSDT/XSDT. The RSDP is defined to be located in relatively small, traversable regions, in the first megabyte (MB) of physical memory. The search criterion for the RSDP limits the amount of time it takes to search and find the RSDT/XSDT, which is allocated towards the top of physical address space. One of the regions where the RSDP can exist is the shadowed BIOS ROM in RAM. To prevent modification of BIOS settings and code, several BIOSs program the shadowed memory as read-only. This would prevent a RSDT/XSDT publishing solution that requires a firmware component to modify the RSDP to point to a new RSDT/XSDT. Instead of publishing a new RSDT/XSDT or RSDP for the WPBT, Windows will support searching and finding the WPBT and appending the table to the ACPI namespace. This mechanism is needed if the core firmware does not pre-allocate space for the WPBT in the RSDT/XSDT and the publishing firmware component needs to extend the ACPI namespace. The rest of this section describes this mechanism in detail.

An extensible boot firmware component publishing the WPBT should allocate memory for the WPBT in low memory (below 0xA0000). During operating system bootstrap, the Windows boot loader will search for the WPBT in memory regions allocated by the firmware below 0xA0000. The Windows boot loader will scan low memory looking for a table with the WPBT’s table signature and a valid table length and checksum. The Windows boot loader will first search for the WPBT table signature. If the boot loader finds a match, the boot loader will ensure that the Length field is valid for revision 1 (at least 52 bytes) and finally check that the checksum sums to zero. If a table is found, Windows will treat the WPBT as if it were part of the RSDT/XSDT.

The low memory region is a shared resource across all boot components. Any allocations made in this region should be made as high as possible (as close to 0xA0000 as possible) and the allocation should be reflected in the int 15h, E820h physical memory map. Only the allocation for the WPBT should be in low memory. The allocation for the handoff memory buffer containing the platform binary should be in high memory, to prevent the exhaustion of memory allocated in low memory. Furthermore, the WPBT low memory requirement is a requirement only if the firmware requires republishing the table. If the firmware pre-allocates space for the table in the RSDT/XSDT, eliminating the republishing requirement, then the WPBT table should not use low memory resources.