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;
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>
 <CAPcyv4jKY0rmewFnyL6My5-b+w8ANAwDY2tLXZk4CYKydoVbtg@mail.gmail.com>
 <b420a7af-5202-fee9-9e0b-39680d0cc9c8@linux.intel.com> <CAPcyv4gNz9gKsHVcindp3OsHz4hMRWPZgsNu1A5xrDQg7tYqNA@mail.gmail.com>
 <cea7c704-5f1c-3f84-e47b-c62da18e358e@linux.intel.com> <CAPcyv4h4=eNZFS7d13WvzpWzTkHAMF7Mxo0frqf2gdmaFN3++Q@mail.gmail.com>
 <125f8362-b1e3-d304-f943-3fc2f07b5d79@linux.intel.com> <CAPcyv4gRDnm0y4=RWhvTSoY2sk=BOyeDDNcCifZD=opyJf05LQ@mail.gmail.com>
 <6f44fbeb-a8be-d2e4-5161-d46ddf09482e@linux.intel.com>
In-Reply-To: <6f44fbeb-a8be-d2e4-5161-d46ddf09482e@linux.intel.com>
From:   Dan Williams <dan.j.williams@intel.com>
Date:   Mon, 24 May 2021 20:40:42 -0700
Message-ID: <CAPcyv4iLNkWpopY6gN9bXtTxnM3qm0YatwV4jc-zVn-VEYpprw@mail.gmail.com>
Subject: Re: [RFC v2-fix-v2 2/2] x86/tdx: Ignore WBINVD instruction for TDX guest
To:     Andi Kleen <ak@linux.intel.com>
Cc:     "Kuppuswamy, Sathyanarayanan" 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@kernel.org>,
        Dave Hansen <dave.hansen@intel.com>,
        Tony Luck <tony.luck@intel.com>,
        Kirill Shutemov <kirill.shutemov@linux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
        Raj Ashok <ashok.raj@intel.com>,
        Sean Christopherson <seanjc@google.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, May 24, 2021 at 8:27 PM Andi Kleen <ak@linux.intel.com> wrote:
>
>
> On 5/24/2021 7:49 PM, Dan Williams wrote:
> > On Mon, May 24, 2021 at 7:13 PM Andi Kleen <ak@linux.intel.com> 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.