Messages in this thread | | | Subject | Re: [PATCH v4 1/1] x86/tdx: Handle MWAIT, MONITOR and WBINVD | From | Dave Hansen <> | Date | Wed, 31 Mar 2021 15:34:29 -0700 |
| |
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?
| |