From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Huang Subject: Re: [RFC] vPMU support for AMD system Date: Thu, 02 Oct 2014 09:15:22 -0500 Message-ID: <542D5DFA.7070800@redhat.com> References: <542B61DA.3070307@redhat.com> <20141002135058.GA28737@potion.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: gleb@kernel.org, pbonzini@redhat.com, KVM To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Return-path: Received: from mx1.redhat.com ([209.132.183.28]:12074 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751857AbaJBOP0 (ORCPT ); Thu, 2 Oct 2014 10:15:26 -0400 In-Reply-To: <20141002135058.GA28737@potion.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: > > (if-else forest is daunting.) > >> I think this approach is quite acceptable, except that there will be many >> if-else in the code. Not clean enough. >> >> (b) Convert intel-pmu.c => vmx.c and convert amd-pmu.c => svm.c >> * PMU function pointers will be created in kvm_x86_ops; >> * The entry functions will be created inside vmx.c and svm.c respectively; > > I would be nicer to keep them in separate files and link to vmx/svm. > >> * There might be common functions defined in pmu.c. >> >> This design is viable too. But to be honest, it is a bit messy compared with >> (a). > > This makes sense as we will use only vmx+intel_pmu and svm+amd_pmu, so > we'd have less code loaded in both cases. > > I consider design (c) strictly better than the current one (2): > (c) keep {intel,amd}-pmu.c and introduce pmu.[hc] that joins duplicate > functions and wraps kvm_pmu_ops Thanks for the suggestion. I will take this into consideration. Your suggestion is similar to existing svm.c/vmx.c/x86.c, which split distinct functions in vmx.c/svm.c; but in the meanwhile merging them in x86.c for common code. > > And if we decide to move VMX/SVM related code into their respective > modules, we won't have to change callers. > Yes.