[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0356a84a-765e-b20b-2efd-c5d94fc2347e@intel.com>
Date: Mon, 29 Mar 2021 15:12:57 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Kuppuswamy, Sathyanarayanan"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>
Cc: 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>,
Sean Christopherson <seanjc@...gle.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/1] x86/tdx: Handle MWAIT, MONITOR and WBINVD
On 3/29/21 3:09 PM, Kuppuswamy, Sathyanarayanan wrote:
>>>>> + case EXIT_REASON_MWAIT_INSTRUCTION:
>>>>> + /* MWAIT is supressed, not supposed to reach here. */
>>>>> + WARN(1, "MWAIT unexpected #VE Exception\n");
>>>>> + return -EFAULT;
>>>>
>>>> How is MWAIT "supppressed"?
>>> I am clearing the MWAIT feature flag in early init code. We should also
>>> disable this feature in firmware.
>>> setup_clear_cpu_cap(X86_FEATURE_MWAIT);
>>
>> I'd be more explicit about that. Maybe even reference the code that
>> clears the X86_FEATURE.
> This change is part of the same patch.
Right, but if someone goes and looks at the switch() statement in 10
years is it going to be obvious how MWAIT was "suppressed"?
Powered by blists - more mailing lists