lkml.org 
[lkml]   [2021]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v4 1/1] x86/tdx: Handle MWAIT, MONITOR and WBINVD
From
Date
On 3/31/21 3:28 PM, Kuppuswamy, Sathyanarayanan wrote:
>
> On 3/31/21 3:11 PM, Dave Hansen wrote:
>> On 3/31/21 3:06 PM, Sean Christopherson wrote:
>>> I've no objection to a nice message in the #VE handler.  What I'm
>>> objecting to
>>> is sanity checking the CPUID model provided by the TDX module.  If we
>>> don't
>>> trust the TDX module to honor the spec, then there are a huge pile of
>>> things
>>> that are far higher priority than MONITOR/MWAIT.
>>
>> In other words:  Don't muck with CPUID or the X86_FEATURE at all.  Don't
>> check it to comply with the spec.  If something doesn't comply, we'll
>> get a #VE at *SOME* point.  We don't need to do belt-and-suspenders
>> programming here.
>>
>> That sounds sane to me.
> But I think there are cases (like MCE) where SEAM does not disable
> them because there will be future support for it. We should at-least
> suppress such features in kernel.

Specifics, please.

The hardware (and VMMs and SEAM) have ways of telling the guest kernel
what is supported: CPUID. If it screws up, and the guest gets an
unexpected #VE, so be it.

We don't have all kinds of crazy handling in the kernel's #UD handler
just in case a CPU mis-enumerates a feature and we get a #UD. We have
to trust the underlying hardware to be sane. If it isn't, we die a
horrible death as fast as possible. Why should TDX be any different?

\
 
 \ /
  Last update: 2021-04-01 00:36    [W:0.157 / U:1.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site