[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fb2d1c23-df8b-4f7f-ce3f-25ba9076e5fb@intel.com>
Date: Wed, 26 Oct 2022 16:26:06 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Kai Huang <kai.huang@...el.com>, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org
Cc: linux-mm@...ck.org, seanjc@...gle.com, pbonzini@...hat.com,
dan.j.williams@...el.com, rafael.j.wysocki@...el.com,
kirill.shutemov@...ux.intel.com, reinette.chatre@...el.com,
len.brown@...el.com, tony.luck@...el.com, peterz@...radead.org,
ak@...ux.intel.com, isaku.yamahata@...el.com, chao.gao@...el.com,
sathyanarayanan.kuppuswamy@...ux.intel.com, bagasdotme@...il.com,
sagis@...gle.com, imammedo@...hat.com
Subject: Re: [PATCH v6 00/21] TDX host kernel support
On 10/26/22 16:15, Kai Huang wrote:
> To keep things simple, this series doesn't handle memory hotplug at all,
> but depends on the machine owner to not do any memory hotplug operation.
> For exmaple, the machine owner should not plug any NVDIMM and CXL memory
> into the machine, or use kmem driver to plug NVDIMM or CXL memory to the
> core-mm.
>
> This will be enhanced in the future after first submission. We are also
> looking into options on how to handle:
This is also known as the "hopes and prayers" approach to software
enabling. "Let's just hope and pray that nobody does these things which
we know are broken."
In the spirit of moving this submission forward, I'm willing to continue
to _review_ this series. But, I don't think it can go upstream until it
contains at least _some_ way to handle memory hotplug.
Powered by blists - more mailing lists