On Fri, Jun 2, 2023 at 12:16 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Fri, Jun 02, 2023, Jim Mattson wrote:
> > On Fri, Jun 2, 2023 at 12:18 AM Gao Shiyuan <gaoshiyuan@xxxxxxxxx> wrote:
> > >
> > > From: Shiyuan Gao <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.
Um...
"You may never migrate this VM to a newer kernel. Sucks to be you."
That's not very user-friendly.
