Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp5775466ioo; Wed, 1 Jun 2022 12:19:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx0kpGWMR7h+SO6Cj31AOdLjhBiOUnmXso8RfX9JZeTzIgrXWZZ87sPQdK6sWGCB4CsxTUx X-Received: by 2002:a17:90a:ba15:b0:1e2:e76c:f725 with SMTP id s21-20020a17090aba1500b001e2e76cf725mr917837pjr.7.1654111148426; Wed, 01 Jun 2022 12:19:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654111148; cv=none; d=google.com; s=arc-20160816; b=w7YMbihPECEoZUSmNY4ZJ4effhpZyRppc3fnCvolT59GAjYa4hC+tFOwu7zy21s3Yj DR04tMM74vr+koiRUcEUzx+GfIQFisC3eJTtTw7VuhhoKwF2ZU/Cfsq+88UdDamJEbGp DJs0ZGhP5v+FuVHtFG9TGUwepysEMdiq6bxc+ywnX6u2Gezi+k55/WDvA9o5dmB5HDlJ Ofa91Tl/lan3XkYRaZQQcX0/mP47Njl5Fd6MoWtVDI9CENHCMkEPjhwyUI6S8MRzVb2K 86F/PleVgmjDOxcb8y6pJ+YrfRBi46taKqFMw3gxMysudz0512EYbgiXmZo+jvN7AtZT 9d2g== 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=Nn9tL2Ye2GaaGO/Ck19asJDssaQbIDtvSY0WBZV97Uo=; b=iChbtrAYzn0MJ+TVESZ6VwXoqoXbWpuaqKzfYWXdkpnWwNOytagcWnc/BszN0d1eha SZk/5xnepysjFcQiqL1kyMWveBl1xsFUD3YnyK9Laa8eMsRNIPJsZpMK/M+iask9+UCT OxSv6YvChLqmRaapEk7MXyurXvQ/KU8ojjHDYHYf1fVIfRGXo1sNwxp4xuk+czgOTE6N /VTxBVmgLK8hj2SlTwEunSEY8EBfBn2BLS0aUAeIgZd83wo88zxUJxZIs5wwXEIFuO9M +5ILthiZYqflf7gEJTx57pxz2967yqdE0qe7xew2j5rC7T8L+4+lHrmpNYwTDXuP4sQa tKgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=lNKvnAJm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id d6-20020a636806000000b003fbc60e335asi3222218pgc.736.2022.06.01.12.19.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 12:19:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=lNKvnAJm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E7E8C1567F1; Wed, 1 Jun 2022 11:55:24 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241819AbiE3Ouh (ORCPT + 99 others); Mon, 30 May 2022 10:50:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42586 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241887AbiE3Oaj (ORCPT ); Mon, 30 May 2022 10:30:39 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 922307CDE5; Mon, 30 May 2022 06:52:29 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9247760FD4; Mon, 30 May 2022 13:52:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB70CC3411A; Mon, 30 May 2022 13:52:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1653918747; bh=L4wMv7eVCEcb+Dh8ypbivhOGsg3GXEYdwwoPqDs6iew=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lNKvnAJmrVcP3FDQXXUeRg6rkRHMqE2SK1uNc5TLZbAq1Aq6MFwSTVoBwSRCCwmXO AYTIalWDYfo/0tcyqQjbLqGaIMeiNzHNpA3tcbCaZEMzjxr91Gqhy2X5XF/6bsG/t5 Usgaf+lddDfnathhAzimCt0GYeKKNJvZFHWntDldr1z84z1yrHU/YJUuPX3znYuE3y 3/iHgVBwuumSiNk0FpvyMZ6hX618uU33zmzkHsDGCbWHuiIKJTvoebBacv+Zkb1fvA wDp0alwOyANEB7xSG5AwOiYh4WF2+fRUN9VihDrkKjUd83sBktHyKTzCxA+ll2tbKu BHUUzIFLzjeqg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Kirill A. Shutemov" , Dave Hansen , Dan Williams , Thomas Gleixner , Sasha Levin , mingo@redhat.com, bp@alien8.de, x86@kernel.org Subject: [PATCH AUTOSEL 4.9 06/24] ACPICA: Avoid cache flush inside virtual machines Date: Mon, 30 May 2022 09:51:53 -0400 Message-Id: <20220530135211.1937674-6-sashal@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220530135211.1937674-1-sashal@kernel.org> References: <20220530135211.1937674-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 From: "Kirill A. Shutemov" [ Upstream commit e2efb6359e620521d1e13f69b2257de8ceaa9475 ] 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 Signed-off-by: Dave Hansen Reviewed-by: Dave Hansen Reviewed-by: Dan Williams Reviewed-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20220405232939.73860-30-kirill.shutemov@linux.intel.com Signed-off-by: Sasha Levin --- 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 1b010a859b8b..6de59a4f723c 100644 --- a/arch/x86/include/asm/acenv.h +++ b/arch/x86/include/asm/acenv.h @@ -16,7 +16,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