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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
