[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191023011951.GB27009@local-michael-cet-test>
Date: Wed, 23 Oct 2019 09:19:51 +0800
From: Yang Weijiang <weijiang.yang@...el.com>
To: Sean Christopherson <sean.j.christopherson@...el.com>
Cc: Yang Weijiang <weijiang.yang@...el.com>,
Jim Mattson <jmattson@...gle.com>,
kvm list <kvm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>
Subject: Re: [PATCH v7 5/7] kvm: x86: Add CET CR4 bit and XSS support
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.
Powered by blists - more mailing lists