All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	kvm@vger.kernel.org, mtosatti@redhat.com,
	linux-kernel@vger.kernel.org, mingo@elte.hu,
	acme@ghostprotocols.net, Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCHv2 2/9] KVM: Expose a version 2 architectural PMU to a guests
Date: Mon, 07 Nov 2011 17:40:00 +0200	[thread overview]
Message-ID: <4EB7FBD0.7060803@redhat.com> (raw)
In-Reply-To: <20111107153439.GG8670@redhat.com>

On 11/07/2011 05:34 PM, Gleb Natapov wrote:
> On Mon, Nov 07, 2011 at 03:22:05PM +0100, Peter Zijlstra wrote:
> > On Thu, 2011-11-03 at 14:33 +0200, Gleb Natapov wrote:
> > > @@ -35,6 +35,7 @@ config KVM
> > >         select KVM_MMIO
> > >         select TASKSTATS
> > >         select TASK_DELAY_ACCT
> > > +       select PERF_EVENTS 
> > 
> > Do you really want to make that an unconditional part of KVM? I know we
> > can't currently build x86 without perf due to that hw breakpoint
> > trainwreck, but people were actually wanting to solve that.
> > 
> I am fine either way (the only thing is that I can't check that I can
> build kvm without pmu right now). But I doubt that there will be many
> KVM deployment without perf enabled and making it optional will increase
> test matrix. KVM has pretty extensive list of selects already for that
> reason. I let maintainers to decide on this.

I prefer to avoid the select, when possible.  But that can be done after
PERF_EVENTS is disentangled from x86.

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2011-11-07 15:40 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 [this message]
2011-11-07 14:34   ` Peter Zijlstra
2011-11-07 14:46     ` Avi Kivity
2011-11-07 14:59       ` Peter Zijlstra
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=4EB7FBD0.7060803@redhat.com \
    --to=avi@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@ghostprotocols.net \
    --cc=fweisbec@gmail.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 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.