[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4idVP7fzdAcsz_9dqGm7Cmzu441hk692XqcMx3+v1Xwiw@mail.gmail.com>
Date: Mon, 24 May 2021 19:26:03 -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 1/2] x86/tdx: Handle MWAIT and MONITOR
On Mon, May 24, 2021 at 4:32 PM Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com> wrote:
>
> When running as a TDX guest, there are a number of existing,
> privileged instructions that do not work. If the guest kernel
> uses these instructions, the hardware generates a #VE.
>
> You can find the list of unsupported instructions in Intel
> Trust Domain Extensions (IntelĀ® TDX) Module specification,
> sec 9.2.2 and in Guest-Host Communication Interface (GHCI)
> Specification for Intel TDX, sec 2.4.1.
>
> To prevent TD guests from using MWAIT/MONITOR instructions,
> the CPUID flags for these instructions are already disabled
> by the TDX module.
>
> After the above mentioned preventive measures, if TD guests
> still execute these instructions, add appropriate warning
> message (WARN_ONCE()) in #VE handler. This handling behavior
> is same as KVM (which also treats MWAIT/MONITOR as nops with
> warning once in unsupported platforms).
>
> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>
> Reviewed-by: Andi Kleen <ak@...ux.intel.com>
> ---
>
> Changes since RFC v2:
> * Moved WBINVD related changes to a new patch.
> * Fixed commit log as per review comments.
Looks good.
Reviewed-by: Dan Williams <dan.j.williams@...el.com>
Powered by blists - more mailing lists