On Mon, Jan 28, 2019 at 05:20:24PM +0800, Yang Weijiang wrote:
> On Mon, Jan 28, 2019 at 07:28:42AM -0800, Sean Christopherson wrote:
> > On Sun, Jan 27, 2019 at 09:05:59PM +0800, Yang Weijiang wrote:
> > > On Fri, Jan 25, 2019 at 02:50:12PM -0800, Sean Christopherson wrote:
> > > > On Wed, Jan 23, 2019 at 04:59:07AM +0800, Yang Weijiang wrote:
> > > > > +
> > > > > + msr_bitmap = vmx->vmcs01.msr_bitmap;
> > > > > + best = kvm_find_cpuid_entry(vcpu, 7, 0);
> > > > > + if ((best && best->function == 0x7) &&
> > > > > + ((best->ecx & bit(X86_FEATURE_SHSTK)) |
> > > > > + (best->edx & bit(X86_FEATURE_IBT)))) {
> > > > > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_U_CET, MSR_TYPE_RW);
> > > > > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_S_CET, MSR_TYPE_RW);
> > > > > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_INT_SSP_TAB, MSR_TYPE_RW);
> > > > > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_PL0_SSP, MSR_TYPE_RW);
> > > > > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_PL3_SSP, MSR_TYPE_RW);
> > > >
> > > > kvm_cpuid_update() an be called multiple times, don't we need to look
> > > > for a change in status as opposed to the bits being enabled? And at
> > > > that point toggling interception should probably be wrapped in a helper
> > > > function.
> > > >
> > > Hi, Sean,
> > >
> > > Do you mean vmx_cpuid_update() here? I checked the code, it's called in
> > > kvm_vcpu_ioctl_set_cpuid() and kvm_vcpu_ioctl_set_cpuid2(). Given that,
> > > do I still need to check the bits before enable them?
> >
> > Userspace can call the ioctl() any number of times, i.e. you can't
> > anything about the state of vmx->vmcs01.msr_bitmap.
>
> OK, I'll add a flag in vcpu_vmx to mark the bit status and wrap the code in a
> helper.
A flag isn't necessary, just enable/disable the MSRs based on the new
CPUID value. Updating the guest's CPUID values is relatively rare, i.e.
worst case scenario fiddling with the MSR bitmaps is redundant.
