From: Like Xu <like.xu@linux.intel.com>
To: Andi Kleen <ak@linux.intel.com>, Peter Zijlstra <peterz@infradead.org>
Cc: 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: Mon, 25 Mar 2019 14:07:17 +0800 [thread overview]
Message-ID: <0559a810-c0e6-16f6-fa15-7baec707a2ad@linux.intel.com> (raw)
In-Reply-To: <20190323231543.GE18020@tassilo.jf.intel.com>
On 2019/3/24 7:15, Andi Kleen wrote:
>>> 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
>
I agree this version doesn't seem to keep an eye on host perf event
constraints deliberately:
1. Based on my limited knowledge, assuming the model number means hwc->idx.
2. The guest event constraints would be constructed into
hwc->config_base value which is pmc->eventsel and pmu->fixed_ctr_ctrl
from KVM point of view.
3. The guest PMU has same semantic model on virt hardware limitation as
the host does with real PMU (related CPUID/PERF_MSR expose this part of
information to guest).
3. Guest perf scheduler would make sure the guest event constraints
could dance with right guest model number.
4. vPMU would make sure the guest vPMC get the right guest model number
by hard-code EVENT_PINNED or just fail with creation.
5. This patch directly apply the guest hwc->config_base value to host
assigned hardware without consent from host perf(a bit deceptive but
practical for reducing the number of reprogram calls).
=== OR ====
If we insist on passing guest event constraints to host perf,
this proposal may need the following changes:
Because the guest configuration of hwc->config_base mostly only toggles
the enable bit of eventsel or fixctrl,it is not necessary to do
reprogram_counter because it's serving the same guest perf event.
The event creation is only needed when guest writes a complete new value
to eventsel or fixctrl.Codes for guest MSR_P6_EVNTSEL0 trap for example
may be modified to be like this:
u64 diff = pmc->eventsel ^ data;
if (intel_pmc_is_assigned(pmc)
&& diff != ARCH_PERFMON_EVENTSEL_ENABLE) {
intel_pmu_save_guest_pmc(pmu, pmc->idx);
intel_pmc_stop_counter(pmc);
}
reprogram_gp_counter(pmc, data);
Does this seem to satisfy our needs?
It makes everything easier to correct me if I'm wrong.
next prev parent reply other threads:[~2019-03-25 6:07 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
2019-03-25 6:07 ` Like Xu [this message]
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=0559a810-c0e6-16f6-fa15-7baec707a2ad@linux.intel.com \
--to=like.xu@linux.intel.com \
--cc=ak@linux.intel.com \
--cc=kan.liang@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=like.xu@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;
as well as URLs for NNTP newsgroup(s).