> > Signed-off-by: Andi Kleen <a...@linux.intel.com>
> 
> I did not contribute to this patch, so please remove that SOB.
> 

OK

> > Signed-off-by: Kan Liang <kan.li...@intel.com>
> 
> >     struct extra_reg *extra_regs;
> >     unsigned int er_flags;
> > +   bool            extra_msr_access;          /* EXTRA REG MSR can be
> accessed */
> >
> 
> This doesn't look right, needs a flag for each extra register.
> 
> They are completely unrelated to each other.

The extra register is either MSR_OFFCORE_RSP_0 or MSR_OFFCORE_RSP_1.
I will add two variables to handle them.

> 
> BTW this will also cause KVM messages at each boot now.
>

Do you mean the "unhandled wrmsr" or " unhandled rdmsr " messages? 
You should not observer  such error message for offcore msrs and LBR from/to 
msrs.

But I forget to handle LBR TOS in KVM patch. You may observed unhandled rdmsr: 
0x1c9 when doing LBR in guest.
I will fix it in next version.
 
> >             wrmsrl(hwc->extra_reg.reg, hwc->extra_reg.config);
> >     wrmsrl(hwc->config_base, (hwc->config | enable_mask) &
> > ~disable_mask);  } diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
> > b/arch/x86/kernel/cpu/perf_event_intel.c
> > index adb02aa..8011d42 100644
> > --- a/arch/x86/kernel/cpu/perf_event_intel.c
> > +++ b/arch/x86/kernel/cpu/perf_event_intel.c
> > @@ -2565,6 +2565,13 @@ __init int intel_pmu_init(void)
> >             }
> >     }
> >
> > +   /* Access LBR MSR may cause #GP under certain circumstances. E.g.
> KVM doesn't support LBR MSR */
> > +   if (x86_pmu.lbr_nr)
> > +           x86_pmu.lbr_msr_access =
> test_msr_access(x86_pmu.lbr_tos) &
> > +test_msr_access(x86_pmu.lbr_from);
> 
> s/&/&&/
> 
> And also this doesn't cover the case when someone takes over the LBRs and
> they start #GPing later.
> So for LBR the test has to be still at each access.

In the second patch, the LBR test has been moved to runtime check.
This case has been handled.  


Kan

> 
> -Andi
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to