[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <286AC319A985734F985F78AFA26841F73984BB8C@shsmsx102.ccr.corp.intel.com>
Date: Sun, 14 Oct 2018 13:42:24 +0000
From: "Wang, Wei W" <wei.w.wang@...el.com>
To: "Wang, Wei W" <wei.w.wang@...el.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Andi Kleen <ak@...ux.intel.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"peterz@...radead.org" <peterz@...radead.org>,
"mingo@...hat.com" <mingo@...hat.com>,
"rkrcmar@...hat.com" <rkrcmar@...hat.com>,
"Xu, Like" <like.xu@...el.com>
Subject: RE: [PATCH v1] KVM/x86/vPMU: Guest PMI Optimization
On Sunday, October 14, 2018 8:41 PM, Wei Wang wrote:
> Here is the plan I have in mind:
> #1 Creates a host perf event on the guest's first bit-setting to
> MSR_CORE_PERF_GLOBAL_CTRL; Meanwhile, disable the intercept of guest
> access to this perf counter related MSRs (i.e. config_base and event_base).
> #2 When the vCPU is sched in,
> #2.1 make the MSRs of the perf counters (assigned to the guest in
> #1) interceptible, so that guest accesses to such a counter is captured, and
> marked it "used", and disable the intercept again;
> #2.2 also check if there is any counter that wasn't "used" in the last vCPU
> time slice, if there is, release that counter and the perf event.
Just thought of an issue with passing through config_base and event base - the guest's view of the perf counter is possible to be different from the one assigned by the host, which results in guest using a different config_base and event_base. So we would still need keep those MSRs being intercepted by the host. The remaining part (the lazy allocation and release of the host perf event) can still work.
Best,
Wei
Powered by blists - more mailing lists