On Tue, Oct 22, 2019 at 01:13:21PM -0700, Sean Christopherson wrote: > 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. Yep, make sense, thank you for explanation.
