On (Mon) Mar 30 2009 [18:02:16], Avi Kivity wrote: > Amit Shah wrote: >>> >>>> /* >>>> * Check whether the Architectural PerfMon supports >>>> * Unhalted Core Cycles Event or not. >>>> * NOTE: Corresponding bit = 0 in ebx indicates event present. >>>> */ >>>> cpuid(10, &(eax.full), &ebx, &unused, &unused); >>>> if ((eax.split.mask_length < >>>> (ARCH_PERFMON_UNHALTED_CORE_CYCLES_INDEX+1)) || >>>> (ebx & ARCH_PERFMON_UNHALTED_CORE_CYCLES_PRESENT)) >>>> return 0; >>>> >>>> >>> So I think it can be done. >>> >> >> Only if the guest kernel (or module accessing those registers) look at >> the cpuid output, right? I checked this for the Kaspersky AV on Windows, >> the crash bug I was solving and that program doesn't seem to check >> cpuid. >> > > The only way to solve all possible cases is to implement the performance > counters MSRs. That's not going to happen in a hurry, we're looking at > making the known cases work. Looks like it does get solved... >> RHEL 5.3 is based on 2.6.18 and this patch appears to have entered in >> 2.6.21. I saw this on 5.3 as well. >> > > The snippet I quoted came from RHEL 5.3. It checks cpuid so we should > be able to make it fail gracefully. Our default CPU is qemu64, which has cpuid till level 2. Trying with -cpu core2duo, this doesn't happen (even without setting EBX to the 0x3f value) on both, RHEL 5.3 and Win+Kaspersky guests. qemu64 loosely models some AMD CPU type. I guess we can update it to expose cpuid levels upto 10 (and leave xlevel to the current value). That should take care of this. Amit -- 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
