Re: [PATCH v8 8.2/9] x86/virt/tdx: Reduce TDMR's reserved areas by using CMRs to find memory holes

[Dan Williams <dan.j.williams@intel.com>]

Huang, Kai wrote:
[..]
> > So in the end, I buy that the CMR's have something to offer here. But I
> > think that "why" I mentioned above casts doubt on whether
> > for_each_mem_pfn_range() is the right primitive on which to build the
> > TDX memblocks in the first place.
> 
> We can change to just use CMRs as TDX memory blocks, i.e., always cover all CMRs
> in TDMRs, but this will have much wider impact.
> 
> The main concern is the PAMT allocation: PAMT is allocated from page allocator,
> but the CMRs -- the RAM as defined by the platform and the TDX module - - can
> cover more, and sometimes much more, regions than the regions end up to the page
> allocator.
> 
> E.g., today we can use 'memmap=' to reserve part of memory for other purpose. 
> And in the future CMRs may cover CXL memory regions which could be much larger
> IIUC.

Please do not point to memmap= as a reason to complicate the TDX
initialization. memmap= is a debug / expert feature where the user gets
to keep all the pieces if they get it wrong.

Please do not point to theoretical CXL futures as a reason not to do the
right thing in TDX initialization. The CXL TEE Security Protocol makes
CXL memory indistinguishable from DDR. It is layering violation for TDX
module initialization to add complexity and policy assumptions as if it
knows better than the published CMRs what memory resources are available
in the platform.

Please drop my reviewed-by on this patch until we have a solution and a
simple story for the recently discovered problems that CMR enumeration
solves. This includes reserve-area population and disambiguating
reserve-area enumeration from late-to-online memory resources.