[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YGTvSvr2T2v3t3XA@google.com>
Date: Wed, 31 Mar 2021 21:53:14 +0000
From: Sean Christopherson <seanjc@...gle.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>,
Andi Kleen <ak@...ux.intel.com>,
Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
Raj Ashok <ashok.raj@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/1] x86/tdx: Handle MWAIT, MONITOR and WBINVD
On Wed, Mar 31, 2021, Kuppuswamy Sathyanarayanan wrote:
> Changes since v3:
> * WARN user if SEAM does not disable MONITOR/MWAIT instruction.
Why bother? There are a whole pile of features that are dictated by the TDX
module spec. MONITOR/MWAIT is about as uninteresting as it gets, e.g. absolute
worst case scenario is the guest kernel crashes, whereas a lot of spec violations
would compromise the security of the guest.
> + case EXIT_REASON_MONITOR_INSTRUCTION:
> + case EXIT_REASON_MWAIT_INSTRUCTION:
> + /*
> + * MWAIT/MONITOR features are disabled by TDX Module (SEAM)
> + * and also re-suppressed in kernel by clearing
> + * X86_FEATURE_MWAIT CPU feature flag in tdx_early_init(). So
> + * if TD guest still executes MWAIT/MONITOR instruction with
> + * above suppression, it needs user attention.
> + */
> + WARN(1, "TD Guest used unsupported MWAIT/MONITOR instruction\n");
Why not just WARN_ONCE and call it good?
> + break;
> default:
> pr_warn("Unexpected #VE: %d\n", ve->exit_reason);
> return -EFAULT;
> --
> 2.25.1
>
Powered by blists - more mailing lists