On Mon, Jun 05, 2023 at 02:27:22AM +1200, Kai Huang wrote: > As a step of initializing the TDX module, the kernel needs to tell the > TDX module which memory regions can be used by the TDX module as TDX > guest memory. > > TDX reports a list of "Convertible Memory Region" (CMR) to tell the > kernel which memory is TDX compatible. The kernel needs to build a list > of memory regions (out of CMRs) as "TDX-usable" memory and pass them to > the TDX module. Once this is done, those "TDX-usable" memory regions > are fixed during module's lifetime. > > To keep things simple, assume that all TDX-protected memory will come > from the page allocator. Make sure all pages in the page allocator > *are* TDX-usable memory. > > As TDX-usable memory is a fixed configuration, take a snapshot of the > memory configuration from memblocks at the time of module initialization > (memblocks are modified on memory hotplug). This snapshot is used to > enable TDX support for *this* memory configuration only. Use a memory > hotplug notifier to ensure that no other RAM can be added outside of > this configuration. > > This approach requires all memblock memory regions at the time of module > initialization to be TDX convertible memory to work, otherwise module > initialization will fail in a later SEAMCALL when passing those regions > to the module. This approach works when all boot-time "system RAM" is > TDX convertible memory, and no non-TDX-convertible memory is hot-added > to the core-mm before module initialization. > > For instance, on the first generation of TDX machines, both CXL memory > and NVDIMM are not TDX convertible memory. Using kmem driver to hot-add > any CXL memory or NVDIMM to the core-mm before module initialization > will result in failure to initialize the module. The SEAMCALL error > code will be available in the dmesg to help user to understand the > failure. > > Signed-off-by: Kai Huang <kai.huang@xxxxxxxxx> > Reviewed-by: "Huang, Ying" <ying.huang@xxxxxxxxx> > Reviewed-by: Isaku Yamahata <isaku.yamahata@xxxxxxxxx> Reviewed-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> -- Kiryl Shutsemau / Kirill A. Shutemov
