From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v7 12/19] x86/VPMU: Initialize PMU for PV guests Date: Fri, 06 Jun 2014 16:49:14 -0400 Message-ID: <5392294A.4060206@oracle.com> References: <1402076415-26475-1-git-send-email-boris.ostrovsky@oracle.com> <1402076415-26475-13-git-send-email-boris.ostrovsky@oracle.com> <539220D5.3010305@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <539220D5.3010305@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: kevin.tian@intel.com, keir@xen.org, JBeulich@suse.com, jun.nakajima@intel.com, tim@xen.org, dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org, suravee.suthikulpanit@amd.com List-Id: xen-devel@lists.xenproject.org On 06/06/2014 04:13 PM, Andrew Cooper wrote: > On 06/06/14 18:40, Boris Ostrovsky wrote: >> Code for initializing/tearing down PMU for PV guests > PVH guests judging by the content? PV and PVH actually. > >> Signed-off-by: Boris Ostrovsky >> Acked-by: Kevin Tian >> Reviewed-by: Dietmar Hahn >> Tested-by: Dietmar Hahn >> --- >> xen/arch/x86/hvm/hvm.c | 3 +- >> xen/arch/x86/hvm/svm/svm.c | 8 +++- >> xen/arch/x86/hvm/svm/vpmu.c | 37 +++++++++++------- >> xen/arch/x86/hvm/vmx/vmx.c | 9 ++++- >> xen/arch/x86/hvm/vmx/vpmu_core2.c | 67 ++++++++++++++++++++++---------- >> xen/arch/x86/hvm/vpmu.c | 82 ++++++++++++++++++++++++++++++++++++++- >> xen/common/event_channel.c | 1 + >> xen/include/asm-x86/hvm/vpmu.h | 1 + >> xen/include/public/pmu.h | 2 + >> xen/include/public/xen.h | 1 + >> 10 files changed, 169 insertions(+), 42 deletions(-) >> >> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c >> index d2190be..fab54ff 100644 >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -4031,7 +4031,8 @@ static hvm_hypercall_t *const pvh_hypercall64_table[NR_hypercalls] = { >> [ __HYPERVISOR_physdev_op ] = (hvm_hypercall_t *)hvm_physdev_op, >> HYPERCALL(hvm_op), >> HYPERCALL(sysctl), >> - HYPERCALL(domctl) >> + HYPERCALL(domctl), >> + HYPERCALL(xenpmu_op) >> }; >> >> int hvm_do_hypercall(struct cpu_user_regs *regs) >> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c >> index 870e4ee..7358626 100644 >> --- a/xen/arch/x86/hvm/svm/svm.c >> +++ b/xen/arch/x86/hvm/svm/svm.c >> @@ -1150,7 +1150,9 @@ static int svm_vcpu_initialise(struct vcpu *v) >> return rc; >> } >> >> - vpmu_initialise(v); >> + /* PVH's VPMU is initialized via hypercall */ >> + if ( is_hvm_domain(v->domain) ) >> + vpmu_initialise(v); >> > With the wish to merge HVM and PVH, is this wise? What does > hypercall-based setup gain us over MSR based setup, given that we have > to provide the MSR access to HVM guests anyway? Interrupts. We have to go via event channel and the handler for VIRQ_PMU in Linux wants to access MSRs via shared page (i.e. not do actual MSR access). That page is set up duting the hypercall. Once we add APIC support for PVH I think most of PMU support will follow HVM code. But for now we have to do it separately. -boris