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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 5D148C4743C for ; Sat, 5 Jun 2021 03:35:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 33A9561185 for ; Sat, 5 Jun 2021 03:35:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230288AbhFEDhb (ORCPT ); Fri, 4 Jun 2021 23:37:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50424 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229726AbhFEDha (ORCPT ); Fri, 4 Jun 2021 23:37:30 -0400 Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23CD2C061766 for ; Fri, 4 Jun 2021 20:35:43 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id c12so8849164pfl.3 for ; Fri, 04 Jun 2021 20:35:43 -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=tZseS8aSnULurPdZf/si9iNA+qWf4+HN6oG8w6/+geQ=; b=uCcYmDmD0mdD2R/F6Gx+4Lbo0Twudda2tFrZ7DfTrInQq5Ll/iB15gFtdu/unlvR3X 35GsCTp+XPoAqExK9lGFbn2ufkny/LzF5L93Jy7ykmZUrJ3iVqdIjf5kUBLPhoLat7Vd cSjF86b/MNToAntmJB5RbAY/bhs3TqfA4plcoHzc0u6MCEfViwP7+KdfdTTxrAKTamky Tyw6Eau1CpxfJ2BU4oKQhUCHZ2p2uwjQRi/Y/iUBGzDWfMivR1BMMHkLnxskRe9XUcQv tDTINfeuJRDjTAs66Y877GWpFqyRwxMVpHtXCbvIyezP0GVaEAKeHQG2qZLtsf0MuzaF cKoA== 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=tZseS8aSnULurPdZf/si9iNA+qWf4+HN6oG8w6/+geQ=; b=g+JgwqoUeYf7xIgzqqkDm6YUWGoxP9HOm96oxxxq6xOBIYKb0q7GMWtdw2O4JY70mb M2a5VioNr023T1Z7SVUpLQSfMkFlwR9+nsMcElVmTn5a8kwCFUAAc+Nnfifg0b8h4cTz Q/xGE1eDeLo1mZayexMXoqLOu1uoGcZ+yxm/DQeP8wfrDeJFPyk7jKkRbqiPGCBovbq4 Vowci6pwcqBMJzHGBrmSM1luekBJ/x3Fj64tAgUQ+KmK95VE5/KPY7UgjQTluaQcQlO6 AD92dKe7Z4WYh4pRGUYyVH7qnndsH4cdKAXcmkfvwpoUMfANbWmu8R4c/2B2nAjmh7DC STzA== X-Gm-Message-State: AOAM533tB6q1y7YBr2rzgNbkl1TT8/V3CaG0uVmwz7ZBmDO+TQBL98l3 ix5/KCQbi5lRnAsPiqvTvrnG/MqbIEHpwTI6hEdc9Q== X-Google-Smtp-Source: ABdhPJzC4T3loAglaejl0UiqBemGIs4bGYkYnOW46p5Q/X/h47kR6SkpiVLR0cu/SmxvMk7BPsg5VUwrGtTSagPi+Gg= X-Received: by 2002:a05:6a00:234f:b029:2c4:b8d6:843 with SMTP id j15-20020a056a00234fb02902c4b8d60843mr7547776pfj.71.1622864142613; Fri, 04 Jun 2021 20:35:42 -0700 (PDT) MIME-Version: 1.0 References: <20210527043832.3984374-1-sathyanarayanan.kuppuswamy@linux.intel.com> In-Reply-To: <20210527043832.3984374-1-sathyanarayanan.kuppuswamy@linux.intel.com> From: Dan Williams Date: Fri, 4 Jun 2021 20:35:31 -0700 Message-ID: Subject: Re: [RFC v2-fix-v3 1/1] x86/tdx: Ignore WBINVD instruction for TDX 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 26, 2021 at 9:38 PM Kuppuswamy Sathyanarayanan wrote: > > Functionally only devices outside the CPU (such as DMA devices, > or persistent memory for flushing) can notice the external side > effects from WBINVD's cache flushing for write back mappings. One > exception here is MKTME, but that is not visible outside the TDX > module and not possible inside a TDX guest. > > Currently TDX does not support DMA, because DMA typically needs > uncached access for MMIO, and the current TDX module always sets > the IgnorePAT bit, which prevents that. > > Persistent memory is also currently not supported. There are some > other cases that use WBINVD, such as the legacy ACPI sleeps, but > these are all not supported in virtualization and there are better > mechanisms inside a guest anyways. The guests usually are not > aware of power management. Another code path that uses WBINVD is > the MTRR driver, but EPT/virtualization always disables MTRRs so > those are not needed. This all implies WBINVD is not needed with > current TDX. > > So handle the WBINVD instruction as nop. Currently, #VE exception > handler does not include any warning for WBINVD handling because > ACPI reboot code uses it. This is the same behavior as KVM. It > only allows WBINVD in a guest when the guest supports VT-d (=DMA), > but just handles it as a nop if it doesn't . > > If TDX ever gets DMA support, or persistent memory support, or > some other devices that can observe flushing side effects, a > hypercall can be added to implement it similar to AMD-SEV. But > current TDX does not need it. Please just drop this patch. It serves no purpose especially when the assertion is that nothing in TDX will miss WBINVD. Why would Linux merge a patch that has no claimed end user benefit? If the only known usage of WBINVD in a TDX guest is the ACPI reboot path then add an is_protected_guest() to that one usage. If a TDX guest runs an unexpected WBINVD that's a bug that needs a kernel fix.