Re: Biweekly KVM Test report, kernel 0c7771... userspace 1223a0...
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Biweekly KVM Test report, kernel 0c7771... userspace 1223a0...
Xu, Jiajun wrote: Hi All, This is our Weekly KVM Testing Report against lastest kvm.git 0c77713470debc666a07dc40080d728272bb58b9 and kvm-userspace.git 1223a029b36b0d9e73af76bcc274bb770f814886. One New Issue: 1. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 This is the architectural performance counting msr which was enabled in 4f76231 (KVM: x86: Ignore reads to EVNTSEL MSRs). Amit, can you check if appropriate cpuid leaf 10 reporting will fix this? -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Biweekly KVM Test report, kernel 0c7771... userspace 1223a0...
On (Mon) Mar 30 2009 [10:07:58], Avi Kivity wrote: 1. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 This is the architectural performance counting msr which was enabled in 4f76231 (KVM: x86: Ignore reads to EVNTSEL MSRs). Amit, can you check if appropriate cpuid leaf 10 reporting will fix this? We already report 0s for the cpuid leaf 10; we need to report 0x3f in EBX for leaf 10 to denote events corresponding to the bits aren't available. I checked and it didn't help (we can't rely on guests to abide by cpuid flags) Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Biweekly KVM Test report, kernel 0c7771... userspace 1223a0...
Amit Shah wrote: On (Mon) Mar 30 2009 [10:07:58], Avi Kivity wrote: 1. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 This is the architectural performance counting msr which was enabled in 4f76231 (KVM: x86: Ignore reads to EVNTSEL MSRs). Amit, can you check if appropriate cpuid leaf 10 reporting will fix this? We already report 0s for the cpuid leaf 10; we need to report 0x3f in EBX for leaf 10 to denote events corresponding to the bits aren't available. I checked and it didn't help (we can't rely on guests to abide by cpuid flags) I see this in the code: /* * 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. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Biweekly KVM Test report, kernel 0c7771... userspace 1223a0...
On (Mon) Mar 30 2009 [16:55:05], Avi Kivity wrote: Amit Shah wrote: On (Mon) Mar 30 2009 [10:07:58], Avi Kivity wrote: 1. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 This is the architectural performance counting msr which was enabled in 4f76231 (KVM: x86: Ignore reads to EVNTSEL MSRs). Amit, can you check if appropriate cpuid leaf 10 reporting will fix this? We already report 0s for the cpuid leaf 10; we need to report 0x3f in EBX for leaf 10 to denote events corresponding to the bits aren't available. I checked and it didn't help (we can't rely on guests to abide by cpuid flags) I see this in the code: /* * 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. 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. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Biweekly KVM Test report, kernel 0c7771... userspace 1223a0...
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. 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. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Biweekly KVM Test report, kernel 0c7771... userspace 1223a0...
Hi All, This is our Weekly KVM Testing Report against lastest kvm.git 0c77713470debc666a07dc40080d728272bb58b9 and kvm-userspace.git 1223a029b36b0d9e73af76bcc274bb770f814886. One New Issue: 1. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 Five Old Issues: 1. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 2. failure to migrate guests with more than 4GB of RAM https://sourceforge.net/tracker/index.php?func=detailaid=1971512group_id=180599atid=893831 3. OpenSuse10.2 can not be installed http://sourceforge.net/tracker/index.php?func=detailaid=2088475group_id=180599atid=893831 4. Fail to Save Restore Guest https://sourceforge.net/tracker/?func=detailatid=893831aid=2175042group_id=180599 5. hotplug inexistent device will kill guest https://sourceforge.net/tracker/index.php?func=detailaid=2432316group_id=180599atid=893831 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G' Report Summary on IA32-pae Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 8 5 3 00 gtest 16 16 0 00 = control_panel 8 5 3 00 :KVM_256M_guest_PAE_gPAE 1 1 0 00 :KVM_linux_win_PAE_gPAE1 1 0 00 :KVM_two_winxp_PAE_gPAE1 1 0 00 :KVM_four_sguest_PAE_gPA 1 0 1 00 :KVM_1500M_guest_PAE_gPA 1 1 0 00 :KVM_LM_Continuity_PAE_g 1 0 1 00 :KVM_LM_SMP_PAE_gPAE 1 1 0 00 :KVM_SR_Continuity_PAE_g 1 0 1 00 gtest 16 16 0 00 :ltp_nightly_PAE_gPAE 1 1 0 00 :boot_up_acpi_PAE_gPAE 1 1 0 00 :boot_up_acpi_xp_PAE_gPA 1 1 0 00 :boot_up_vista_PAE_gPAE1 1 0 00 :reboot_xp_PAE_gPAE1 1 0 00 :boot_base_kernel_PAE_gP 1 1 0 00 :boot_up_acpi_win2k3_PAE 1 1 0 00 :boot_smp_acpi_win2k3_PA 1 1 0 00 :boot_smp_acpi_win2k_PAE 1 1 0 00 :boot_up_win2008_PAE_gPA 1 1 0 00 :boot_up_acpi_win2k_PAE_ 1 1 0 00 :boot_smp_acpi_xp_PAE_gP 1 1 0 00 :boot_up_noacpi_win2k_PA 1 1 0 00 :boot_smp_vista_PAE_gPAE 1 1 0 00 :boot_smp_win2008_PAE_gP 1 1 0 00 :kb_nightly_PAE_gPAE 1 1 0 00 = Total 24 21 3 00 Report Summary on IA32e Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 17 9 8 00 gtest 23 23 0 00 = control_panel 17 9 8 00 :KVM_4G_guest_64_g32e 1 1 0 00 :KVM_four_sguest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e1 0 1 00 :KVM_linux_win_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_gPAE1 0 1 00 :KVM_SR_Continuity_64_gP 1 0 1 00 :KVM_four_sguest_64_g32e 1 1 0 00 :KVM_four_dguest_64_gPAE 1 1 0 00 :KVM_SR_SMP_64_gPAE1 0 1 00 :KVM_LM_Continuity_64_g3 1 0 1 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_LM_Continuity_64_gP 1 1 0 00 :KVM_1500M_guest_64_g32e 1 0 1 00 :KVM_SR_Continuity_64_g3 1 0
