On Fri, Jun 3, 2023 at 6:52 AM Sean Christopherson <seanjc@xxxxxxxxxx <mailto:seanjc@xxxxxxxxxx>> wrote: > On Fri, Jun 02, 2023, Jim Mattson wrote: > > On Fri, Jun 2, 2023 at 2:48 PM Sean Christopherson <seanjc@xxxxxxxxxx <mailto:seanjc@xxxxxxxxxx>> wrote: > > > > > > On Fri, Jun 02, 2023, Jim Mattson wrote: > > > > On Fri, Jun 2, 2023 at 12:16 PM Sean Christopherson <seanjc@xxxxxxxxxx <mailto:seanjc@xxxxxxxxxx>> wrote: > > > > > > > > > > On Fri, Jun 02, 2023, Jim Mattson wrote: > > > > > > On Fri, Jun 2, 2023 at 12:18 AM Gao Shiyuan <gaoshiyuan@xxxxxxxxx <mailto:gaoshiyuan@xxxxxxxxx>> wrote: > > > > > > > > > > > > > > From: Shiyuan Gao <gaoshiyuan@xxxxxxxxx <mailto:gaoshiyuan@xxxxxxxxx>> > > > > > > > > > > > > > > When live-migrate VM on icelake microarchitecture, if the source > > > > > > > host kernel before commit 2e8cd7a3b828 ("kvm: x86: limit the maximum > > > > > > > number of vPMU fixed counters to 3") and the dest host kernel after this > > > > > > > commit, the migration will fail. > > > > > > > > > > > > > > The source VM's CPUID.0xA.edx[0..4]=4 that is reported by KVM and > > > > > > > the IA32_PERF_GLOBAL_CTRL MSR is 0xf000000ff. However the dest VM's > > > > > > > CPUID.0xA.edx[0..4]=3 and the IA32_PERF_GLOBAL_CTRL MSR is 0x7000000ff. > > > > > > > This inconsistency leads to migration failure. > > > > > > > > > > IMO, this is a userspace bug. KVM provided userspace all the information it needed > > > > > to know that the target is incompatible (3 counters instead of 4), it's userspace's > > > > > fault for not sanity checking that the target is compatible. > > > > > > > > > > I agree that KVM isn't blame free, but hacking KVM to cover up userspace mistakes > > > > > everytime a feature appears or disappears across kernel versions or configs isn't > > > > > maintainable. > > > > yeah, this is userspace's fault, I also submmit a patch to QEMU: https://lore.kernel.org/kvm/20230602073857.96790-1-gaoshiyuan@xxxxxxxxx/T/#u > > > > > > > > "You may never migrate this VM to a newer kernel. Sucks to be you." > > > > > > Userspace can fudge/fixup state to migrate the VM. > > > > Um, yeah. Userspace can clear bit 35 from the saved > > IA32_PERF_GLOBAL_CTRL MSR so that the migration will complete. But > > what happens the next time the guest tries to set bit 35 in > > IA32_PERF_GLOBAL_CTRL, which it will probably do, since it cached > > CPUID.0AH at boot? > > > Ah, right. Yeah, guest is hosed. > > > I'm still not convinced this is KVM's problem to fix. > I tried to clear bit 35 in userspace during the migration process, the migration is successful. However, the perf cann't be used in the dest VM. I admit that fixed this problem in KVM is unsuitable. I can't find any better way.
