On 10/30/26 17:06, Jiri Denemark wrote: > 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 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
