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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DFB4AC54EBC for ; Tue, 10 Jan 2023 16:25:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4302A8E0002; Tue, 10 Jan 2023 11:25:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DFD28E0001; Tue, 10 Jan 2023 11:25:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A7BA8E0002; Tue, 10 Jan 2023 11:25:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1B47B8E0001 for ; Tue, 10 Jan 2023 11:25:48 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id DDB64A0BDB for ; Tue, 10 Jan 2023 16:25:47 +0000 (UTC) X-FDA: 80339415534.07.C08F65A Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf15.hostedemail.com (Postfix) with ESMTP id D3A6BA001C for ; Tue, 10 Jan 2023 16:25:44 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=arCXktTt; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf15.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673367945; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=P0VJFHfeWtOvVmn2tVvhklAd+2deLH7j7JJs8wlfXO8=; b=T592wDMOdJrA5DJuzbKF9HILMzE+9gSV31fEKpp1j0DU66uKVc81sI4zsuATB5sYawHUxk q1YQdovh+raJjZxfu/hbNtKdb5vy3eqBldWD98NM7tYvGknvs51mGVe6NDVorhk5awl8NK VbKZAhk5IEA0Ptwft/8sEcLPvEiyh7Y= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=arCXktTt; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf15.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673367945; a=rsa-sha256; cv=none; b=ocZeogqvo3nIF1sn3CrYsnKFSs3LE7mxxTkiDY4l62jqTkGczAHiGfvoA3g71FR2tADa8z 6qsFHzWA/VFYX2bPIU4RBg+ZNAPvRa5i8t3bHWjCySEwChgCjhG9kXU2f+nUiM46cBe3s0 6Qtq9rZ8Ir1Bq0KD3Q4pijV9qhziqHk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673367945; x=1704903945; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=eJNdrQV4oRElpWQ+CG8bXg+giTuMt6NAEdhJm7LZmYo=; b=arCXktTtPPpncHlBOUum5rBJfp+0rVNMSu5mzsDinrdpF98IOtcRHnuG /X9YA4mzGbhYXinXMHCT0kjP7f6h7zTW0j3MBAShXRQwKJkaHDgUj8W0f MZuGYAWzQ/9o+yja+avJMQczyXOgcEh8nmxDsMVJTNOSCSbVucgYAtqds ZvGUA2C1yLq+Mma4gUP5a+qlOg8hpiJirGKjSF0jJVmw7NR54O/7ja0nT jM//U9V2Rgt9pCQMuRJmZZg0Jtj7l0svigsxOGPPmmYdOeVaRRUBnmdNI m+Zpq/Ezn1vYbzusV6g+indbAuS7SY4+IkRai40oNAEX2QvWcz+fTMR+S Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="302890701" X-IronPort-AV: E=Sophos;i="5.96,315,1665471600"; d="scan'208";a="302890701" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jan 2023 08:25:43 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="607011593" X-IronPort-AV: E=Sophos;i="5.96,315,1665471600"; d="scan'208";a="607011593" Received: from svenka7-mobl1.amr.corp.intel.com (HELO [10.209.63.27]) ([10.209.63.27]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jan 2023 08:25:42 -0800 Message-ID: <755f94aa-a0cc-b7d6-ce8a-a81ff4f598da@intel.com> Date: Tue, 10 Jan 2023 08:25:42 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v8 12/16] x86/virt/tdx: Designate the global KeyID and configure the TDX module Content-Language: en-US To: "Huang, Kai" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Cc: "Luck, Tony" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "kirill.shutemov@linux.intel.com" , "Christopherson,, Sean" , "Chatre, Reinette" , "pbonzini@redhat.com" , "tglx@linutronix.de" , "linux-mm@kvack.org" , "Yamahata, Isaku" , "peterz@infradead.org" , "Shahar, Sagi" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "Williams, Dan J" References: <748adb0e8df5f804371f0587ed8fef1184177484.camel@intel.com> From: Dave Hansen In-Reply-To: <748adb0e8df5f804371f0587ed8fef1184177484.camel@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: D3A6BA001C X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: bitp8prjfsb6a6cio5kjs34j9tz9916u X-HE-Tag: 1673367944-149661 X-HE-Meta: U2FsdGVkX18tezsGD26U5Yh3CbymMHxg+D4kOBG3QDUTwDyJMY2PRCTy9crknht9H58kQo0LKaI2S32XQ8z6rbhdC6ajLvyS08DcNNz3RpyRHzfZG1bN5oeg2vhtzN+EUSUXTFLIDgVl7BphkjA5xtwBwh1weZQs5ZPPgBDTx1Saj/Q10KF1bEzfDk6obG8mtYqSppC2PrRbbEFpuZGm3neD1Y7wId6Hslw/MXGUuTUlqdXPEyLGEjAtqaXX8No5LFojearIOMd0QVrCkhbxjp123jWUOaXImzfbOqjpN6A9TITQypZR53a6upBIUFScUt1er+nFDNIk+5IZ3vmgmcki/DUxYmctxinPqA6eelkowgjB+81Cd2DUwj5/5t282RWIsxF7gDWK9oTfzcbbEdtisWdteOlrqg5eP33Immey35ghuq0FDTNu4pI7BYv6AvacFDxab+xtiusIh9hXOurfxtpgi3a53NRm7lMgO2PFa0AjtwwdPnkjm8AyvzZSJqG8PdCo6+QXtEkWoujyIDOQthBvbzQOmUytkH7bz77g5852MJzKsUGGSxZFgJnPPFkpL9eMP0+FafMNXEh77/kCCG80/7VE5ijyibmtRDsNRgPKp/bZszGsQl1mYPUTnOUw4zXm91phe8lum25Zj+cYNrh2I1YgVlZVw2wHT1i6JLxSYzVxXLJARfvMNAu8sW9xXRGBBUdgJk8Tp/ECd1RB3vBpZ2uCLB3ZgOT8FnkwWumSQ+Y9TjSWD/BGNomJdQ9YC5CmTLGv5HXDXe3GTi7FgXZSpoq0A1WJTLImoC4fqAneElXiMfgCzz+KZS8Q2sjjp7zZ/96Vxv0WHyXWV94aDIw3o/GAGXS7KpGzXFouGoIR+uvUSk8Pt3KtuMCXGubJUiR2+Zsr/YG+mEGVJA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 1/10/23 02:48, Huang, Kai wrote: >>> >>> + /* >>> + * Use the first private KeyID as the global KeyID, and pass >>> + * it along with the TDMRs to the TDX module. >>> + */ >>> + ret = config_tdx_module(&tdmr_list, tdx_keyid_start); >>> + if (ret) >>> + goto out_free_pamts; >> This is "consuming" tdx_keyid_start. Does it need to get incremented >> since the first guest can't use this KeyID now? > > It depends on how we treat 'tdx_keyid_start'. If it means the first _usable_ > KeyID for KVM, then we should increase it; but if it only used for the hardware- > enabled TDX KeyID range, then we don't need to increase it. > > Currently it is marked as __ro_after_init so my intention is the latter (also in > the spirit of keeping this series minimal). > > Eventually we will need to have functions to allocate/free TDX KeyIDs anyway for > KVM, but in that we can just treat 'tdx_keyid_start + 1' as the first usable > KeyID. So, basically, you're going to depend on the KVM code (which isn't in this series) to magically know exactly what this series did? Then, you're expecting that this code will never change in a way that breaks this random KVM code? That's frankly awful. Make the variable read/write. Call it tdx_guest_keyid_start, and increment it when you make a keyid unavailable for guest use.