On Mon, Oct 26, 2026 at 20:06:54 +0100, Denis V. Lunev wrote:
> From: Denis V. Lunev <[email protected]>
>
> 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 <[email protected]>
> ---
> RHEL-149512 reports the same failure.
>
> Linux commit: https://git.kernel.org/torvalds/c/de572491a975
> KVM thread:
> https://lore.kernel.org/all/[email protected]/
> 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
