```
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.
thanks
john
[1] yes, it should be using `virsh domcapabilities`, but that didn't use to
exist AFAIK
