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 83E31C433F5 for ; Thu, 24 Feb 2022 15:57:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230274AbiBXP6X (ORCPT ); Thu, 24 Feb 2022 10:58:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236723AbiBXP5Q (ORCPT ); Thu, 24 Feb 2022 10:57:16 -0500 Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1983422BC8 for ; Thu, 24 Feb 2022 07:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645718201; x=1677254201; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=aMt9dMQFnuWJAh9cVzkqMUEeYOnZHiNvm0HEf2p9qHU=; b=lXuCa+iwUVti7N3VDEAB9CS6A1zl4MUIdYHZdwssyjhGO/Xox1UGHF6D 0sgbUD6VHmm8WIa+zIfzo2426FN5fIAgMB9s3JhWBifYallPs+XRyvICs ewAogf3nJTsXYQ1pDDRUdDg5MaNfgD1fAXi2uMiajoc2YUcxvk7ucazKM xzh3DWv83QDRK2DngM2F5A6x4l1BlxIuKS9uYwc3M1PAu+OgmRgjxneHi EOJ2ToiPq1jUnpKo6GDfEiYMkfVL7+43UuMlbQUtDLWE89On95DgGZ4Wb uMlQFkJGkREG+nThCYoxB2XkssUUQp5XeN2Ptxhv6sZRpb/aCvXNGcMLn w==; X-IronPort-AV: E=McAfee;i="6200,9189,10268"; a="312983041" X-IronPort-AV: E=Sophos;i="5.90,134,1643702400"; d="scan'208";a="312983041" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Feb 2022 07:56:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,134,1643702400"; d="scan'208";a="506362116" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga002.jf.intel.com with ESMTP; 24 Feb 2022 07:56:32 -0800 Received: by black.fi.intel.com (Postfix, from userid 1000) id B1E38C7E; Thu, 24 Feb 2022 17:56:35 +0200 (EET) From: "Kirill A. Shutemov" To: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@intel.com, luto@kernel.org, peterz@infradead.org Cc: sathyanarayanan.kuppuswamy@linux.intel.com, aarcange@redhat.com, ak@linux.intel.com, dan.j.williams@intel.com, david@redhat.com, hpa@zytor.com, jgross@suse.com, jmattson@google.com, joro@8bytes.org, jpoimboe@redhat.com, knsathya@kernel.org, pbonzini@redhat.com, sdeep@vmware.com, seanjc@google.com, tony.luck@intel.com, vkuznets@redhat.com, wanpengli@tencent.com, thomas.lendacky@amd.com, brijesh.singh@amd.com, x86@kernel.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" Subject: [PATCHv4 29/30] ACPICA: Avoid cache flush on TDX guest Date: Thu, 24 Feb 2022 18:56:29 +0300 Message-Id: <20220224155630.52734-30-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220224155630.52734-1-kirill.shutemov@linux.intel.com> References: <20220224155630.52734-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ACPI_FLUSH_CPU_CACHE() flushes caches on entering sleep states. It is required to prevent data loss. While running inside TDX guest, the kernel can bypass cache flushing. Changing sleep state in a virtual machine doesn't affect the host system sleep state and cannot lead to data loss. The approach can be generalized to all guest kernels, but, to be cautious, let's limit it to TDX for now. Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/acenv.h | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/acenv.h b/arch/x86/include/asm/acenv.h index 9aff97f0de7f..d19deca6dd27 100644 --- a/arch/x86/include/asm/acenv.h +++ b/arch/x86/include/asm/acenv.h @@ -13,7 +13,21 @@ /* Asm macros */ -#define ACPI_FLUSH_CPU_CACHE() wbinvd() +/* + * ACPI_FLUSH_CPU_CACHE() flushes caches on entering sleep states. + * It is required to prevent data loss. + * + * While running inside TDX guest, the kernel can bypass cache flushing. + * Changing sleep state in a virtual machine doesn't affect the host system + * sleep state and cannot lead to data loss. + * + * TODO: Is it safe to generalize this from TDX guests to all guest kernels? + */ +#define ACPI_FLUSH_CPU_CACHE() \ +do { \ + if (!cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) \ + wbinvd(); \ +} while (0) int __acpi_acquire_global_lock(unsigned int *lock); int __acpi_release_global_lock(unsigned int *lock); -- 2.34.1