lkml.org 
[lkml]   [2022]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v3 00/21] TDX host kernel support
    [ add Mike ]


    On Thu, May 5, 2022 at 2:54 AM Kai Huang <kai.huang@intel.com> 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?

    \
     
     \ /
      Last update: 2022-05-05 15:52    [W:3.542 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site