[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4gRDnm0y4=RWhvTSoY2sk=BOyeDDNcCifZD=opyJf05LQ@mail.gmail.com>
Date: Mon, 24 May 2021 19:49:38 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Andi Kleen <ak@...ux.intel.com>
Cc: "Kuppuswamy, Sathyanarayanan"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...el.com>,
Tony Luck <tony.luck@...el.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 7:13 PM Andi Kleen <ak@...ux.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 and for that reason many bare metal
use cases that require wbinvd have not been ported to guests (like
PMEM unlock), and others that only use wbinvd to opportunistically
enforce a cache state (like ACPI sleep states) do not see ill effects
from missing wbinvd. Given KVM ships with a policy to elide wbinvd in
many scenarios adopt the same policy for TDX guests.
Powered by blists - more mailing lists