From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7FA5EC433EF for ; Mon, 9 May 2022 23:27:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232467AbiEIXbc (ORCPT ); Mon, 9 May 2022 19:31:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47776 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231748AbiEIXba (ORCPT ); Mon, 9 May 2022 19:31:30 -0400 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A51478118C; Mon, 9 May 2022 16:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652138855; x=1683674855; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=prhLNqLk3ZELQbOpJAUzmyZtueVk5G/zEzxvEY8r+ug=; b=LzYVOa0I0zcsr7m68+iLi6HR1j5e7myiN5fmR9hncdMulu+lztsa2oRd lWcXYrnBUdTLa0ZrzmdtCxOGwnU32qHDviHDhqhmxeORIseB95njpF1uP TbCVjk1iCm/Nd7Fie3Mo+EyRX9zgpO6KLd2NG8CeRQiG7gt4Ru8YPm/f0 I235JQcWBE+i8z5bPkn77iAI12yBZBWOQWYLezPOs+b9yMIrKUcIadbrl 0WA/f4bhocGZLbiP117k1LrHrV5MDtGBScWpRKzCuxGOHks6VmLTxZMrw k0E+QHxRCujcSVwhdmgxEeHqyBGhF43LgJ82SJ7r2njVAWBYuzkB76Lt0 Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10342"; a="249731016" X-IronPort-AV: E=Sophos;i="5.91,212,1647327600"; d="scan'208";a="249731016" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 May 2022 16:27:35 -0700 X-IronPort-AV: E=Sophos;i="5.91,212,1647327600"; d="scan'208";a="602191441" Received: from abehrenx-mobl1.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.254.1.104]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 May 2022 16:27:31 -0700 Message-ID: <7367cae9957dba0142a878531a71f9873e1d6316.camel@intel.com> Subject: Re: [PATCH v3 00/21] TDX host kernel support From: Kai Huang To: Mike Rapoport Cc: Dan Williams , Dave Hansen , Linux Kernel Mailing List , KVM list , Sean Christopherson , Paolo Bonzini , "Brown, Len" , "Luck, Tony" , Rafael J Wysocki , Reinette Chatre , Peter Zijlstra , Andi Kleen , "Kirill A. Shutemov" , Kuppuswamy Sathyanarayanan , Isaku Yamahata Date: Tue, 10 May 2022 11:27:29 +1200 In-Reply-To: References: <664f8adeb56ba61774f3c845041f016c54e0f96e.camel@intel.com> <1b681365-ef98-ec78-96dc-04e28316cf0e@intel.com> <8bf596b45f68363134f431bcc550e16a9a231b80.camel@intel.com> <6bb89ca6e7346f4334f06ea293f29fd12df70fe4.camel@intel.com> <5c7196b517398e7697464fe997018e9031d15470.camel@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > > Hi Mike, > > > > Thanks for feedback. > > > > Perhaps I haven't put a lot details of the new TDX data structures, so let me > > point out that the new two data structures 'struct tdx_memblock' and 'struct > > tdx_memory' that I am proposing are mostly supposed to be used by TDX code only, > > which is pretty standalone. They are not supposed to be some basic > > infrastructure that can be widely used by other random kernel components.  > > We already have "pretty standalone" numa_meminfo that originally was used > to setup NUMA memory topology, but now it's used by other code as well. > And e820 tables also contain similar data and they are supposedly should be > used only at boot time, but in reality there are too much callbacks into > e820 way after the system is booted. > > So any additional memory representation will only add to the overall > complexity and well have even more "eventually consistent" collections of > { .start, .end, .flags } structures. > > > In fact, currently the only operation we need is to allow memblock to register > > all memory regions as TDX memory blocks when the memblock is still alive. > > Therefore, in fact, the new data structures can even be completely invisible to > > other kernel components. For instance, TDX code can provide below API w/o > > exposing any data structures to other kernel components: > > > > int tdx_add_memory_block(phys_addr_t start, phys_addr_t end, int nid); > > > > And we call above API for each memory region in memblock when it is alive. > > > > TDX code internally manages those memory regions via the new data structures > > that I mentioned above, so we don't need to keep memblock after boot. The > > advantage of this approach is it is more flexible to support other potential TDX > > memory resources (such as CLX memory) in the future. > > Please let keep things simple. If other TDX memory resources will need > different handling it can be implemented then. For now, just enable > ARCH_KEEP_MEMBLOCK and use memblock to track TDX memory. > Looks good to me. Thanks for the feedback. -- Thanks, -Kai