Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2509628pxp; Fri, 18 Mar 2022 12:02:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwtQ+h4ai3oQAXe2L9D90ou7nQzqdHIlP2BFbajEatyz4XddWGMrKoiAlfItuqbdCo1wXA3 X-Received: by 2002:a05:6a00:815:b0:4f6:ee04:30af with SMTP id m21-20020a056a00081500b004f6ee0430afmr11380974pfk.15.1647630134005; Fri, 18 Mar 2022 12:02:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647630134; cv=none; d=google.com; s=arc-20160816; b=ZLF3ScXY5U6aiw6bDPXeYGWOfSrFsPbdxpzrJRCGu/fqgYj26Q5kiBpiYvBRR8xGIW Bf62imKkDxqw8aK6iqT9puhCZfZ4VGnxcn3Uf+n1Co8EKftAj6ip18t6cGKs6uQjGHBM jIhn6lAlJsxpu/6MJr/fOEjvCkX46HAiPqec51+70VouP7/9kQn6nOA0K5d3gRYMGYi/ cjHDw9mCjNgLVeaWtCZ11xqTKfGqTMH9yNKm8Sd4T4FA64dSBkc83WAjL4uvK9RBEYaM X+6W9+Zkacrl1jr02TZYCSJJtSrA7kbLIyKfxqxcRjDdYjakRaFyWZQH6sLriwsnCmqn c8vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=QIFESMVGJ4X/Vm3hQlgI3gWo7LLfoT7PD511cTTEqpI=; b=knzoSsrSCYxK6JDL8wqHo0VO47rQg7uPwzfkfXBrYIVhxEd8Zu5HZlx0y+BCO2E4iy q2P0bO+mJDV5wlv/qo5TExEsVsKGEDWkc0U3Hw3VQwekQEHibLkPGr6oCWHVi5B4n0UN s1657UWrtLLFNOdjGASc+/+NAncdbCmHXaacRtMQhD2A1ckUcSCPevgvlYovNquMEoS/ odNBYCcShNTUsI9dhtZ2CPBQ/qb1gF/mk7XdPM5b08qjIECB99j7AMQ5XRDd31iyrmnY Tz57VghHSy7OsjH5zo40cnLh1ueGIo2njLyUlpIMl13+cWyVYolbLM4bK0fq56SYSOqE FGvw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=VMdMJaud; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n198-20020a628fcf000000b004fa3a8dffdesi60281pfd.149.2022.03.18.12.01.45; Fri, 18 Mar 2022 12:02:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=VMdMJaud; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230126AbiCQXFd (ORCPT + 99 others); Thu, 17 Mar 2022 19:05:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38826 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229730AbiCQXFc (ORCPT ); Thu, 17 Mar 2022 19:05:32 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 70D8F2C2752 for ; Thu, 17 Mar 2022 16:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647558255; x=1679094255; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=jcx2pvuYRJlbZfM/GWFl8nSn4/vkEAjnqC1ZiKdWoyY=; b=VMdMJaudbp00A9afpmeLn7oLhwvLnxKKig+FF23ut+/lqqZzkZopEoFu rdv/plc6DMQC5iow8JQE3BPFYbw7Nk747cRCQI7GTwbC1y1rjKxrXrk7W i6/lYJ/AaxI38YfV1SJhHQopSxSjcRr0I012BjcKHwW0KUT+qfIEjKXV7 7b2BH8cEcUfXvAuzCiKNX8IN/tOA79XMG0zEhJHkBiWhAxdszoloqqX0k EIhkTvHfuwodjvbbmJPyRb6X7K9rVLUQq8kOjeWrD7+JC+mezsJ1nwePN 7P+1TJNpzUpRhGnFZsFffCt1NtsKyip+vGoxgI1cBrOn9y5GjV2AW01jp w==; X-IronPort-AV: E=McAfee;i="6200,9189,10289"; a="254558110" X-IronPort-AV: E=Sophos;i="5.90,190,1643702400"; d="scan'208";a="254558110" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Mar 2022 16:04:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,190,1643702400"; d="scan'208";a="558146973" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga008.jf.intel.com with ESMTP; 17 Mar 2022 16:04:08 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 62605107; Fri, 18 Mar 2022 01:04:28 +0200 (EET) Date: Fri, 18 Mar 2022 02:04:28 +0300 From: "Kirill A. Shutemov" To: Dave Hansen Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, luto@kernel.org, peterz@infradead.org, 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 Subject: Re: [PATCHv6 29/30] ACPICA: Avoid cache flush inside virtual machines Message-ID: <20220317230428.uqfbm6y7v2qbgknn@black.fi.intel.com> References: <20220316020856.24435-1-kirill.shutemov@linux.intel.com> <20220316020856.24435-30-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-8.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE 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 On Wed, Mar 16, 2022 at 03:13:18PM -0700, Dave Hansen wrote: > On 3/15/22 19:08, Kirill A. Shutemov wrote: > > 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. > > Looks good. Did you have more acks on this earlier that got removed? I > thought I remembered more acks on earlier versions. I missed Dan's Reviewed-by, but it was the only one that got to my inbox. We had few (actually few too many) different approaches to address WBINVD and some of them got acks. Dan was the only one who acked this version, before current submission. -- Kirill A. Shutemov