[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4jKY0rmewFnyL6My5-b+w8ANAwDY2tLXZk4CYKydoVbtg@mail.gmail.com>
Date: Mon, 24 May 2021 16:39:49 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...el.com>,
Tony Luck <tony.luck@...el.com>,
Andi Kleen <ak@...ux.intel.com>,
Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
Raj Ashok <ashok.raj@...el.com>,
Sean Christopherson <seanjc@...gle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v2-fix-v2 2/2] x86/tdx: Ignore WBINVD instruction for TDX guest
On Mon, May 24, 2021 at 4:32 PM Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com> wrote:
>
> Functionally only DMA devices can notice a side effect from
> WBINVD's cache flushing. But, 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.
I thought we discussed that there are other considerations for wbinvd
besides DMA? In any event this paragraph is actively misleading
because it disregards ACPI and Persistent Memory secure-erase whose
usages of wbinvd have nothing to do with DMA. I would much prefer a
patch to shutdown all the known wbinvd users as a precursor to this
patch rather than assuming it's ok to simply ignore it. You have
mentioned that TDX does not need to use those paths, but rather than
assume they can't be used why not do the audit to explicitly disable
them? Otherwise this statement seems to imply that the audit has not
been done.
Powered by blists - more mailing lists