> > Signed-off-by: Andi Kleen
>
> I did not contribute to this patch, so please remove that SOB.
>
OK
> > Signed-off-by: Kan Liang
>
> > struct extra_reg *extra_regs;
> > unsigned int er_flags;
> > + boolextra_msr_access; /* EXTRA REG MSR can be
> accessed */
>
> On Wed, Jul 2, 2014 at 2:14 PM, wrote:
> > From: Kan Liang
> >
> > x86, perf: Protect LBR and offcore rsp against KVM lying
> >
> > With -cpu host, KVM reports LBR and offcore support, if the host has
> support.
> > When the guest perf driver tries to access LBR or offcore_rsp MSR, it
> >
>
> On Thu, Jul 03, 2014 at 05:52:37PM +0200, Andi Kleen wrote:
> > > If there's active LBR users out there, we should refuse to enable PT
> > > and vice versa.
> >
> > This doesn't work, e.g. hardware debuggers can take over at any time.
>
> Tough cookies. Hardware debuggers get to deal with w
>
> On Mon, Jul 07, 2014 at 06:34:25AM -0700, kan.li...@intel.com wrote:
> > + /*
> > +* Access LBR MSR may cause #GP under certain circumstances.
> > +* E.g. KVM doesn't support LBR MSR
> > +* Check all LBT MSR here.
> > +* Disable LBR access if any LBR MSRs can not be accesse
> -Original Message-
> From: Peter Zijlstra [mailto:pet...@infradead.org]
> Sent: Tuesday, July 08, 2014 5:29 AM
> To: Liang, Kan
> Cc: a...@firstfloor.org; linux-ker...@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH V3 1/2] perf ignore LBR and offcore_rsp
>
> On Tue, Jul 08, 2014 at 09:49:40AM -0700, kan.li...@intel.com wrote:
> > --- a/arch/x86/kernel/cpu/perf_event.h
> > +++ b/arch/x86/kernel/cpu/perf_event.h
> > @@ -464,6 +464,12 @@ struct x86_pmu {
> > */
> > struct extra_reg *extra_regs;
> > unsigned int er_flags;
> > + /*
> >
> On Tue, Jul 08, 2014 at 09:49:40AM -0700, kan.li...@intel.com wrote:
> > +/*
> > + * Under certain circumstances, access certain MSR may cause #GP.
> > + * The function tests if the input MSR can be safely accessed.
> > + */
> > +static inline bool check_msr(unsigned long msr) {
> > + u64 val
> -Original Message-
> From: Peter Zijlstra [mailto:pet...@infradead.org]
> Sent: Wednesday, July 09, 2014 10:58 AM
> To: Liang, Kan
> Cc: a...@firstfloor.org; linux-ker...@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH V4 1/2] perf ignore LBR and extra_regs
> > >
> > > On Wed, Jul 09, 2014 at 02:32:28PM +, Liang, Kan wrote:
> > > >
> > > >
> > > > > On Tue, Jul 08, 2014 at 09:49:40AM -0700, kan.li...@intel.com wrote:
> > > > > > +/*
> > > > > > + * Unde
> >>> For reproducing the issue, please build the kernel with
> CONFIG_KVM_INTEL = y (for host kernel).
> >>> And CONFIG_PARAVIRT = n and CONFIG_KVM_GUEST = n (for guest
> kernel).
> >>
> >> I'm not sure this is a useful patch.
> >>
> >> This is #GP'ing just because of a limitation in the PMU; ju
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Monday, July 14, 2014 9:40 AM
> To: Liang, Kan; Peter Zijlstra
> Cc: a...@firstfloor.org; linux-ker...@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH V5 1/2] perf ignore LBR and
> > diff --git a/arch/x86/kernel/cpu/perf_event.h
> > b/arch/x86/kernel/cpu/perf_event.h
> > index 3b2f9bd..992c678 100644
> > --- a/arch/x86/kernel/cpu/perf_event.h
> > +++ b/arch/x86/kernel/cpu/perf_event.h
> > @@ -464,6 +464,12 @@ struct x86_pmu {
> > */
> > struct extra_reg *extra_re
>
>
> Since nobody ever treats EVENT_EXTRA_END as an actual event, the value
> of .extra_msr_access is irrelevant, this leaves the only 'possible'
> value 'true' and we can delete all those changes.
>
Right.
> Which, combined with a few whitespace cleanups, gives the below patch.
Thanks. Your
>
> Dear KVM developers:
> I am trying use perf stat inside a VM to obtain some hardware cache
> performance counter values.
> The perf stat can report some numbers for L1 and TLB related counters. But
> for the LLC-loads and LLC-load-misses, the numbers are always 0. It seems
> that the these o
>
> 1. If the guest is non-paravirt, can I get the LLC-loads number?
No, the guest will crash.
> 2. Do you know any method that can capture the LLC-loads for the guest?
I don't know.
> Thanks.
>
0%]
> >
> >782,552,911,616 L1-dcache-loads
> > [80.00%]
> >
> > 5,810,697,456 L1-dcache-load-misses #0.74% of all
> > L1-dcache hits [80.00%]
> >
> > 2,145,907,209 L1-dcache-prefetch-misses
> > [80.00%]
>
t;.
For your case, 0.00% is the misses/hit radio for dTLB cache.
0.74% is the misses/hit radio for L1dcache.
I have no idea what does 80.00% mean.
> >
> > On Wed, Aug 27, 2014 at 12:28 PM, Liang, Kan wrote:
> > >
> > >> > Hi, Kan,
> > >> >
>
17 matches
Mail list logo
