On 10/30/26 17:06, Jiri Denemark 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
On Mon, Oct 26, 2026 at 20:06:54 +0100, Denis V. Lunev wrote: 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 Actually there are more issues on the same transition.
bus-lock-detect on never Zen and v-vmsave-vmload which are also safe to ignore but let us come to the decision first here and decide on followup stuff later on. Den