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 97265C7618A for ; Tue, 14 Mar 2023 17:38:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C23C6B0072; Tue, 14 Mar 2023 13:38:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 272998E0002; Tue, 14 Mar 2023 13:38:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13AB18E0001; Tue, 14 Mar 2023 13:38:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 00FA26B0072 for ; Tue, 14 Mar 2023 13:38:50 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C9CD21C64FD for ; Tue, 14 Mar 2023 17:38:50 +0000 (UTC) X-FDA: 80568214020.08.601025E Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf12.hostedemail.com (Postfix) with ESMTP id 3856C4000F for ; Tue, 14 Mar 2023 17:38:46 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=d8tNvDK5; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf12.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.65 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=1678815528; 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=Qa392Hnhf41kNptY4jU8LeMDdlEy3CcMeQ0XSdmtCtM=; b=zGEbnekMhsaZPLuLCyzXxFQk80MPfJ0TDrnK0FfoQJfqCobD1Se8SiB9hdxhfBLDWbhCZK EthA2aWcsWsHwjZbwkUriQmFSfqvOWs0L5BMdnQSTlYT/Jhd+cbz/NGtYr2/w2KHiOtrGF xY9iXk+Ff2rfP4MYkLF+SIKjGPz6yMo= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=d8tNvDK5; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf12.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.65 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678815528; a=rsa-sha256; cv=none; b=ixwkoqgI36TWSb5kuGo9wQWDaW4ZAFTvr/C3/m8myCSmzBJpOYIQDGMAzT1iQre4F1jyOT TD+Kg1xMd1ObflZonVsAnFLVvZIZC2JOUiAQaPdB+TvCUWc/DW6QlJ2IoSojstRhFoCXfk lcLEoln34jaGmU6Cz93NG1zPlFZQCL4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678815527; x=1710351527; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=VgVMyqR52hv/pd5q0qh+OTN2bW5UJL20CGoQOlOBteg=; b=d8tNvDK5wS+Q7fKn7cJ1n/tQPfln4E+eBAcn72Qur4b5RA4NrA/l9+fT 8860qG2zV+38JauDWlm3S6sfOI0DWxN71ZYa4/z8vJSjfF8lkalEtrh8b BWwtQF5PttRvg0TQnD+jdFsy7DlCGHfHkcjKKXlddNbE8e9IvzJTSmI1H IrNzJHN0uBV0BeKwnS/XCvTa0QXGXXvfV0e7X9t/doa+ecPc4iQhRSWoj RSLkNlUh/W9NKmi04tTxRaUf8pnOIrz3b1l2mC2o457OdxbpsY6NOSpOc CW5dF8QewYNUMPQV65alSv8mfC9z7ERFBWkunXrZ51lp7xusk7RE3jDed Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10649"; a="339862612" X-IronPort-AV: E=Sophos;i="5.98,260,1673942400"; d="scan'208";a="339862612" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Mar 2023 10:38:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10649"; a="789458862" X-IronPort-AV: E=Sophos;i="5.98,260,1673942400"; d="scan'208";a="789458862" Received: from jstavrid-mobl.amr.corp.intel.com (HELO [10.212.216.78]) ([10.212.216.78]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Mar 2023 10:38:33 -0700 Message-ID: <082f3086-b5e1-1842-6039-fb6710df6ca8@intel.com> Date: Tue, 14 Mar 2023 10:38:33 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v10 05/16] x86/virt/tdx: Add skeleton to enable TDX on demand Content-Language: en-US To: Isaku Yamahata Cc: "Huang, Kai" , "kvm@vger.kernel.org" , "david@redhat.com" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "linux-kernel@vger.kernel.org" , "Chatre, Reinette" , "Christopherson,, Sean" , "pbonzini@redhat.com" , "tglx@linutronix.de" , "Yamahata, Isaku" , "kirill.shutemov@linux.intel.com" , "linux-mm@kvack.org" , "Luck, Tony" , "peterz@infradead.org" , "Shahar, Sagi" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "Williams, Dan J" References: <20230308222738.GA3419702@ls.amr.corp.intel.com> <96b56c5b8a5876aaf6d5ccbb81bab334b10983eb.camel@intel.com> <20230313234916.GC3922605@ls.amr.corp.intel.com> <20230314040200.GD3922605@ls.amr.corp.intel.com> <902b0166-6156-8def-a7a3-f0ce8995fa9c@intel.com> <20230314171603.GE3922605@ls.amr.corp.intel.com> From: Dave Hansen In-Reply-To: <20230314171603.GE3922605@ls.amr.corp.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 3856C4000F X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: 7ptmoy44puu76cu8tgp7o4ai4oaiq3dj X-HE-Tag: 1678815526-884318 X-HE-Meta: U2FsdGVkX1+F3owc9Y0ZByuykFGapbr53ZIOL2VDztRABoUOJmxQ+XKyEzuBWP0oerwcna6fdrK4Vgo7lW65k1iV59lAGUGiRykIYyzjALSfRDzGOvnJUSMo1d/v8GxsXpkqXqLpz9bMG6LaY+eTAz54Xz+tLIhQuqMShSiKUtecx3MdrcT5xjZrtxTeDLcYH2/kAX2fn39USszPo0MAVmIQoyZguGII9C8XIlGQMZCdIV/FYvbZwVsE2lYEJ0W5oVmDhIDb0HZJjqge+x33Qf4oxKi4zhX4J2m6I/AT32XkkpyhhfsgbRvAtSp5HUp05AreuCRzJcYaxQf8316tFQUUoh/VXU7N5PK2wpP1aBwvGpLhiCS85pdfpVjXbZ4cbrxVgg3C4Fx1xWRmoD6v3z6Emmyp4izrSmqZp3r7aNaXXuyaGYH6zL3mXRwPfO0UJOWVaBO3sYpVBoMOQmS8mq9UCwqKgJfLHjtHTaxPM2m3UU3fkzbWuWbmRSw2q5OxoFBCutP7HywmPhTSdq4fu0mbo83IzdisW98J4hIQdDkrCqBt6GYtI9kLiPYwqCdXrrOhCQs8jQX+FBCG+nKyMrMmth18KQoH5OGK7wupETCVlxM9o0N9+vCTLtRzfcxqNW1dUGUlPGv5clxtsAKDts74r4EJPzYARmZZ0MgcJHyWFVUEz3tBhssxOzIkFJ6xBqsRd9pxRjJyTMCnbpw07hv/f31bqPLm7HA1OvT0W/2yUEwwu2+P2k/cZivV4gXO3itGH5dZPpnLmDFaUn/KbGAewqy2Eai9MPe/neAjl4JGBKwZ3yvsrvRNoC0aLAPkIshL8IVVDsFmnskz5VvahbYfeKCLv/rqRdaUGtsOHKFR/ORv7gNbybYcj9NwdwJsfn/ojvRVJAjkEZWoZI/G4EGrLX4A7hTXQfjFBCxIuKcEhXVHxRGGGEkZX3s5hjayspYsEuw/YDtPQK9XQYy hC/Cu9JE onEHUO8qaCUEtPejB3jANOtVSPVGETxMvxivN5EZQyd4xNTqYSgzgv45Gpv1W0nXJkchjxiRW24ibZRmzUAU1pMpCePHqNS2Xvf8qSCD54y43p+hzNP1W7PHzoV1YJBv9yUBjvRij73Ej69YY0ls7hzKZs6xgeiC5EyzzwJ9rsorwIJ/8B9Rn7zSO0I62uH9kmh5QzYGn2nKCKPrqdWEmyHxCe5nMkBR1UxUI/1CXABm28PHZhPJQJga2h8H24CK/7R5jHyOImslfKFCiQlXD7T04RQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 3/14/23 10:16, Isaku Yamahata wrote: >>> TDX 1.5 spec introduced TDX_RND_NO_ENTROPY status code. For TDX 1.0, let's >>> postpone it to TDX 1.5 activity. >> What the heck does this mean? >> >> I don't remember seeing any code here that checks for "TDX 1.0" or "TDX >> 1.5". That means that this code needs to work with _any_ TDX version. >> >> Are features being added to new versions that break code written for old >> versions? > No new feature, but new error code. TDX_RND_NO_ENTROPY, lack of entropy. > For TDX 1.0, some APIs return TDX_SYS_BUSY. It can be contention(lock failure) > or the lack of entropy. The caller can't distinguish them. > For TDX 1.5, they return TDX_RND_NO_ENTROPY instead of TDX_SYS_BUSY in the case > of rdrand/rdseed failure. > > Because both TDX_SYS_BUSY and TDX_RND_NO_ENTROPY are recoverable error > (bit 63 error=1, bit 62 non_recoverable=0), the caller can check error bit and > non_recoverable bit for retry. Oh, that's actually really nice. It separates out the "RDRAND is empty" issue from the "the VMM should have had a lock here" issue. For now, let's consider TDX_SYS_BUSY to basically indicate a non-fatal kernel bug: the kernel called TDX in a way that it shouldn't have. We'll treat it in the kernel as non-recoverable. We'll return an error, WARN_ON(), and keep on running. A follow-on patch can add generic TDX_RND_NO_ENTROPY retry support to the seamcall infrastructure.