[PATCH v5 10/27] KVM: arm64: Hide IMPLEMENTATION DEFINED PMU support for the guest

[Oliver Upton]

On Tue, Feb 15, 2022 at 06:52:27PM -0800, Reiji Watanabe wrote:
> Hi Oliver,
> 
> Thank you for the review!
> 
> On Tue, Feb 15, 2022 at 10:57 AM Oliver Upton <oupton at google.com> wrote:
> >
> > Hi Reiji,
> >
> > On Sun, Feb 13, 2022 at 10:57:29PM -0800, Reiji Watanabe wrote:
> > > When ID_AA64DFR0_EL1.PMUVER or ID_DFR0_EL1.PERFMON is 0xf, which
> > > means IMPLEMENTATION DEFINED PMU supported, KVM unconditionally
> > > expose the value for the guest as it is.  Since KVM doesn't support
> > > IMPLEMENTATION DEFINED PMU for the guest, in that case KVM should
> > > expose 0x0 (PMU is not implemented) instead.
> > >
> > > Change cpuid_feature_cap_perfmon_field() to update the field value
> > > to 0x0 when it is 0xf.
> >
> > Definitely agree with the change in this patch. Do we need to tolerate
> > writes of 0xf for ABI compatibility (even if it is nonsensical)?
> > Otherwise a guest with IMP_DEF PMU cannot be migrated to a newer kernel.
> 
> Hmm, yes, I think KVM should tolerate writes of 0xf so that we can
> avoid the migration failure.  I will make this change in v6.
> 
> Since ID registers are immutable with the current KVM, I think a live
> migration failure to a newer kernel happens when the newer kernel/KVM
> supports more CPU features (or when an ID register field is newly
> masked or capped by KVM, etc).  So, I would assume such migration
> breakage on KVM/ARM has been introduced from time to time though.
>

Indeed it has, but IMO migration breakage should really be avoided at
all costs. End of the day, its ABI breakage.

Unless folks feel otherwise, I would be in favor of just ignoring the
IMP_DEF write and setting the field value to NI instead. Allows VMs to
migrate onto newer kernels and fixes the KVM bug at the same time.

--
Oliver