Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp2609595rdg; Mon, 16 Oct 2023 09:17:46 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGhNk7LrNnwl8O6jrO02zJ0zfR0qouGp7e0WN4Y6LU7SFg8zPfjVTjsw0LgSdGgS+yI9iFq X-Received: by 2002:a05:6a21:7988:b0:172:6771:d766 with SMTP id bh8-20020a056a21798800b001726771d766mr13749879pzc.51.1697473066606; Mon, 16 Oct 2023 09:17:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697473066; cv=none; d=google.com; s=arc-20160816; b=eGZo91smygpInv7L2E8or9pu4RqcyIQXRVEhkd33wjyBcc+Xh6CErjEKioeRY6fMDG 62SdNGITEBE6o3gp1kUpHmKvzQPgK+bln3A2+7BW7iqs7Fk4uKZD6PrO5AYB2MvyPA7d WxKb2lZesbyf/yzuqyn1x6I77YRFsw3H5/BF20SZ4vx9Bzl/4q59u8fqL0I6DgNE9XF+ 1hMXNCxGXmVx/rUAAzYpiEvcwMioQGtq53UZ7blAHLrEZohVu/rAljZQkV1fztXnmkJn nH2pyZ7lnoRPUS6eZnLFlKYRvMuySKT2Iak7QFpnbJATF28Gw0xcYTYBaP3FVOdjppS0 VKRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=VkCbH3QgUbrPq78ZeITx48UjMZ1ABPEF9Ox96U24qWg=; fh=xdQvOLja6DS+TBIVx/0DTWdY8fnxYXFKExRAJ6j4veY=; b=KcHNFmgPh1FZZOT//Zfjik6k9QMUTj5NMD06WuqVaUkOVsmJq+MOk/Ou0ORn1kTmT5 1tNWd6itmdWOjTbA5YPZPrdl/3LhC3P71cHACy5UpdlLt525UnDzY75AfploSc+C80l7 KbfIDoAI5cekDDawz4xVMMRUDcMoxNwuW3STO3YrsD8iggQQb7HeCgfB5z+Bry0V8sNz XcOzztm+Fh/yJSHUIbqxfrWptfv3wheduX66GzRuY9S89G/213Lkts4AhG2W/o7upAI+ DUfH16mLYwHKN/qTRTqsnRYOPM98FxkO2YvbsZNAoTJo+tMLl+INf88L+BAxjZbkc4XF ziUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=hDL6UpDW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id bk14-20020a17090b080e00b002776794a75csi6346736pjb.171.2023.10.16.09.17.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Oct 2023 09:17:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=hDL6UpDW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id A0A0E802D524; Mon, 16 Oct 2023 09:17:45 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233841AbjJPQRh (ORCPT + 99 others); Mon, 16 Oct 2023 12:17:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51532 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233901AbjJPQRY (ORCPT ); Mon, 16 Oct 2023 12:17:24 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65857D49; Mon, 16 Oct 2023 09:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697473018; x=1729009018; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=sgs5wi7ZMeEhbaMFUd4+BfODjA6FoTySEiCzmdzlcyY=; b=hDL6UpDWKmAQpVMEHhLWriORRuSM0+V7uNMByAp2UWoTZKzLHZcLL3Ld zT0+dHusRlV0fKnG3A1IZ0NIFFnvNp+Da2QtBjmykXeftpWLLfjNeAEKj xQa5JCOAnZWm0haLAMYyddTpfii3K9MaxnMYwVjhcUH+Q7uA21L1nK88F d91kIZblElGRbl+/gWSklWzRlsb3k1SgwPTCaPKeFMRF6c9LcNzv7Wdkx p3tSnRFSrIdUbI/lN1x0/pckM1b3Wyt3UYiCB/fACd0dkos4bWW9Idn0o ADLeYczTRFqR24YzTVb0k+4RZDirOUgcSsROQJBAo0P9Win0KwL5nu9N+ A==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="364921809" X-IronPort-AV: E=Sophos;i="6.03,229,1694761200"; d="scan'208";a="364921809" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Oct 2023 09:15:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="846448141" X-IronPort-AV: E=Sophos;i="6.03,229,1694761200"; d="scan'208";a="846448141" Received: from ls.sc.intel.com (HELO localhost) ([172.25.112.31]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Oct 2023 09:15:45 -0700 From: isaku.yamahata@intel.com To: kvm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: isaku.yamahata@intel.com, isaku.yamahata@gmail.com, Paolo Bonzini , erdemaktas@google.com, Sean Christopherson , Sagi Shahar , David Matlack , Kai Huang , Zhi Wang , chen.bo@intel.com, hang.yuan@intel.com, tina.zhang@intel.com, Yuan Yao Subject: [PATCH v16 053/116] KVM: TDX: Retry seamcall when TDX_OPERAND_BUSY with operand SEPT Date: Mon, 16 Oct 2023 09:14:05 -0700 Message-Id: X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 16 Oct 2023 09:17:45 -0700 (PDT) From: Yuan Yao TDX module internally uses locks to protect internal resources. It tries to acquire the locks. If it fails to obtain the lock, it returns TDX_OPERAND_BUSY error without spin because its execution time limitation. TDX SEAMCALL API reference describes what resources are used. It's known which TDX SEAMCALL can cause contention with which resources. VMM can avoid contention inside the TDX module by avoiding contentious TDX SEAMCALL with, for example, spinlock. Because OS knows better its process scheduling and its scalability, a lock at OS/VMM layer would work better than simply retrying TDX SEAMCALLs. TDH.MEM.* API except for TDH.MEM.TRACK operates on a secure EPT tree and the TDX module internally tries to acquire the lock of the secure EPT tree. They return TDX_OPERAND_BUSY | TDX_OPERAND_ID_SEPT in case of failure to get the lock. TDX KVM allows sept callbacks to return error so that TDP MMU layer can retry. TDH.VP.ENTER is an exception with zero-step attack mitigation. Normally TDH.VP.ENTER uses only TD vcpu resources and it doesn't cause contention. When a zero-step attack is suspected, it obtains a secure EPT tree lock and tracks the GPAs causing a secure EPT fault. Thus TDG.VP.ENTER may result in TDX_OPERAND_BUSY | TDX_OPERAND_ID_SEPT. Also TDH.MEM.* SEAMCALLs may result in TDX_OPERAN_BUSY | TDX_OPERAND_ID_SEPT. Retry TDX TDH.MEM.* API and TDH.VP.ENTER on the error because the error is a rare event caused by zero-step attack mitigation and spinlock can not be used for TDH.VP.ENTER due to indefinite time execution. Signed-off-by: Yuan Yao Signed-off-by: Isaku Yamahata --- arch/x86/kvm/vmx/tdx_ops.h | 48 +++++++++++++++++++++++++++++++------- 1 file changed, 39 insertions(+), 9 deletions(-) diff --git a/arch/x86/kvm/vmx/tdx_ops.h b/arch/x86/kvm/vmx/tdx_ops.h index c9f74b2400a7..fd73a1731bf8 100644 --- a/arch/x86/kvm/vmx/tdx_ops.h +++ b/arch/x86/kvm/vmx/tdx_ops.h @@ -62,6 +62,36 @@ static inline u64 tdx_seamcall(u64 op, u64 rcx, u64 rdx, u64 r8, u64 r9, void pr_tdx_error(u64 op, u64 error_code, const struct tdx_module_args *out); #endif +/* + * TDX module acquires its internal lock for resources. It doesn't spin to get + * locks because of its restrictions of allowed execution time. Instead, it + * returns TDX_OPERAND_BUSY with an operand id. + * + * Multiple VCPUs can operate on SEPT. Also with zero-step attack mitigation, + * TDH.VP.ENTER may rarely acquire SEPT lock and release it when zero-step + * attack is suspected. It results in TDX_OPERAND_BUSY | TDX_OPERAND_ID_SEPT + * with TDH.MEM.* operation. Note: TDH.MEM.TRACK is an exception. + * + * Because TDP MMU uses read lock for scalability, spin lock around SEAMCALL + * spoils TDP MMU effort. Retry several times with the assumption that SEPT + * lock contention is rare. But don't loop forever to avoid lockup. Let TDP + * MMU retry. + */ +#define TDX_ERROR_SEPT_BUSY (TDX_OPERAND_BUSY | TDX_OPERAND_ID_SEPT) + +static inline u64 tdx_seamcall_sept(u64 op, u64 rcx, u64 rdx, u64 r8, u64 r9, + struct tdx_module_args *out) +{ +#define SEAMCALL_RETRY_MAX 16 + int retry = SEAMCALL_RETRY_MAX; + u64 ret; + + do { + ret = tdx_seamcall(op, rcx, rdx, r8, r9, out); + } while (ret == TDX_ERROR_SEPT_BUSY && retry-- > 0); + return ret; +} + static inline u64 tdh_mng_addcx(hpa_t tdr, hpa_t addr) { clflush_cache_range(__va(addr), PAGE_SIZE); @@ -72,26 +102,26 @@ static inline u64 tdh_mem_page_add(hpa_t tdr, gpa_t gpa, hpa_t hpa, hpa_t source struct tdx_module_args *out) { clflush_cache_range(__va(hpa), PAGE_SIZE); - return tdx_seamcall(TDH_MEM_PAGE_ADD, gpa, tdr, hpa, source, out); + return tdx_seamcall_sept(TDH_MEM_PAGE_ADD, gpa, tdr, hpa, source, out); } static inline u64 tdh_mem_sept_add(hpa_t tdr, gpa_t gpa, int level, hpa_t page, struct tdx_module_args *out) { clflush_cache_range(__va(page), PAGE_SIZE); - return tdx_seamcall(TDH_MEM_SEPT_ADD, gpa | level, tdr, page, 0, out); + return tdx_seamcall_sept(TDH_MEM_SEPT_ADD, gpa | level, tdr, page, 0, out); } static inline u64 tdh_mem_sept_rd(hpa_t tdr, gpa_t gpa, int level, struct tdx_module_args *out) { - return tdx_seamcall(TDH_MEM_SEPT_RD, gpa | level, tdr, 0, 0, out); + return tdx_seamcall_sept(TDH_MEM_SEPT_RD, gpa | level, tdr, 0, 0, out); } static inline u64 tdh_mem_sept_remove(hpa_t tdr, gpa_t gpa, int level, struct tdx_module_args *out) { - return tdx_seamcall(TDH_MEM_SEPT_REMOVE, gpa | level, tdr, 0, 0, out); + return tdx_seamcall_sept(TDH_MEM_SEPT_REMOVE, gpa | level, tdr, 0, 0, out); } static inline u64 tdh_vp_addcx(hpa_t tdvpr, hpa_t addr) @@ -104,20 +134,20 @@ static inline u64 tdh_mem_page_relocate(hpa_t tdr, gpa_t gpa, hpa_t hpa, struct tdx_module_args *out) { clflush_cache_range(__va(hpa), PAGE_SIZE); - return tdx_seamcall(TDH_MEM_PAGE_RELOCATE, gpa, tdr, hpa, 0, out); + return tdx_seamcall_sept(TDH_MEM_PAGE_RELOCATE, gpa, tdr, hpa, 0, out); } static inline u64 tdh_mem_page_aug(hpa_t tdr, gpa_t gpa, hpa_t hpa, struct tdx_module_args *out) { clflush_cache_range(__va(hpa), PAGE_SIZE); - return tdx_seamcall(TDH_MEM_PAGE_AUG, gpa, tdr, hpa, 0, out); + return tdx_seamcall_sept(TDH_MEM_PAGE_AUG, gpa, tdr, hpa, 0, out); } static inline u64 tdh_mem_range_block(hpa_t tdr, gpa_t gpa, int level, struct tdx_module_args *out) { - return tdx_seamcall(TDH_MEM_RANGE_BLOCK, gpa | level, tdr, 0, 0, out); + return tdx_seamcall_sept(TDH_MEM_RANGE_BLOCK, gpa | level, tdr, 0, 0, out); } static inline u64 tdh_mng_key_config(hpa_t tdr) @@ -199,7 +229,7 @@ static inline u64 tdh_phymem_page_reclaim(hpa_t page, static inline u64 tdh_mem_page_remove(hpa_t tdr, gpa_t gpa, int level, struct tdx_module_args *out) { - return tdx_seamcall(TDH_MEM_PAGE_REMOVE, gpa | level, tdr, 0, 0, out); + return tdx_seamcall_sept(TDH_MEM_PAGE_REMOVE, gpa | level, tdr, 0, 0, out); } static inline u64 tdh_sys_lp_shutdown(void) @@ -215,7 +245,7 @@ static inline u64 tdh_mem_track(hpa_t tdr) static inline u64 tdh_mem_range_unblock(hpa_t tdr, gpa_t gpa, int level, struct tdx_module_args *out) { - return tdx_seamcall(TDH_MEM_RANGE_UNBLOCK, gpa | level, tdr, 0, 0, out); + return tdx_seamcall_sept(TDH_MEM_RANGE_UNBLOCK, gpa | level, tdr, 0, 0, out); } static inline u64 tdh_phymem_cache_wb(bool resume) -- 2.25.1