On Mon, Oct 26, 2026 at 20:06:54 +0100, Denis V. Lunev wrote:
From: Denis V. Lunev <den@openvz.org>
Since Linux kernel commit de572491a975 ("KVM: x86: AMD's IBPB is not equivalent to Intel's IBPB") KVM offers spec-ctrl on AMD hosts only when the CPU enumerates IBPB_RET, which Zen 1-3 do not. A host-model guest started on such a CPU under an older kernel has spec-ctrl in its live definition. On a destination with the newer kernel QEMU filters the feature out and the incoming migration fails:
guest CPU doesn't match specification: missing features: spec-ctrl
Restoring a save image or reverting a snapshot fails the same way, so the guest cannot be moved to the new kernel without a restart.
Dropping the bit in libvirt costs the guest nothing beyond what KVM already withholds. KVM grants PRED_CMD for spec-ctrl or ibpb and SPEC_CTRL for spec-ctrl or any of ibrs, amd-stibp and amd-ssbd (kernel commit 39485ed95d6b), and checks the values written to SPEC_CTRL against the host, not the guest CPUID (kernel commit 841c2be09fe4). Both predate de572491a975. Since kernel commit e592ec657d84 KVM also ignores guest CPUID bits it does not support, so a host without IBPB_RET treats the guest as lacking spec-ctrl even if the bit stayed. QEMU drops the bit either way; libvirt only decides whether the guest survives.
When an existing domain is started (incoming migration, restore, snapshot revert) and the hypervisor dropped a required spec-ctrl while providing ibpb and one of ibrs, amd-stibp and amd-ssbd, disable spec-ctrl in the live definition and log a warning. spec-ctrl is also removed from the features QEMU reports as filtered, because check='full' fails on any filtered feature whatever the definition says. Fresh starts and any other missing or extra feature still fail with check='full'.
Signed-off-by: Denis V. Lunev <den@openvz.org> --- RHEL-149512 reports the same failure.
Linux commit: https://git.kernel.org/torvalds/c/de572491a975 KVM thread: https://lore.kernel.org/all/20241011214353.1625057-5-jmattson@google.com/ RHEL bug: https://redhat.atlassian.net/browse/RHEL-149512
So in other words.. The spec-ctrl feature (bit 26 of the main sub leaf of CPUID leaf 0x7) says whether the CPU supports both IA32_PRED_CMD and IA32_SPEC_CTRL MSRs. So when migrating to a host which does not report spec-ctrl, we must make sure the two MSRs are still available by checking other features. The following is the KVM code for deciding when these two MSRs are available static inline bool guest_has_spec_ctrl_msr(struct kvm_vcpu *vcpu) { return (guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL) || guest_cpuid_has(vcpu, X86_FEATURE_AMD_STIBP) || guest_cpuid_has(vcpu, X86_FEATURE_AMD_IBRS) || guest_cpuid_has(vcpu, X86_FEATURE_AMD_SSBD)); } static inline bool guest_has_pred_cmd_msr(struct kvm_vcpu *vcpu) { return (guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL) || guest_cpuid_has(vcpu, X86_FEATURE_AMD_IBPB)); } Which confirms your claim that the CPU must provide ibpb and either ibrs, amd-stibp, or amd-ssbd to support both MSRs. In which case we can safely drop the requirement for spec-ctrl as a guest using these MSRs based on previous spec-ctrl check will keep working. That said I agree with the idea of this patch. I'll look at the actual code with a fresh mind next week :-) Jirka