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 61214EB64DA for ; Wed, 5 Jul 2023 14:35:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232413AbjGEOfZ (ORCPT ); Wed, 5 Jul 2023 10:35:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45120 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231540AbjGEOfX (ORCPT ); Wed, 5 Jul 2023 10:35:23 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A074712A; Wed, 5 Jul 2023 07:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688567722; x=1720103722; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=WQapOgHKiFYlx2YNIHI1rc9qJxC2isYNrPhJNnI3h7Y=; b=HS9Q9q3+4Gv4VVR+IuriLTVR0Il6r4qzpvboPHY/+kA6EC/Sm7jW3a/w 3cyOLVLsRE6qhwb0QiytHoX94AlEaGRnjF4UEShupvX32fu/vl4DqOGzF gs9rbz3Vo6n+slJKiZsAPE1uZbxfk1AheIoauzztTfiWG1Czv7HYLIGs2 +Xu3HuNPJrbgRSOSWrAgnR+3rtn5ryJfNQousd3OpIulfKvx/ot+JEDdM By0SrSPbkKCBTbF9OXpowqYUHOXXCiOiq3QO15c096mJ7zRZ+wcWTZfwD yots5AKWIYPtIA2MqHaSHxm+ygndUGZkVaR1HvVLUZQ2czsquwnVYtzQD w==; X-IronPort-AV: E=McAfee;i="6600,9927,10762"; a="427040562" X-IronPort-AV: E=Sophos;i="6.01,183,1684825200"; d="scan'208";a="427040562" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jul 2023 07:34:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10762"; a="713217660" X-IronPort-AV: E=Sophos;i="6.01,183,1684825200"; d="scan'208";a="713217660" Received: from subrator-mobl1.amr.corp.intel.com (HELO [10.209.29.125]) ([10.209.29.125]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jul 2023 07:34:06 -0700 Message-ID: <1a8099e2-da28-6b2a-7b5a-1d6346b7f95d@intel.com> Date: Wed, 5 Jul 2023 07:34:06 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v12 07/22] x86/virt/tdx: Add skeleton to enable TDX on demand Content-Language: en-US To: Peter Zijlstra , Sean Christopherson Cc: Isaku Yamahata , Kai Huang , "kvm@vger.kernel.org" , Ashok Raj , Tony Luck , "david@redhat.com" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , Rafael J Wysocki , "kirill.shutemov@linux.intel.com" , Reinette Chatre , "pbonzini@redhat.com" , "mingo@redhat.com" , "tglx@linutronix.de" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Isaku Yamahata , "nik.borisov@suse.com" , "hpa@zytor.com" , Sagi Shahar , "imammedo@redhat.com" , "bp@alien8.de" , Chao Gao , Len Brown , "sathyanarayanan.kuppuswamy@linux.intel.com" , Ying Huang , Dan J Williams , "x86@kernel.org" References: <104d324cd68b12e14722ee5d85a660cccccd8892.1687784645.git.kai.huang@intel.com> <20230628131717.GE2438817@hirez.programming.kicks-ass.net> <0c9639db604a0670eeae5343d456e43d06b35d39.camel@intel.com> <20230630092615.GD2533791@hirez.programming.kicks-ass.net> <2659d6eef84f008635ba300f4712501ac88cef2c.camel@intel.com> <20230630183020.GA4253@hirez.programming.kicks-ass.net> <20230630190514.GH3436214@ls.amr.corp.intel.com> <20230704165836.GB462772@hirez.programming.kicks-ass.net> From: Dave Hansen In-Reply-To: <20230704165836.GB462772@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/4/23 09:58, Peter Zijlstra wrote: > If we have concerns about allocating the PAMT array, can't we use CMA > for this? Allocate the whole thing at boot as CMA such that when not > used for TDX it can be used for regular things like userspace and > filecache pages? I never thought of CMA as being super reliable. Maybe it's improved over the years. KVM also has a rather nasty habit of pinning pages, like for device passthrough. I suspect that means that we'll have one of two scenarios: 1. CMA works great, but the TDX/CMA area is unusable for KVM because it's pinning all its pages and they just get moved out of the CMA area immediately. The CMA area is effectively wasted. 2. CMA sucks, and users get sporadic TDX failures when they wait a long time to run a TDX guest after boot. Users just work around the CMA support by starting up TDX guests at boot or demanding a module parameter be set. Hacking in CMA support was a waste. Am I just too much of a pessimist?