On 02/28/2012 07:36 PM, David Ahern wrote: > On 2/28/12 10:24 AM, Avi Kivity wrote: >> On 02/28/2012 05:55 PM, Joerg Roedel wrote: >>> >>> __init int amd_pmu_init(void) >>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c >>> index 5fa553b..773fee2 100644 >>> --- a/arch/x86/kvm/svm.c >>> +++ b/arch/x86/kvm/svm.c >>> @@ -29,6 +29,7 @@ >>> #include<linux/ftrace_event.h> >>> #include<linux/slab.h> >>> >>> +#include<asm/perf_event.h> >>> #include<asm/tlbflush.h> >>> #include<asm/desc.h> >>> #include<asm/kvm_para.h> >>> @@ -575,6 +576,8 @@ static void svm_hardware_disable(void *garbage) >>> wrmsrl(MSR_AMD64_TSC_RATIO, TSC_RATIO_DEFAULT); >>> >>> cpu_svm_disable(); >>> + >>> + x86_pmu_disable_virt(); >>> } >>> >>> static int svm_hardware_enable(void *garbage) >>> @@ -622,6 +625,8 @@ static int svm_hardware_enable(void *garbage) >>> >>> svm_init_erratum_383(); >>> >>> + x86_pmu_enable_virt(); >>> + >>> return 0; >>> } >>> >> >> These should go into x86.c. If the functions later gain meaning on >> Intel, we want them to be called (and nothing in the name suggests >> they're AMD specific). >> > > I was to suggest the reverse: since this patch addesses an AMD bug, > why not push those functions into perf_event_amd.c and make them > dependent on CONFIG_CPU_SUP_AMD as well. It depends on which direction you expect the code to grow. These hooks seem reasonable, so I think they should be generic. -- error compiling committee.c: too many arguments to function -- 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
