On Thu, 20 Jun 2019 at 16:17, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 20/06/19 08:46, Xiaoyao Li wrote: > >> > >> It depends on whether or not processors support the 1-setting instead > >> of “enable XSAVES/XRSTORS” is 1 in VM-exection control field. Anyway, > > > > Yes, whether this field exist or not depends on whether processors > > support the 1-setting. > > > > But if "enable XSAVES/XRSTORS" is clear to 0, XSS_EXIT_BITMAP doesn't > > work. I think in this case, there is no need to set this vmcs field? > > vmx->secondary_exec_control can change; you are making the code more > complex by relying on the value of the field at the point of vmx_vcpu_setup. > > I do _think_ your version is incorrect, because at this point CPUID has > not been initialized yet and therefore > vmx_compute_secondary_exec_control has not set SECONDARY_EXEC_XSAVES. > However I may be wrong because I didn't review the code very closely: > the old code is obvious and so there is no point in changing it. Agreed, in addition, guest can enable/disable cpuid bits by grub parameter, should we call kvm_x86_ops->cpuid_update() in kvm_vcpu_reset() path to reflect the new guest cpuid influence to exec_control? e.g. the first boot guest disable xsaves in grub, kvm disables xsaves in exec_control; then guest reboot w/ xsaves enabled, it still get an #UD when executing. Regards, Wanpeng Li
