On Mon, Jan 10, 2022 at 6:20 AM John Levon <levon@xxxxxxxxxxxxxxxxx> wrote:
>
>
> ```
> arch/x86/kernel/cpu/common.c:
>
> 863 /*
> 864 * The Intel SPEC_CTRL CPUID bit implies IBRS and IBPB support,
> 865 * and they also have a different bit for STIBP support. Also,
> 866 * a hypervisor might have set the individual AMD bits even on
> 867 * Intel CPUs, for finer-grained selection of what's available.
> 868 */
> 869 if (cpu_has(c, X86_FEATURE_SPEC_CTRL)) {
> 870 set_cpu_cap(c, X86_FEATURE_IBRS);
> 871 set_cpu_cap(c, X86_FEATURE_IBPB);
> 872 set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL);
> 873 }
>
> arch/x86/kvm/cpuid.c:
>
> 550 /*
> 551 * AMD has separate bits for each SPEC_CTRL bit.
> 552 * arch/x86/kernel/cpu/bugs.c is kind enough to
> 553 * record that in cpufeatures so use them.
> 554 */
> 555 if (boot_cpu_has(X86_FEATURE_IBPB))
> 556 kvm_cpu_cap_set(X86_FEATURE_AMD_IBPB);
> 557 if (boot_cpu_has(X86_FEATURE_IBRS))
> 558 kvm_cpu_cap_set(X86_FEATURE_AMD_IBRS);
> ```
>
> As a result, we're setting AMD-specific bits in the relevant CPUID leaf. They're
> reserved, but it appears, somewhat unfortunately, that libvirt happily reports
> them regardless of vendor - with the knock-on effect that anything using `virsh
> capabilities` to decide which flags to pass to qemu inside the guest VM
> breaks[1].
>
> Curious if other people have hit this, and if there's specific reason why we're
> setting AMD-specific flags on Intel like this.
See the discussion at
https://patchwork.kernel.org/project/kvm/patch/1565854883-27019-2-git-send-email-pbonzini@xxxxxxxxxx/.
