>> + if (data & MITI_CTRL_BHB_CLEAR_SEQ_S_USED && >> + kvm_cpu_cap_has(X86_FEATURE_BHI_CTRL) && >> + !(host_arch_capabilities & ARCH_CAP_BHI_NO)) >> + spec_ctrl_mask |= SPEC_CTRL_BHI_DIS_S; >> + >> + /* >> + * Intercept IA32_SPEC_CTRL to disallow guest from changing >> + * certain bits if "virtualize IA32_SPEC_CTRL" isn't supported >> + * e.g., in nested case. >> + */ >> + if (spec_ctrl_mask && !cpu_has_spec_ctrl_shadow()) >> + vmx_enable_intercept_for_msr(vcpu, MSR_IA32_SPEC_CTRL, MSR_TYPE_RW); >> + >> + /* >> + * KVM_CAP_FORCE_SPEC_CTRL takes precedence over >> + * MSR_VIRTUAL_MITIGATION_CTRL. >> + */ >> + spec_ctrl_mask &= ~vmx->vcpu.kvm->arch.force_spec_ctrl_mask; >> + >> + vmx->force_spec_ctrl_mask = vmx->vcpu.kvm->arch.force_spec_ctrl_mask | >> + spec_ctrl_mask; >> + vmx->force_spec_ctrl_value = vmx->vcpu.kvm->arch.force_spec_ctrl_value | >> + spec_ctrl_mask; >> + vmx_set_spec_ctrl(&vmx->vcpu, vmx->spec_ctrl_shadow); >> + >> vmx->msr_virtual_mitigation_ctrl = data; >> break; > >I continue find all of this unpalatable. The guest tells KVM what software >mitigations the guest is using, and then KVM is supposed to translate that into >some hardware functionality? And merge that with userspace's own overrides? Yes. It is ugly. I will drop all Intel-defined stuff from KVM. Actually, I wanted to punt to userspace ... > >Blech. > >With KVM_CAP_FORCE_SPEC_CTRL, I don't see any reason for KVM to support the >Intel-defined virtual MSRs. If the userspace VMM wants to play nice with the >Intel-defined stuff, then userspace can advertise the MSRs and use an MSR filter >to intercept and "emulate" the MSRs. They should be set-and-forget MSRs, so >there's no need for KVM to handle them for performance reasons. ... I had this idea of implementing policy-related stuff in userspace, and I wrote in the cover-letter: """ 1. the KVM<->userspace ABI defined in patch 1 I am wondering if we can allow the userspace to configure the mask and the shadow value during guest's lifetime and do it on a vCPU basis. this way, in conjunction with "virtual MSRs" or any other interfaces, the usespace can adjust hardware mitigations applied to the guest during guest's lifetime e.g., for the best performance. """ As said, this requires some tweaks to KVM_CAP_FORCE_SPEC_CTRL, such as making the mask and shadow values adjustable and applicable on a per-vCPU basis. The tweaks are not necessarily for Intel-defined virtual MSRs; if there were other preferable interfaces, they could also benefit from these changes. Any objections to these tweaks to KVM_CAP_FORCE_SPEC_CTRL? > >That way KVM doesn't need to deal with the the virtual MSRs, userspace can make >an informed decision when deciding how to set KVM_CAP_FORCE_SPEC_CTRL, and as a >bonus, rollouts for new mitigation thingies should be faster as updating userspace >is typically easier than updating the kernel/KVM. Good point!
