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 X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 765ACC48BCF for ; Wed, 9 Jun 2021 19:57:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5FBE6613BC for ; Wed, 9 Jun 2021 19:57:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229782AbhFIT7b (ORCPT ); Wed, 9 Jun 2021 15:59:31 -0400 Received: from mail-pf1-f173.google.com ([209.85.210.173]:43847 "EHLO mail-pf1-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229740AbhFIT7b (ORCPT ); Wed, 9 Jun 2021 15:59:31 -0400 Received: by mail-pf1-f173.google.com with SMTP id m7so6426441pfa.10 for ; Wed, 09 Jun 2021 12:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ed3c0CY6+ZiTf8IgpI3kXf3HcsCngM7z14+9/Ftg5SE=; b=iAnBkfqu6IpZOHIQ9qwPj68RXJTgOIX/Pny9DDjzHNjHvSjw7+a5U/YiDcyskXJ5cV MYvniHJ4OxJQ6VBZOLHnhlKb9pRLoaP6jO1VT+Uwn0xhuYYh3WaN1gtVKAh37kzqxXml JLIRC/M4xWWeLXLfxEfnwV/7v+JkZXaro+2c5EI2smEroaRC2JEhYzzMAE//A5hKI8l6 /NGIGe83+SXoEiWUVmRLZlwpqgT14Q9aUw1ho737/uZA2BWQ971gd0p1wM2CuBVtJFSQ ldaQt8UMlBRfHm73apH+Y30XBsf54t9J1HVRCNoIkUCSpr7XqyezcGzzlEmZhzZ+b4Rh YQuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ed3c0CY6+ZiTf8IgpI3kXf3HcsCngM7z14+9/Ftg5SE=; b=l3JhRLa4UjP260tOMtM5QbA5OWG9x2Iz98wPVyzLNX3qroaea3m4ORnqHqA3Zj6Ec6 3V+BwzcbGIh/+aDVrgV2o4EgMldIYQKQ0gEcm7S14FJNobRF+vtVVGkfdVgdF0enWQ2K MMzhXrjWBU/DBSkfZlKCeUCnxtK13FU1E4sY4ssEutdz346Ug0uuedz/X2N/lRpzNK9R hsG1YmjCuaUwNucw1YH5lTErIt63R/c/euxTZCmk60y45o102Ofzjo/7qPmgUKzscJYB cOmRPcuFYFl/rkEsT0pX01UqMKwI/oj+b8Y91sa77HOfxqy3TZs3d20X+5LejmAHdPhS H7Xg== X-Gm-Message-State: AOAM531VC4tScCVb+r7LFOj3q3fydt0yHPFI2Leca22IxminQTolX+tP DDBbh+up7Lhuc058WCXiGDj5HAJo6UrUtDEqJHjRBA== X-Google-Smtp-Source: ABdhPJxDJ/e/nzDP4k49vLkESWIf4iyvke2cp/k6UU8JGvGgWmYdgvNJPiY51jIJT4i+Rr9VpLd2zSJ87fKD4mXGN8E= X-Received: by 2002:aa7:952b:0:b029:2e9:eef1:8e17 with SMTP id c11-20020aa7952b0000b02902e9eef18e17mr1408582pfp.70.1623268596069; Wed, 09 Jun 2021 12:56:36 -0700 (PDT) MIME-Version: 1.0 References: <973add45-9fd2-7abc-3a97-96a26c263ea0@linux.intel.com> <20210609194926.1949859-1-sathyanarayanan.kuppuswamy@linux.intel.com> In-Reply-To: <20210609194926.1949859-1-sathyanarayanan.kuppuswamy@linux.intel.com> From: Dan Williams Date: Wed, 9 Jun 2021 12:56:25 -0700 Message-ID: Subject: Re: [RFC v2-fix-v5 1/1] x86: Skip WBINVD instruction for VM guest To: Kuppuswamy Sathyanarayanan Cc: Peter Zijlstra , Andy Lutomirski , Dave Hansen , Tony Luck , Andi Kleen , Kirill Shutemov , Kuppuswamy Sathyanarayanan , Raj Ashok , Sean Christopherson , Linux Kernel Mailing List , Linux ACPI , "Rafael J. Wysocki" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ add back linux-acpi and Rafael ] On Wed, Jun 9, 2021 at 12:49 PM Kuppuswamy Sathyanarayanan wrote: > > VM guests that supports ACPI, use standard ACPI mechanisms to > signal sleep state entry (including reboot) to the host. The > ACPI specification mandates WBINVD on any sleep state entry > with the expectation that the platform is only responsible for > maintaining the state of memory over sleep states, not > preserving dirty data in any CPU caches. ACPI cache flushing > requirements pre-date the advent of virtualization. Given guest > sleep state entry does not affect any host power rails it is not > required to flush caches. The host is responsible for maintaining > cache state over its own bare metal sleep state transitions that > power-off the cache. A TDX guest, unlike a typical guest, will > machine check if the CPU cache is powered off. Looks like you are wrapping at column 62 than 72, double check that for the final submission of this series. Other than that this looks good to me. Reviewed-by: Dan Williams