On Tue, Jun 16, 2020 at 9:45 AM Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> wrote: > > Jim Mattson <jmattson@xxxxxxxxxx> writes: > > > On Tue, Jun 16, 2020 at 9:14 AM Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> wrote: > >> > >> state_test/smm_test selftests are failing on AMD with: > >> "Unexpected result from KVM_GET_MSRS, r: 51 (failed MSR was 0x345)" > >> > >> MSR_IA32_PERF_CAPABILITIES is an emulated MSR indeed but only on Intel, > >> make svm_has_emulated_msr() skip it so it is not returned by > >> KVM_GET_MSR_INDEX_LIST. > > > > Do we need to support this MSR under SVM for cross-vendor migration? > > Or, have we given up on that? > > To be honest I'm not sure about the status of cross-vendor migration in > general and PMU implications in particular, hope Paolo/Sean can shed > some light. In this particular case my shallow understanding is that > MSR_IA32_PERF_CAPABILITIES has only one known feature bit which unlocks > an MSR range with additional counters. If the feature bit is not set > this, I guess, can easily be migrated (basically, let's allow writing > '0' there on AMD and return '0' on read). But what if the feature was > enabled? We'll have to support the new MSR range and do something with > it after migration (run intel_pmu in fully emulated mode?). > > Anyway, the immediate issue I'm trying to fix here is: whatever is > returned by KVM_GET_MSR_INDEX_LIST can be successfully queried with > KVM_GET_MSRS as some userspaces count on that. That's a nice property. Is it documented somewhere? Reviewed-by: Jim Mattson <jmattson@xxxxxxxxxx>
