Re: [PATCH v7 5/7] kvm: x86: Add CET CR4 bit and XSS support

[Sean Christopherson]

On Fri, Oct 18, 2019 at 09:58:02AM +0800, Yang Weijiang wrote:
> On Thu, Oct 17, 2019 at 12:56:42PM -0700, Sean Christopherson wrote:
> > On Wed, Oct 02, 2019 at 12:05:23PM -0700, Jim Mattson wrote:
> > > > +               u64 kvm_xss = kvm_supported_xss();
> > > > +
> > > > +               best->ebx =
> > > > +                       xstate_required_size(vcpu->arch.xcr0 | kvm_xss, true);
> > > 
> > > Shouldn't this size be based on the *current* IA32_XSS value, rather
> > > than the supported IA32_XSS bits? (i.e.
> > > s/kvm_xss/vcpu->arch.ia32_xss/)
> > 
> > Ya.
> >
> I'm not sure if I understand correctly, kvm_xss is what KVM supports,
> but arch.ia32_xss reflects what guest currently is using, shoudn't CPUID
> report what KVM supports instead of current status?
> Will CPUID match current IA32_XSS status if guest changes it runtime?

Not in this case.  Select CPUID output is dependent on current state as
opposed to being a constant defind by hardware.  Per the SDM, EBX is:

  The size in bytes of the XSAVE area containing all states enabled by
  XCRO | IA32_XSS

Since KVM is emulating CPUID for the guest, XCR0 and IA32_XSS in this
context refers to the guest's current/actual XCR0/IA32_XSS values.  The
purpose of this behavior is so that software can call CPUID to query the
actual amount of memory that is needed for XSAVE(S), as opposed to the
absolute max size that _might_ be needed.

MONITOR/MWAIT is the other case that comes to mind where CPUID dynamically
reflects configured state, e.g. MWAIT is reported as unsupported if it's
disabled via IA32_MISC_ENABLE MSR.