On Thu, Apr 05, 2012 at 03:48:51PM +0300, Avi Kivity wrote: > On 04/05/2012 03:37 PM, Gleb Natapov wrote: > > On Thu, Apr 05, 2012 at 03:27:18PM +0300, Avi Kivity wrote: > > > On 04/04/2012 01:29 PM, Gleb Natapov wrote: > > > > > > > > > > > ok. seems to be. will move over to perf as its working fine inside guest. > > > > > > > > > Good riddance IMO. I managed to run it on a guest (but not on my > > > > host!). The thing is buggy. It does not use global ctrl MSR to enable > > > > counters and kvm has all of them disabled by default. I didn't find what > > > > value this MSR should have after reset, so this may be either kvm bug or > > > > real BIOSes enable all counters in global ctrl MSR for PMUv1 > > > > compatibility. Doing "wrmsr 0x38f 0x70000000f" solves this problem. The > > > > second problem is that oprofile reprogram PMU counters without > > > > disabling them first and this is explicitly prohibited by Intel SDM. > > > > The patch below solve that, but oprofile is the one who should be fixed. > > > > > > Both should be fixed, there may be other profilers affected. > > > > > Global ctrl msr issue I need to investigate further, but second one is > > bug that should be fixed in oprofile. Intel spec clearly says: > > > > EN (Enable Counters) Flag (bit 22) — When set, performance counting > > is enabled in the corresponding performance-monitoring counter; when > > clear, the corresponding counter is disabled. The event logic unit > > for a UMASK must be disabled by setting IA32_PERFEVTSELx[bit 22] = 0, > > before writing to IA32_PMCx. > > > > I suspect that on real HW they got wrong result too. It simply subtly > > wrong, so it is not as noticeable as with kvm. > > > > First, there is the standard Linus rant to never break userspace (and We broke nothing. Oprofile is broken and never could have worked according to Intel spec. (It didn't manage to get any result from it on real CPU, but may be this is unrelated). > for us a guest kernel is userspace). Second, the Intel rule may have > been added later (as preparation for a change in behaviour), so it may > actually work correctly on older hardware. > May be (the rule is specified for MPUv1 BTW), but we emulate newer HW, the one that spec describes and we report this in cpuid leaf 10. I highly doubt Intel would change CPU in a way that may make old software to work incorrectly on newer cpus. -- Gleb. -- 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
