From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2/9] KVM: Expose a version 2 architectural PMU to a guests Date: Wed, 02 Nov 2011 11:54:33 +0200 Message-ID: <4EB11359.1030304@redhat.com> References: <1319993624-20247-1-git-send-email-gleb@redhat.com> <1319993624-20247-3-git-send-email-gleb@redhat.com> <4EAFCE36.4070509@redhat.com> <20111101123041.GV17571@redhat.com> <20111101135745.GA14726@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, mtosatti@redhat.com, mingo@elte.hu, a.p.zijlstra@chello.nl, acme@ghostprotocols.net To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:41515 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751572Ab1KBJyy (ORCPT ); Wed, 2 Nov 2011 05:54:54 -0400 In-Reply-To: <20111101135745.GA14726@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/01/2011 03:57 PM, Gleb Natapov wrote: > On Tue, Nov 01, 2011 at 02:30:41PM +0200, Gleb Natapov wrote: > > > > > > > + > > > > +static void kvm_perf_overflow(struct perf_event *perf_event, > > > > + struct perf_sample_data *data, > > > > + struct pt_regs *regs) > > > > +{ > > > > + struct kvm_pmc *pmc = perf_event->overflow_handler_context; > > > > + struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu; > > > > + __set_bit(pmc_to_global_idx(pmc), > > > > + (unsigned long *)&pmu->global_status); > > > > +} > > > > + > > > > +static void kvm_perf_overflow_intr(struct perf_event *perf_event, > > > > + struct perf_sample_data *data, struct pt_regs *regs) > > > > +{ > > > > + struct kvm_pmc *pmc = perf_event->overflow_handler_context; > > > > + struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu; > > > > + if (!__test_and_set_bit(pmc_to_global_idx(pmc), > > > > + (unsigned long *)&pmu->reprogram_pmi)) { > > > > + kvm_perf_overflow(perf_event, data, regs); > > > > + kvm_make_request(KVM_REQ_PMU, pmc->vcpu); > > > > + } > > > > +} > > > > > > Is it safe to use the __ versions here? > > > > > It supposed to run in an NMI context on the same CPU that just ran > > the vcpu so simultaneous access to the same variable from different > > CPUs shouldn't be possible. But if your scenario below can happen then > > that assumption may not hold. The question is if PMI delivery can be > > so skewed as to be delivered long after vmexit (which switches perf msr > > values btw). > > > Thinking about it some more since perf events we create are bound to a > vcpu task it is impossible to have event callback called on a different CPU. Ok. Maybe there is some theoretical skew value that gets the NMI delayed past the context switch, but not on any real cpu. -- error compiling committee.c: too many arguments to function