All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Zickus <dzickus@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Jason Wessel <jason.wessel@windriver.com>,
	Ingo Molnar <mingo@elte.hu>,
	Robert Richter <robert.richter@amd.com>,
	ying.huang@intel.com, Andi Kleen <andi@firstfloor.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [V2 PATCH 0/6] x86, NMI: give NMI handler a face-lift
Date: Fri, 19 Nov 2010 11:59:52 -0500	[thread overview]
Message-ID: <20101119165952.GJ18100@redhat.com> (raw)
In-Reply-To: <1290112234.2109.1534.camel@laptop>

On Thu, Nov 18, 2010 at 09:30:33PM +0100, Peter Zijlstra wrote:
> On Thu, 2010-11-18 at 15:08 -0500, Don Zickus wrote:
> > On Thu, Nov 18, 2010 at 01:51:44PM -0600, Jason Wessel wrote:
> > > > So the problem is when the nmi watchdog is enabled, the perf event is
> > > > 'active' and thus tries to read the counter value.  Because it is always
> > > > zero, perf just assumes the counter overflowed and the NMI is his.
> > > >
> > > > Not sure how to fix it yet, other than include the logic that detects we
> > > > are on a guest and disable perf??
> > > >
> > > >   
> > > 
> > > I highly doubt we want to disable perf.   I would rather use the source
> > > and fix the nmi emulation in KVM/Qemu after we hear back the results
> > 
> > Well I think Peter does not have a positive opinion about emulating perf
> > inside a guest.  
> 
> Well, I'll let someone else write it.. I tihnk its pretty pointless to
> have, the whole virt layer totally destroys many (if not all) useful
> metrics.
> 
> But I don't have a problem with full msr emulation, what I do not like
> is a direct msr passthough bypassing perf.
> 
> > Nor are the KVM folks having much success in doing so.
> 
> Just busy doing other stuff I guess.. Jes was going to prod at it at
> some point.
> 
> > Just to clarify, perf counter emulation is _not_ implemented in kvm.
> > Therefore disabling perf in the guest makes sense until someone gets
> > around to actually writing the emulation code for perf in a guest. :-)
> 
> Right, which is what I proposed, on init do a checking_wrmsrl() on a
> known PMU reg, KVM/qemu should fault on that.. (I'd prefer it if they'd
> also fault on reading it too).

Reading the kvm code in arch/x86/kernel/kvm/x86.c, it seems like they do
_not_ fault on writes, only on some (which don't include a bunch of the
perfctrs).  The reason seems to be to prevent older distros from falling
apart that could not handle those faults properly.

I thought about a patch like this, but it only works for kvm and doesn't
really solve the problem for other virt-machines like xen and vmware.

Cheers,
Don


diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index bbe3c4a..ef7119e 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -493,6 +493,10 @@ static int x86_setup_perfctr(struct perf_event *event)
 
 static int x86_pmu_hw_config(struct perf_event *event)
 {
+	
+	if (perf_guest_cbs && !perf_guest_cbs->is_perfctr_emulated())
+		return -EOPNOTSUPP;
+
 	if (event->attr.precise_ip) {
 		int precise = 0;
 
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2288ad8..58203ea 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4600,10 +4600,16 @@ static unsigned long kvm_get_guest_ip(void)
 	return ip;
 }
 
+static int kvm_is_perfctr_emulated(void)
+{
+	return 0;
+}
+
 static struct perf_guest_info_callbacks kvm_guest_cbs = {
 	.is_in_guest		= kvm_is_in_guest,
 	.is_user_mode		= kvm_is_user_mode,
 	.get_guest_ip		= kvm_get_guest_ip,
+	.is_perfctr_emulated	= kvm_is_perfctr_emulated,
 };
 
 void kvm_before_handle_nmi(struct kvm_vcpu *vcpu)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 057bf22..9cb500b 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -469,6 +469,7 @@ struct perf_guest_info_callbacks {
 	int (*is_in_guest) (void);
 	int (*is_user_mode) (void);
 	unsigned long (*get_guest_ip) (void);
+	int (*is_perfctr_emulated) (void);
 };
 
 #ifdef CONFIG_HAVE_HW_BREAKPOINT

  reply	other threads:[~2010-11-19 17:00 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-12 14:43 [V2 PATCH 0/6] x86, NMI: give NMI handler a face-lift Don Zickus
2010-11-12 14:43 ` [PATCH 1/6] x86, NMI: Add NMI symbol constants and rename memory parity to PCI SERR Don Zickus
2010-11-12 14:43 ` [PATCH 2/6] x86, NMI: Add touch_nmi_watchdog to io_check_error delay Don Zickus
2010-11-12 14:43 ` [PATCH 3/6] x86, NMI: Rewrite NMI handler Don Zickus
2010-11-12 14:43 ` [PATCH 4/6] x86, NMI: Remove DIE_NMI_IPI and add priorties to handlers Don Zickus
2010-11-12 14:43 ` [PATCH 5/6] x86, NMI: Allow NMI reason io port (0x61) to be processed on any CPU Don Zickus
2010-11-12 14:43 ` [PATCH 6/6] x86, NMI: Remove do_nmi_callback logic Don Zickus
2010-11-12 15:05 ` [V2 PATCH 0/6] x86, NMI: give NMI handler a face-lift Jason Wessel
2010-11-12 15:42   ` Don Zickus
2010-11-12 15:55     ` Jason Wessel
2010-11-12 16:11       ` Don Zickus
2010-11-12 16:34         ` Jason Wessel
2010-11-12 17:27           ` Don Zickus
2010-11-16 18:43             ` Don Zickus
2010-11-16 20:04               ` Jason Wessel
2010-11-18  8:05                 ` Ingo Molnar
2010-11-18 12:47                   ` Jason Wessel
2010-11-18 13:17                     ` Peter Zijlstra
2010-11-18 14:32                       ` Don Zickus
2010-11-18 15:18                         ` Jason Wessel
2010-11-18 15:38                       ` Peter Zijlstra
2010-11-18 19:32                       ` Don Zickus
2010-11-18 19:51                         ` Jason Wessel
2010-11-18 20:04                           ` Peter Zijlstra
2010-11-18 20:08                           ` Don Zickus
2010-11-18 20:11                             ` Cyrill Gorcunov
2010-11-18 20:52                               ` Don Zickus
2010-11-18 21:01                                 ` Cyrill Gorcunov
2010-11-18 21:16                                   ` Don Zickus
2010-11-18 21:26                                     ` Cyrill Gorcunov
2010-11-18 20:28                             ` Cyrill Gorcunov
2010-11-18 20:39                               ` Cyrill Gorcunov
2010-11-18 21:02                                 ` Don Zickus
2010-11-18 21:19                                   ` Cyrill Gorcunov
2010-11-18 20:30                             ` Peter Zijlstra
2010-11-19 16:59                               ` Don Zickus [this message]
2010-11-19 18:25                                 ` Peter Zijlstra
2010-11-19 22:59                                   ` Don Zickus
2010-11-19 23:09                                     ` Peter Zijlstra
2010-11-19 23:30                                       ` Jason Wessel
2010-11-22 14:22                                         ` Don Zickus
2010-11-22 14:22                                       ` Don Zickus
2010-11-22 14:29                                         ` Peter Zijlstra
2010-11-18 20:04                         ` Cyrill Gorcunov
2010-11-18 21:56                         ` Cyrill Gorcunov
2010-11-18 21:58                           ` Cyrill Gorcunov
2010-11-18 22:15                           ` Cyrill Gorcunov
2010-11-18 22:24                             ` Jason Wessel
2010-11-18 22:27                               ` Cyrill Gorcunov

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=20101119165952.GJ18100@redhat.com \
    --to=dzickus@redhat.com \
    --cc=andi@firstfloor.org \
    --cc=fweisbec@gmail.com \
    --cc=jason.wessel@windriver.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=robert.richter@amd.com \
    --cc=ying.huang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.