From mboxrd@z Thu Jan  1 00:00:00 1970
From: Gleb Natapov <gleb@redhat.com>
Subject: Re: [PATCH 2/9] KVM: Expose a version 2 architectural PMU to a guests
Date: Tue, 1 Nov 2011 15:57:45 +0200
Message-ID: <20111101135745.GA14726@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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: kvm@vger.kernel.org, mtosatti@redhat.com, mingo@elte.hu,
	a.p.zijlstra@chello.nl, acme@ghostprotocols.net
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:2580 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753713Ab1KAN54 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 1 Nov 2011 09:57:56 -0400
Content-Disposition: inline
In-Reply-To: <20111101123041.GV17571@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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.

--
			Gleb.