On 06/10/2015 01:05 PM, Joerg Roedel wrote: > On Wed, Jun 10, 2015 at 11:43:20AM -0500, Wei Huang wrote: >> On 06/10/2015 05:12 AM, Joerg Roedel wrote: >>> On Fri, Jun 05, 2015 at 01:20:14AM -0400, Wei Huang wrote: >>>> + >>>> + struct kvm_pmu_ops *(*get_pmu_ops)(void); >>> >>> Can't you just set kvm_pmu_ops in svm.c and vmx.c and save this >>> call-back? Besides that the patch looks good. >> Hi Joerg, >> >> Thanks for your review. How about setting up kvm_pmu_ops in >> .hardware_setup function of VMX and SVM? More specifically: >> >> 1) EXPORT_SYMBOL_GPL(kvm_pmu_ops) from pmu.c file; >> 2) In vmx.c, set "kvm_pmu_ops = &intel_pmu_ops" in hardware_setup(); >> 3) In svm.c, set "kvm_pmu_ops = &amd_pmu_ops" in svm_hardware_setup(). >> >> With that, we can get rid of the call-back. > > Okay, just had a look at how this works with kvm_x86_ops, because my > suggestion needs the EXPORT_SYMBOL_GPL(kvm_pmu_ops), which is better > also avoided. > > So how about putting the pmu-ops directly into the kvm_x86_ops as a > (const) member, I like this idea better. Here is the (expanded) design: 1) add const "struct kvm_pmu_ops *pmu_ops" to kvm_x86_ops; 2) In VMX, "vmx_x86_ops.pmu_ops = &intel_pmu_ops"; 3) In SVM, "svm_x86_ops.pmu_ops = &amd_pmu_ops". Common kvm_pmu_xxxx functions (in pmu.c) will change accordingly afterwards. If no objection, I will do this way. or alternativly as an additional parameter to kvm_init? > This still saves us the access functions. Passing pmu-ops to kvm_init() implies that we have to change the public API (adding a new parameter) to kvm_init, which will affect many architectures. I will try to avoid it unless have to. > > > Joerg > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
