public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Like Xu <like.xu@linux.intel.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	like.xu@intel.com, wei.w.wang@intel.com,
	Kan Liang <kan.liang@linux.intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC] [PATCH v2 0/5] Intel Virtual PMU Optimization
Date: Sat, 23 Mar 2019 16:15:43 -0700	[thread overview]
Message-ID: <20190323231543.GE18020@tassilo.jf.intel.com> (raw)
In-Reply-To: <20190323172800.GD6058@hirez.programming.kicks-ass.net>

> > We optimize the current vPMU to work in this manner:
> > 
> > (1) rely on the existing host perf (perf_event_create_kernel_counter)
> >     to allocate counters for in-use vPMC and always try to reuse events;
> > (2) vPMU captures guest accesses to the eventsel and fixctrl msr directly
> >     to the hardware msr that the corresponding host event is scheduled on
> >     and avoid pollution from host is also needed in its partial runtime;
> 
> If you do pass-through; how do you deal with event constraints?

The guest has to deal with them. It already needs to know
the model number to program the right events, can as well know
the constraints too.

For architectural events that don't need the model number it's
not a problem because they don't have constraints.

-Andi

  reply	other threads:[~2019-03-23 23:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-23 14:18 [RFC] [PATCH v2 0/5] Intel Virtual PMU Optimization Like Xu
2019-03-23 14:18 ` [RFC] [PATCH v2 1/5] perf/x86: avoid host changing counter state for kvm_intel events holder Like Xu
2019-03-23 14:18 ` [RFC] [PATCH v2 2/5] KVM/x86/vPMU: add pmc operations for vmx and count to track release Like Xu
2019-03-23 14:18 ` [RFC] [PATCH v2 3/5] KVM/x86/vPMU: add Intel vPMC enable/disable and save/restore support Like Xu
2019-03-23 14:18 ` [RFC] [PATCH v2 4/5] KVM/x86/vPMU: add vCPU scheduling support for hw-assigned vPMC Like Xu
2019-03-23 14:18 ` [RFC] [PATCH v2 5/5] KVM/x86/vPMU: not do reprogram_counter for Intel " Like Xu
2019-03-23 17:28 ` [RFC] [PATCH v2 0/5] Intel Virtual PMU Optimization Peter Zijlstra
2019-03-23 23:15   ` Andi Kleen [this message]
2019-03-25  6:07     ` Like Xu
2019-03-25  6:47   ` Like Xu
2019-03-25  7:19     ` Peter Zijlstra
2019-03-25 15:58       ` Andi Kleen
2019-04-01  9:08       ` Wei Wang

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=20190323231543.GE18020@tassilo.jf.intel.com \
    --to=ak@linux.intel.com \
    --cc=kan.liang@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=like.xu@intel.com \
    --cc=like.xu@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=wei.w.wang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox