From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Avi Kivity <avi@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>,
kvm@vger.kernel.org, mtosatti@redhat.com,
linux-kernel@vger.kernel.org, mingo@elte.hu,
acme@ghostprotocols.net
Subject: Re: [PATCHv2 2/9] KVM: Expose a version 2 architectural PMU to a guests
Date: Mon, 07 Nov 2011 15:59:08 +0100 [thread overview]
Message-ID: <1320677949.18053.54.camel@twins> (raw)
In-Reply-To: <4EB7EF4F.3090907@redhat.com>
On Mon, 2011-11-07 at 16:46 +0200, Avi Kivity wrote:
> On 11/07/2011 04:34 PM, Peter Zijlstra wrote:
> > On Thu, 2011-11-03 at 14:33 +0200, Gleb Natapov wrote:
> > > +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->idx, (unsigned long *)&pmu->reprogram_pmi)) {
> > > + kvm_perf_overflow(perf_event, data, regs);
> > > + kvm_make_request(KVM_REQ_PMU, pmc->vcpu);
> > > + /*
> > > + * Inject PMI. If vcpu was in a guest mode during NMI PMI
> > > + * can be ejected on a guest mode re-entry. Otherwise we can't
> > > + * be sure that vcpu is not halted, so we should kick it, but
> > > + * this is impossible from NMI context. Do it from irq work
> > > + * instead.
> > > + */
> > > + if (!kvm_is_in_guest())
> > > + irq_work_queue(&pmc->vcpu->arch.pmu.irq_work);
> > > + else
> > > + kvm_make_request(KVM_REQ_PMI, pmc->vcpu);
> > > + }
> > > +}
> >
> > I'm not sure I get this, since the counters are vcpu task bound and only
> > count while the guest is running as per (144d31e6f19) how can we get an
> > NMI outside of guest context with the vcpu not halted?
>
> PMI skew. Do we know how bad it can get?
You're talking about the PMI getting asserted before leaving guest mode
but not getting ran until after we left guest mode?
But in that case we know the guest is stopped, right? So we can simply
set that REQ_PMI bit and have guest entry sort things, no?
next prev parent reply other threads:[~2011-11-07 14:59 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-03 12:33 [PATCHv2 0/9] KVM in-guest performance monitoring Gleb Natapov
2011-11-03 12:33 ` [PATCHv2 1/9] KVM: Expose kvm_lapic_local_deliver() Gleb Natapov
2011-11-03 12:33 ` [PATCHv2 2/9] KVM: Expose a version 2 architectural PMU to a guests Gleb Natapov
2011-11-07 14:22 ` Peter Zijlstra
2011-11-07 15:34 ` Gleb Natapov
2011-11-07 15:40 ` Avi Kivity
2011-11-07 14:34 ` Peter Zijlstra
2011-11-07 14:46 ` Avi Kivity
2011-11-07 14:59 ` Peter Zijlstra [this message]
2011-11-07 15:11 ` Gleb Natapov
2011-11-07 15:13 ` Avi Kivity
2011-11-07 15:19 ` Gleb Natapov
2011-11-07 15:25 ` Avi Kivity
2011-11-07 16:22 ` Peter Zijlstra
2011-11-07 16:26 ` Gleb Natapov
2011-11-07 14:36 ` Peter Zijlstra
2011-11-07 15:25 ` Gleb Natapov
2011-11-07 16:45 ` Peter Zijlstra
2011-11-07 17:17 ` Gleb Natapov
2011-11-03 12:33 ` [PATCHv2 3/9] KVM: Add generic RDPMC support Gleb Natapov
2011-11-03 12:33 ` [PATCHv2 4/9] KVM: SVM: Intercept RDPMC Gleb Natapov
2011-11-03 12:33 ` [PATCHv2 5/9] KVM: VMX: " Gleb Natapov
2011-11-03 12:33 ` [PATCHv2 6/9] perf: expose perf capability to other modules Gleb Natapov
2011-11-07 14:07 ` Peter Zijlstra
2011-11-07 15:53 ` Gleb Natapov
2011-11-07 16:01 ` Peter Zijlstra
2011-11-07 16:22 ` Gleb Natapov
2011-11-07 16:25 ` Peter Zijlstra
2011-11-08 12:49 ` Gleb Natapov
2011-11-08 13:26 ` Peter Zijlstra
2011-11-08 13:54 ` Gleb Natapov
2011-11-08 14:12 ` Peter Zijlstra
2011-11-08 14:18 ` Gleb Natapov
2011-11-08 14:31 ` Peter Zijlstra
2011-11-10 11:56 ` Gleb Natapov
2011-11-03 12:33 ` [PATCHv2 7/9] KVM: Expose the architectural performance monitoring CPUID leaf Gleb Natapov
2011-11-07 14:09 ` Peter Zijlstra
2011-11-07 15:41 ` Gleb Natapov
2011-11-07 15:45 ` Peter Zijlstra
2011-11-07 15:54 ` Gleb Natapov
2011-11-03 12:33 ` [PATCHv2 8/9] KVM: x86 emulator: fix RDPMC privilege check Gleb Natapov
2011-11-03 12:33 ` [PATCHv2 9/9] KVM: x86 emulator: implement RDPMC (0F 33) Gleb Natapov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1320677949.18053.54.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mtosatti@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox