[ add Mike ] On Thu, May 5, 2022 at 2:54 AM Kai Huang <kai.huang@xxxxxxxxx> wrote: [..] > > Hi Dave, > > Sorry to ping (trying to close this). > > Given we don't need to consider kmem-hot-add legacy PMEM after TDX module > initialization, I think for now it's totally fine to exclude legacy PMEMs from > TDMRs. The worst case is when someone tries to use them as TD guest backend > directly, the TD will fail to create. IMO it's acceptable, as it is supposedly > that no one should just use some random backend to run TD. The platform will already do this, right? I don't understand why this is trying to take proactive action versus documenting the error conditions and steps someone needs to take to avoid unconvertible memory. There is already the CONFIG_HMEM_REPORTING that describes relative performance properties between initiators and targets, it seems fitting to also add security properties between initiators and targets so someone can enumerate the numa-mempolicy that avoids unconvertible memory. No, special casing in hotplug code paths needed. > > I think w/o needing to include legacy PMEM, it's better to get all TDX memory > blocks based on memblock, but not e820. The pages managed by page allocator are > from memblock anyway (w/o those from memory hotplug). > > And I also think it makes more sense to introduce 'tdx_memblock' and > 'tdx_memory' data structures to gather all TDX memory blocks during boot when > memblock is still alive. When TDX module is initialized during runtime, TDMRs > can be created based on the 'struct tdx_memory' which contains all TDX memory > blocks we gathered based on memblock during boot. This is also more flexible to > support other TDX memory from other sources such as CLX memory in the future. > > Please let me know if you have any objection? Thanks! It's already the case that x86 maintains sideband structures to preserve memory after exiting the early memblock code. Mike, correct me if I am wrong, but adding more is less desirable than just keeping the memblock around?
