> >+static void vmx_vcpu_config_fred_after_set_cpuid(struct kvm_vcpu *vcpu)
> >+{
> >+ struct vcpu_vmx *vmx = to_vmx(vcpu);
> >+
> >+ if (!cpu_feature_enabled(X86_FEATURE_FRED) ||
> >+ !guest_cpuid_has(vcpu, X86_FEATURE_FRED))
> >+ return;
> >+
> >+ /* Enable loading guest FRED MSRs from VMCS */
> >+ vm_entry_controls_setbit(vmx, VM_ENTRY_LOAD_IA32_FRED);
> >+
> >+ /*
> >+ * Enable saving guest FRED MSRs into VMCS and loading host FRED MSRs
> >+ * from VMCS.
> >+ */
> >+ vm_exit_controls_setbit(vmx,
> VM_EXIT_ACTIVATE_SECONDARY_CONTROLS);
> >+ secondary_vm_exit_controls_setbit(vmx,
> >+ SECONDARY_VM_EXIT_SAVE_IA32_FRED
> |
> >+
> SECONDARY_VM_EXIT_LOAD_IA32_FRED);
>
> all above vmcs controls need to be cleared if guest doesn't enumerate FRED, see
>
> https://lore.kernel.org/all/ZJYzPn7ipYfO0fLZ@xxxxxxxxxx/
Good point, the user space could set cpuid multiple times...
> Clearing VM_EXIT_ACTIVATE_SECONDARY_CONTROLS may be problematic when
> new bits are added to secondary vmcs controls. Why not keep
> VM_EXIT_ACTIVATE_SECONDARY_CONTROLS always on if it is supported? or you
> see any perf impact?
I think it from the other way, why keeps hw loading it on every vmentry
even if it's not used by a guest?
Different CPUs may implement it in different ways, which we can't assume.
Other features needing it should set it separately, say with a refcount.
