On Sat, May 30, 2026, [email protected] wrote: > > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c > > index c81a24d0efdf6..fd1c417b4f9b9 100644 > > --- a/arch/x86/kernel/kvm.c > > +++ b/arch/x86/kernel/kvm.c > > @@ -460,7 +460,7 @@ static void __init sev_map_percpu_data(void) > > [ ... ] > > > -static void kvm_guest_cpu_offline(bool shutdown) > > +static void kvm_guest_cpu_offline(enum kvm_guest_cpu_action action) > > { > > kvm_disable_steal_time(); > > if (kvm_para_has_feature(KVM_FEATURE_PV_EOI)) > > @@ -468,9 +468,10 @@ static void kvm_guest_cpu_offline(bool shutdown) > > if (kvm_para_has_feature(KVM_FEATURE_MIGRATION_CONTROL)) > > wrmsrq(MSR_KVM_MIGRATION_CONTROL, 0); > > [Severity: High] > This isn't a bug introduced by this patch, but I noticed that > MSR_KVM_MIGRATION_CONTROL is cleared to 0 here during CPU offline and system > suspend, but it does not appear to be re-enabled upon online/resume. > > Since this patch introduces the kvm_guest_cpu_action enum to solve an > identical state-machine issue for kvmclock, should we also use this action > enum to ensure the migration control MSR isn't incorrectly cleared on > suspend? Otherwise, wouldn't a single CPU hotplug event or a suspend/resume > cycle permanently disable live migration for the entire VM?
Looks like. That's someone else's future problem though.
