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@xxxxxxxxxx> 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
