Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp948426pxb; Wed, 6 Apr 2022 05:05:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5NG43bH7hHuPCAQL7a4lAoEGCCIj15rSD8SQD8xtlYo0wO8OPr3oh83rTZ/zX3gFzbJsn X-Received: by 2002:a17:90a:a509:b0:1ca:c48e:a795 with SMTP id a9-20020a17090aa50900b001cac48ea795mr9436091pjq.165.1649246757525; Wed, 06 Apr 2022 05:05:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649246757; cv=none; d=google.com; s=arc-20160816; b=Wi54yMXpMaZaUFunoy5JSzMy7fx+IyC4/VvJiMJsnbwQ0KrsDQ0nQTe9ihKq2Sm7tY kaFvsJbUuNu0t4mhncuJwxDVbymTnAQ9iHI4/ghh3ph/iF8l47R7FtSIHCrUGjy0WJWB Z8CBgmpTUezY829/EXJ6XR1Tc5A4SA88zBLXb+GvJOUxeUkceNeWVrOZ7Sy6EDozAL+f xXd5gQmeMWTFfVUH6awEgqvsA87/z/7thHpgJgil08GmTVAua2H9qQB8ihtKlSSOxnYW bOcP2uF5Om9iQAmuIPUN2m5DdX3b4Lky/A3PTcfxARDnz+kduJ0AYgvVsR7ER5a6VrYi 699Q== 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=X0mPwKaMHQX/rvGD9fjfs+DCD3ISIVb0zXbL3qH32Q8=; b=x/7iHnG65+EHDpvLeD0/ANY72HlaQX1pUZuq/fgRH0bUWw/dS6DfhRVcKIGKpt7GZw VYPzLkuEmUo+y89Me8YIEJG6rfI8tg55cr0nG4HO2BfqO07voasN0O1szpLrsNZNSZOY zM3hiJuwkvEjtuvYVY00vIvDsvro5LWHxmzJtLddF4kJhhDbfwMk/N+YHjQWpswj0ECC d5rHoBIeOJbQK79nI+iOpFHt9kgbk8ZYmP94oV8e15dMck779iwLQ+E8QiE9DgazVHbI ATljD3LDQ25PVk7Q+fD8pgfrCK5Czvtwzh8WxKfm9hXJAM2GIbrNeVmbEHSFpC0OEcrI H7Sg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=cjkKTCCv; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id f6-20020a170902ce8600b00153b2d1653fsi17219310plg.327.2022.04.06.05.05.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 05:05:57 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=cjkKTCCv; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 48C5E682DE7; Wed, 6 Apr 2022 03:33:44 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1451102AbiDFDUM (ORCPT + 99 others); Tue, 5 Apr 2022 23:20:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48198 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1449290AbiDFCO7 (ORCPT ); Tue, 5 Apr 2022 22:14:59 -0400 Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29F741B30AE for ; Tue, 5 Apr 2022 16: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=1649201722; x=1680737722; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=unkPtz2FMjtzoyFiMcJoPzyEFlbEMwcX2og1L5Gz+lw=; b=cjkKTCCvBLtOgdu9KOeTIMyJ6J8jFK+ZyTBqNlRtwCoYjSmLetipxNqu LEOqcMnE814V9iT4MYHv9hblM8k3QtHDTXMcOBfo9rHJoT36aHbYQZ97+ CWUudNeOI95MjBeeXUYY2I66t2WpzkSzKK2hSH1VmyGZnSWuuMz1yZ5C6 rcWBjKyGh//we2lW2MApeYSSmAQe4rmXDWxGVhg2AJScxm4FP8Rew3rNe VLJNfTBts4OQ63tvuL0TeEqkWqllJsSx0QmztM8clwBd1chM9N7jlGYLf AGOwqOiq1Q/M/mlEgYzLCSq0WFoaC8orrVpzRwgrzfQWwP8Q+dQ1hbExQ A==; X-IronPort-AV: E=McAfee;i="6200,9189,10308"; a="321586088" X-IronPort-AV: E=Sophos;i="5.90,238,1643702400"; d="scan'208";a="321586088" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Apr 2022 16:34:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,238,1643702400"; d="scan'208";a="652106972" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga002.fm.intel.com with ESMTP; 05 Apr 2022 16:34:49 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 023FC1100; Wed, 6 Apr 2022 02:29:46 +0300 (EEST) 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" , Dave Hansen Subject: [PATCHv8 29/30] ACPICA: Avoid cache flush inside virtual machines Date: Wed, 6 Apr 2022 02:29:38 +0300 Message-Id: <20220405232939.73860-30-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405232939.73860-1-kirill.shutemov@linux.intel.com> References: <20220405232939.73860-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 While running inside virtual machine, 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. Before entering sleep states, the ACPI code flushes caches to prevent data loss using the WBINVD instruction. This mechanism is required on bare metal. But, any use WBINVD inside of a guest is worthless. Changing sleep state in a virtual machine doesn't affect the host system sleep state and cannot lead to data loss, so most hypervisors simply ignore it. Despite this, the ACPI code calls WBINVD unconditionally anyway. It's useless, but also normally harmless. In TDX guests, though, WBINVD stops being harmless; it triggers a virtualization exception (#VE). If the ACPI cache-flushing WBINVD were left in place, TDX guests would need handling to recover from the exception. Avoid using WBINVD whenever running under a hypervisor. This both removes the useless WBINVDs and saves TDX from implementing WBINVD handling. Signed-off-by: Kirill A. Shutemov Reviewed-by: Dave Hansen Reviewed-by: Dan Williams Reviewed-by: Thomas Gleixner --- arch/x86/include/asm/acenv.h | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/acenv.h b/arch/x86/include/asm/acenv.h index 9aff97f0de7f..d937c55e717e 100644 --- a/arch/x86/include/asm/acenv.h +++ b/arch/x86/include/asm/acenv.h @@ -13,7 +13,19 @@ /* 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 virtual machine, 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. + */ +#define ACPI_FLUSH_CPU_CACHE() \ +do { \ + if (!cpu_feature_enabled(X86_FEATURE_HYPERVISOR)) \ + wbinvd(); \ +} while (0) int __acpi_acquire_global_lock(unsigned int *lock); int __acpi_release_global_lock(unsigned int *lock); -- 2.35.1