On 7/14/20 5:51 PM, Sean Christopherson wrote:
> To do the above table, KVM will also need to update itlb_multihit_kvm_mitigation
> when it is unloaded, which seems rather silly. That's partly why I suggested
> keying off CR4.VMXE as it doesn't require poking directly into KVM. E.g. the
> entire fix becomes:
Failing to update itlb_multihit_kvm_mitigation leaves us with something
that's asymmetric. A system with a never-loaded kvm module will say
something different than one that was loaded and then unloaded.
That's funky, but not the end of the world I guess.
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index ed54b3b21c39..4452df7f332d 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -1447,7 +1447,12 @@ static ssize_t l1tf_show_state(char *buf)
>
> static ssize_t itlb_multihit_show_state(char *buf)
> {
> - if (itlb_multihit_kvm_mitigation)
> + if (!boot_cpu_has(X86_FEATURE_MSR_IA32_FEAT_CTL) ||
> + !boot_cpu_has(X86_FEATURE_VMX))
> + return sprintf(buf, "KVM: Mitigation: VMX unsupported\n");
> + else if (!(cr4_read_shadow() & X86_CR4_VMXE))
> + return sprintf(buf, "KVM: Mitigation: VMX disabled\n");
> + else if (itlb_multihit_kvm_mitigation)
> return sprintf(buf, "KVM: Mitigation: Split huge pages\n");
> else
> return sprintf(buf, "KVM: Vulnerable\n");
That's at least short and sweet. I wouldn't object to that at all.
