The development tree for Linux 7.4 has merged Dynamic PAMT, a feature that saves on the memory TDX uses for management. TDX is Intel's confidential virtual machine technology. Previously, using TDX meant reserving about 0.4% of physical memory up front for page management. The new approach allocates part of that memory only when it is needed. Hosts that use TDX lightly benefit the most. However, not all of the reserved area becomes unnecessary, and a look at the implementation shows that the savings also vary with how physical addresses are laid out.
From a fixed reservation to on-demand allocation
TDX (Intel Trust Domain Extensions) isolates a virtual machine's register state and encrypts guest memory, protecting it against access from the host and other sources. The TDX module that underpins this protection keeps management information for every page of physical memory. The area that stores this information is the PAMT (Physical Address Metadata Table).
Under the old design, the kernel supplied the PAMT when the TDX module was first loaded. In the pull request for Linux 7.4-rc1 on October 19, Intel's Dave Hansen described this burden as about 0.4% of physical memory. If you enabled TDX, you paid that cost up front, and there was little room to start small in line with how much memory confidential virtual machines actually used.
In the adopted change, the PAMT area that tracks 4KB pages is allocated at runtime. The PAMT holds management information for each page size (1GB, 2MB and 4KB), and Dynamic PAMT makes only the 4KB portion dynamic.
| What is managed | Conventional PAMT | Dynamic PAMT |
|---|---|---|
| Metadata for 1GB and 2MB pages | Allocated at initialization | Remains part of what is allocated at initialization |
| Metadata for 4KB pages | Allocated at initialization | Allocated at runtime as needed |
| Reference counters that track use of the dynamic area | Not needed for this dynamic allocation | Allocated separately |
Given this difference, it is not accurate to describe Dynamic PAMT as a feature that eliminates TDX's management cost. It is better understood as a change that reduces the burden at low usage levels by no longer claiming the finest-grained page metadata in advance.
The unit of allocation also deserves attention. According to the commit that added the reference counters, the kernel hands the TDX module a pair of pages for the PAMT, and that pair covers a 2MB range of host physical memory. The "2MB unit" is the range being tracked, not a statement that 2MB of management memory is allocated each time. Before pages in that range can be used by TDX, the corresponding management area must be prepared.
Savings depend on more than utilization
The official documentation explains that memory consumption drops while confidential virtual machines are not in use. Because the management area can grow with usage, the design favors setups where confidential virtual machines do not use up the host's memory. Conversely, as the range in use widens, the PAMT needed to manage those pages is required too. The old burden of about 0.4% cannot simply be counted as the actual reduction rate.
In addition, the dynamic area comes with reference counters to track usage. The kernel keeps a counter for each 2MB range of the host and uses it to decide whether the area is needed or can be released. This allocation does not cover only the pages TDX is actually using.
The savings from Dynamic PAMT depend not only on how much TDX is used but also on the physical address range covered by the reference counters. This is a judgment drawn by comparing how the counters are allocated, as shown in an implementation commit from September 2026, with the on-demand allocation described in the official documentation from the same patch series.
According to the implementer's explanation, the reference counters cover physical addresses from 0 up to max_pfn and consume 2MB for every 1TB of that address range. The number of terabytes of installed RAM alone is therefore not enough to judge this overhead. How far out in the physical address space the memory is placed also matters.
As an extreme assumption, the same commit notes that if the counters had to cover the entire 52-bit address space, they would take 8GB. It also indicates that on specialized platforms where a small amount of RAM is sparsely placed, Dynamic PAMT could end up with a net loss. This is not a result observed on typical servers but a limit derived from how the allocation works. An improvement that allocates counters only for the range of memory usable by TDX is left as future work.
When evaluating a host, it is closer to reality to look separately at the range of memory that confidential virtual machines use and the address range covered by the management data, rather than at the number of virtual machines. For hosts with large memory capacity that use only part of it for TDX, the ability to reduce the fixed reservation is likely to be significant.
Enabled automatically with a supporting module, but conditions remain to check
The final enablement policy is to use the feature automatically when the TDX module reports support for it. The enablement commit explains that it is enabled by default because of the value of the memory savings. Updating Linux alone does not mean every Xeon server supports this feature.
An earlier draft included a method in which users explicitly enabled it by specifying a boot parameter, tdx_dpamt=. However, in the v11 patch of September 4, this parameter was removed, and the design changed to enable the feature automatically when supported. The description in older patches that it is "disabled by default" should not be carried over as-is into configuration steps for the adopted version.
The enabled state can also be checked in the boot log. The dmesg message virt/tdx: Enable Dynamic PAMT, shown in the official documentation, is one clue. However, the PAMT allocation log shown in the documentation is only an example and is not a figure that guarantees the savings on any given host.
Known exceptions remain. The enablement commit mentions a defect in which, with certain rare BIOS keyid configurations, the TDX module reports support for Dynamic PAMT even though it cannot actually handle it. The developers judged that this is unlikely to be a practical problem and chose not to add a kernel-side workaround. Adopting automatic enablement does not mean this module-side problem has been fixed.
Also, what can be confirmed here is adoption in the mainline toward Linux 7.4. Whether the feature is available on a distribution in production depends on whether that kernel includes the change and whether the host's module supports it.
Variable Quote size is a separate preparation for post-quantum cryptography
The same TDX update also includes a change that makes the buffer size for the "Quote" exchanged during attestation flexible. Attestation is a mechanism for verifying the execution environment, and its role differs from that of the PAMT, which handles page management for memory.
Hansen's pull request explains that the previous fixed 128k buffer is too small for post-quantum cryptography, which makes Quotes larger. Because the TDX module can now enumerate the sizes it needs, the change connects the kernel to a process that queries those sizes. It is too early to conclude from this that post-quantum support for TDX as a whole is complete.
What Dynamic PAMT changes is how memory is held when TDX is enabled. On hosts with a supporting kernel and module, evaluating the management area in light of actual TDX usage and physical address layout should make it easier to allocate memory without being tied to the old fixed reservation, even when only some confidential virtual machines are used.