Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3988904pxj; Mon, 24 May 2021 20:43:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwjjOP3KV27WR+j89TVxvw6n7bC911IuL4DLFo3Z6exsGWDagdtMiEGMt3mLCH4srPWbU9J X-Received: by 2002:aa7:dd10:: with SMTP id i16mr29445641edv.274.1621914231915; Mon, 24 May 2021 20:43:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621914231; cv=none; d=google.com; s=arc-20160816; b=1HvBonxd5Ic2dsuzNrbCBdNceuie2+pejZyefSUYoZLxjCNG31x3uhFHqkypEruRTn TY6B1tlp/Dd3JXz8fwvw6qMs3vXVa+KSpqZjcbwbh1la4aV8pqiDvFx+NE/W6FA2O2LL tLsKdRcKCZ8AkT1j/IIrk/8f3QFMMxQm27PCT/kZZIpamrVCBUUUWikZHOjfGoEXCpPN 0m/bUaHFBNuU10wz6n4lo7WaQFzJw6S9GdErJV0CU6o7ved740Y1heIUbCTCLiFP017k Br9EYNFYJA+Le/S9dZydRx6fteVv90aYhbvyR4gzfJrYe9WqYZR0PoI3+9idX67aCycR dyHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=TYxoO7yBBzqdzyOxDkIoKwGSFZKwMeGZb66v0c/avEE=; b=PJoCs+vKerq2gGU+iNaBkd1kBi7/dKEOUlN7OqODVJWvSDbTFl7Kv8Yljr0QSIGWub o8u7x14DugVUFFc06GW1qBXkaeb1maD+wEUbooPzwQO6njuWqqSjfbV+MjBXacYaSLLE HVY89+f4Tuw8gBpThGZYuIMISw5kF/Cne9jiPCN6JFR+HsFmb/KE7vdmfkdxagIbRPgq waN5lozVNvqIb8/JNaua8rPguRfRTeYsx+j9oS8sN9bSyqywswEWL2emDGBHNZgscz9E yAQJJ2QAD+pQrcxqSOsk5IakI0+IOx5ytwCInhqZxwLK/wrfOR7dO5pzF+rsNWSIhX3k 3ohw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=TffITMri; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i21si14489980edc.289.2021.05.24.20.43.29; Mon, 24 May 2021 20:43:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=TffITMri; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230335AbhEYDmS (ORCPT + 99 others); Mon, 24 May 2021 23:42:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230048AbhEYDmS (ORCPT ); Mon, 24 May 2021 23:42:18 -0400 Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5AFB0C061574 for ; Mon, 24 May 2021 20:40:49 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id b7so11505158plg.0 for ; Mon, 24 May 2021 20:40:49 -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=TYxoO7yBBzqdzyOxDkIoKwGSFZKwMeGZb66v0c/avEE=; b=TffITMriBqjrMlYEwaN2fzQJvKIqqDn6b7MCg3RMNPRHXLbWKZfeb0DcSQMvKvyfWi 6rmZgeYfuPBncqp5wshTfLLHxK7QGye3ENIZrEbAUOC1XLlE2hObZzuaXodtuwHWyiE9 urFchfogdnddL40KAwxA8FxatTFJesIJGNHc+7Bt15cGs26MCaM9i5sDI1lsWUqJqG6J ooYlqpn/UETWvlnbFquR8BbGNuquIhf0TGeXR9im+rt/mZVHdoGX4LPeKOPagDd2uP0r yoqSCabdDkdUZIU4vD07NxuAkdD2LZWuFnZKQiyzOv4fHUFl8qGxqvkh736bmR6ydexu OF3w== 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=TYxoO7yBBzqdzyOxDkIoKwGSFZKwMeGZb66v0c/avEE=; b=i28xNQgmnJBf9BS4aaiEIQ/w008Fw6YBIdSuFhgiNfqGdYksfBKp96FDudD4dwj7kT jtOSrxx87OVX43Pt8/u93LGJFfrI4pGMV4oA2aTr44ESYapUrjZgTohwZSXa+Xi9QtY3 P53689BC6bEhY61PYDEQ4UAq4nYaB4ZOeuBM5cFcHOyfoLR7+R3ROahp11BUhKa/Qp7S T7s4L5oNekg6Uye7FI8btZ+EtB0KeI/SvcS4zNHDuF/B+X5I0KpDLIolSvh/fsOu0Adg yLfZswzunCWsNZ14BgRypy78AiyLS1NJ2CcYL9g2/o4icvq3gpSEfXVJlAaRnRiFqpdG oGPw== X-Gm-Message-State: AOAM532V4sW2W0WnOQTyWhX9LensxNSZg5tclprUlo4kgQmosnxygi9Y V53YuWPE9w5t/oBNdTpz5UzeEfG+4GhT/j1TljHwHw== X-Received: by 2002:a17:902:8693:b029:eb:53f:1336 with SMTP id g19-20020a1709028693b02900eb053f1336mr28650609plo.52.1621914048846; Mon, 24 May 2021 20:40:48 -0700 (PDT) MIME-Version: 1.0 References: <37ad50ca-f568-4c62-56e2-9e9b1f34084c@linux.intel.com> <20210524233211.802033-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20210524233211.802033-2-sathyanarayanan.kuppuswamy@linux.intel.com> <125f8362-b1e3-d304-f943-3fc2f07b5d79@linux.intel.com> <6f44fbeb-a8be-d2e4-5161-d46ddf09482e@linux.intel.com> In-Reply-To: <6f44fbeb-a8be-d2e4-5161-d46ddf09482e@linux.intel.com> From: Dan Williams Date: Mon, 24 May 2021 20:40:42 -0700 Message-ID: Subject: Re: [RFC v2-fix-v2 2/2] x86/tdx: Ignore WBINVD instruction for TDX guest To: Andi Kleen Cc: "Kuppuswamy, Sathyanarayanan" , Peter Zijlstra , Andy Lutomirski , Dave Hansen , Tony Luck , 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 Mon, May 24, 2021 at 8:27 PM Andi Kleen wrote: > > > On 5/24/2021 7:49 PM, Dan Williams wrote: > > On Mon, May 24, 2021 at 7:13 PM Andi Kleen wrote: > > [..] > >>> ...to explicitly error out a wbinvd use case before data is altered > >>> and wbinvd is needed. > >> I don't see any point of all of this. We really just want to be the same > >> as KVM. Not get into the business of patching a bazillion sub systems > >> that cannot be used in TDX anyways. > > Please let's not start this patch off with dubious claims of safety > > afforded by IgnorePAT. Instead make the true argument that wbinvd is > > known to be problematic in guests > > That's just another reason to not support WBINVD, but I don't think it's > the main reason. The main reason is that it is simply not needed, unless > you do DMA in some form. > > (and yes I consider direct mapping of persistent memory with a complex > setup procedure a form of DMA -- my guess is that the reason that it > works in KVM is that it somehow activates the DMA code paths in KVM) No, it doesn't. Simply no one has tried to pass through the security interface of bare metal nvdimm to a guest, or enabled the security commands in a virtualized nvdimm. If a guest supports a memory map it supports PMEM I struggle to see DMA anywhere in that equation. > > IMNSHO that's the true reason. I do see why it would be attractive if IgnorePAT was a solid signal to ditch wbinvd support. However, it simply isn't, and to date nothing has cared trip over that gap.