On Tue, Mar 30, 2021, Andy Lutomirski wrote: > > > On Mar 30, 2021, at 8:14 AM, Sean Christopherson <sea...@google.com> wrote: > > > > On Mon, Mar 29, 2021, Andy Lutomirski wrote: > >> > >>>> On Mar 29, 2021, at 7:04 PM, Andi Kleen <a...@linux.intel.com> wrote: > >>> > >>> > >>>> > >>>>> No, if these instructions take a #VE then they were executed at CPL=0. > >>>>> MONITOR > >>>>> and MWAIT will #UD without VM-Exit->#VE. Same for WBINVD, s/#UD/#GP. > >>>> > >>>> Dare I ask about XSETBV? > >>> > >>> XGETBV does not cause a #VE, it just works normally. The guest has full > >>> AVX capabilities. > >>> > >> > >> X *SET* BV > > > > Heh, XSETBV also works normally, relative to the features enumerated in > > CPUID. > > XSAVES/XRSTORS support is fixed to '1' in the virtual CPU model. A subset > > of > > the features managed by XSAVE can be hidden by the VMM, but attempting to > > enable > > unsupported features will #GP (either from hardware or injected by TDX > > Module), > > not #VE. > > Normally in non-root mode means that every XSETBV results in a VM exit and, > IIUC, there’s a buglet in that this happens even if CPL==3. Does something > special happen in TDX or does the exit get reflected back to the guest as a > #VE?
Hmm, I forgot about that quirk. I would expect the TDX Module to inject a #GP for that case. I can't find anything in the spec that confirms or denies that, but injecting #VE would be weird and pointless. Andi/Sathya, the TDX Module spec should be updated to state that XSETBV will #GP at CPL!=0. If that's not already the behavior, the module should probably be changed...
