[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YKN/DVNt847iEctd@hirez.programming.kicks-ass.net>
Date: Tue, 18 May 2021 10:47:09 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Andi Kleen <ak@...ux.intel.com>
Cc: Like Xu <like.xu@...ux.intel.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Borislav Petkov <bp@...en8.de>,
Sean Christopherson <seanjc@...gle.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>, weijiang.yang@...el.com,
Kan Liang <kan.liang@...ux.intel.com>, wei.w.wang@...el.com,
eranian@...gle.com, liuxiangdong5@...wei.com,
linux-kernel@...r.kernel.org, x86@...nel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v6 07/16] KVM: x86/pmu: Reprogram PEBS event to emulate
guest PEBS counter
On Mon, May 17, 2021 at 07:44:15AM -0700, Andi Kleen wrote:
>
> On 5/17/2021 1:39 AM, Peter Zijlstra wrote:
> > On Tue, May 11, 2021 at 10:42:05AM +0800, Like Xu wrote:
> > > + if (pebs) {
> > > + /*
> > > + * The non-zero precision level of guest event makes the ordinary
> > > + * guest event becomes a guest PEBS event and triggers the host
> > > + * PEBS PMI handler to determine whether the PEBS overflow PMI
> > > + * comes from the host counters or the guest.
> > > + *
> > > + * For most PEBS hardware events, the difference in the software
> > > + * precision levels of guest and host PEBS events will not affect
> > > + * the accuracy of the PEBS profiling result, because the "event IP"
> > > + * in the PEBS record is calibrated on the guest side.
> > > + */
> > > + attr.precise_ip = 1;
> > > + }
> > You've just destroyed precdist, no?
>
> precdist can mean multiple things:
>
> - Convert cycles to the precise INST_RETIRED event. That is not meaningful
> for virtualization because "cycles" doesn't exist, just the raw events.
>
> - For GLC+ and TNT+ it will force the event to a specific counter that is
> more precise. This would be indeed "destroyed", but right now the patch kit
> only supports Icelake which doesn't support that anyways.
>
> So I think the code is correct for now, but will need to be changed for
> later CPUs. Should perhaps fix the comment though to discuss this.
OK, can we then do a better comment that explains *why* this is correct
now and what needs help later?
Because IIUC the only reason it is correct now is because:
- we only support ICL
* and ICL has pebs_format>=2, so {1,2} are the same
* and ICL doesn't have precise_ip==3 support
- Other hardware (GLC+, TNT+) that could possibly care here
is unsupported atm. but needs changes.
None of which is actually mentioned in that comment it does have.
Powered by blists - more mailing lists