* KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue @ 2008-02-25 8:41 Zhao, Yunfeng 2008-02-25 9:31 ` Yang, Sheng 0 siblings, 1 reply; 10+ messages in thread From: Zhao, Yunfeng @ 2008-02-25 8:41 UTC (permalink / raw) To: kvm-devel Hi, all, This is today's KVM test result against kvm.git 81e4400b4df4e597a81c19c1161aa03c73613710 and kvm-userspace.git 08385e49dcff3585f597870af67301d7659a1ecb. One new issue has been found in today's testing: 1. fc5/fc6/rhel5u1 no-acpi up guests can't boot on pae host https://sourceforge.net/tracker/index.php?func=detail&aid=1901208&group_ id=180599&atid=893831 Five old issues: 2. Fails to save/restore guests https://sourceforge.net/tracker/index.php?func=detail&aid=1824525&group_ id=180599&atid=893831 3. smp windows installer crashes while rebooting https://sourceforge.net/tracker/index.php?func=detail&aid=1877875&group_ id=180599&atid=893831 4. Timer of guest is inaccurate https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1826080&gro up_id=180599 5. Installer of 64bit vista guest will pause for ten minutes after reboot https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1836905&gro up_id=180599 6. Cannot boot 32bit smp RHEL5.1 guest with nic on 64bit host https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1812043&gro up_id=180599 Test environment ================================================ Platform Woodcrest CPU 4 Memory size 8G' Details ================================================ IA32-pae: 1. boot guest with 256M memory PASS 2. boot two windows xp guest PASS 3. boot 4 same guest in parallel PASS 4. boot linux and windows guest in parallel PASS 5. boot guest with 1500M memory PASS 6. boot windows 2003 with ACPI enabled PASS 7. boot Windows xp with ACPI enabled PASS 8. boot Windows 2000 without ACPI PASS 9. kernel build on SMP linux guest PASS 10. LTP on SMP linux guest PASS 11. boot base kernel linux PASS 12. save/restore 32-bit HVM guests PASS 13. live migration 32-bit HVM guests PASS 14. boot SMP Windows xp with ACPI enabled PASS 15. boot SMP Windows 2003 with ACPI enabled PASS 16. boot SMP Windows 2000 with ACPI enabled PASS ================================================ IA32e: 1. boot four 32-bit guest in parallel PASS 2. boot four 64-bit guest in parallel PASS 3. boot 4G 64-bit guest PASS 4. boot 4G pae guest PASS 5. boot 32-bit linux and 32 bit windows guest in parallel PASS 6. boot 32-bit guest with 1500M memory PASS 7. boot 64-bit guest with 1500M memory PASS 8. boot 32-bit guest with 256M memory PASS 9. boot 64-bit guest with 256M memory PASS 10. boot two 32-bit windows xp in parallel PASS 11. boot four 32-bit different guest in para PASS 12. save/restore 64-bit linux guests PASS 13. save/restore 32-bit linux guests PASS 14. boot 32-bit SMP windows 2003 with ACPI enabled PASS 15. boot 32-bit SMP Windows 2000 with ACPI enabled PASS 16. boot 32-bit SMP Windows xp with ACPI enabled PASS 17. boot 32-bit Windows 2000 without ACPI PASS 18. boot 64-bit Windows xp with ACPI enabled PASS 19. boot 32-bit Windows xp without ACPI PASS 20. boot 64-bit vista PASS 21. kernel build in 32-bit linux guest OS PASS 22. kernel build in 64-bit linux guest OS PASS 23. LTP on SMP 32-bit linux guest OS PASS 24. LTP on SMP 64-bit linux guest OS PASS 25. boot 64-bit guests with ACPI enabled PASS 26. boot 32-bit x-server PASS 27. boot 64-bit SMP windows XP with ACPI enabled PASS 28. boot 64-bit SMP windows 2003 with ACPI enabled PASS 29. live migration 64bit linux guests PASS 30. live migration 32bit linux guests PASS Report Summary on IA32-pae Summary Test Report of Last Session ===================================================================== Total Pass Fail NoResult Crash ===================================================================== control_panel 6 5 1 0 0 Restart 2 2 0 0 0 gtest 14 13 1 0 0 ===================================================================== control_panel 6 5 1 0 0 :KVM_LM_PAE_gPAE 1 0 1 0 0 :KVM_four_sguest_PAE_gPA 1 1 0 0 0 :KVM_256M_guest_PAE_gPAE 1 1 0 0 0 :KVM_linux_win_PAE_gPAE 1 1 0 0 0 :KVM_1500M_guest_PAE_gPA 1 1 0 0 0 :KVM_two_winxp_PAE_gPAE 1 1 0 0 0 Restart 2 2 0 0 0 :GuestPAE_PAE_g64 1 1 0 0 0 :BootTo32pae_PAE_g64 1 1 0 0 0 gtest 14 13 1 0 0 :ltp_nightly_PAE_gPAE 1 1 0 0 0 :boot_up_acpi_PAE_gPAE 1 1 0 0 0 :reboot_xp_PAE_gPAE 1 1 0 0 0 :boot_up_vista_PAE_gPAE 1 1 0 0 0 :boot_up_acpi_xp_PAE_gPA 1 1 0 0 0 :boot_up_acpi_win2k3_PAE 1 1 0 0 0 :boot_base_kernel_PAE_gP 1 1 0 0 0 :boot_smp_acpi_win2k3_PA 1 1 0 0 0 :boot_smp_acpi_win2k_PAE 1 1 0 0 0 :boot_up_acpi_win2k_PAE_ 1 1 0 0 0 :boot_smp_acpi_xp_PAE_gP 1 1 0 0 0 :boot_up_noacpi_win2k_PA 1 1 0 0 0 :bootx_PAE_gPAE 1 0 1 0 0 :kb_nightly_PAE_gPAE 1 1 0 0 0 ===================================================================== Total 22 20 2 0 0 Report Summary on IA32e Summary Test Report of Last Session ===================================================================== Total Pass Fail NoResult Crash ===================================================================== control_panel 13 10 2 1 0 Restart 3 3 0 0 0 gtest 24 24 0 0 0 ===================================================================== control_panel 13 10 2 1 0 :KVM_LM_64_g64 1 0 1 0 0 :KVM_four_sguest_64_gPAE 1 1 0 0 0 :KVM_4G_guest_64_g64 1 1 0 0 0 :KVM_four_sguest_64_g64 1 1 0 0 0 :KVM_linux_win_64_gPAE 1 0 1 0 0 :KVM_1500M_guest_64_gPAE 1 1 0 0 0 :KVM_LM_64_gPAE 1 0 0 1 0 :KVM_256M_guest_64_g64 1 1 0 0 0 :KVM_4G_guest_64_gPAE 1 1 0 0 0 :KVM_1500M_guest_64_g64 1 1 0 0 0 :KVM_256M_guest_64_gPAE 1 1 0 0 0 :KVM_two_winxp_64_gPAE 1 1 0 0 0 :KVM_four_dguest_64_gPAE 1 1 0 0 0 Restart 3 3 0 0 0 :GuestPAE_64_gPAE 1 1 0 0 0 :BootTo64_64_gPAE 1 1 0 0 0 :Guest64_64_gPAE 1 1 0 0 0 gtest 24 24 0 0 0 :boot_up_acpi_64_gPAE 1 1 0 0 0 :boot_up_noacpi_xp_64_gP 1 1 0 0 0 :boot_smp_acpi_xp_64_g64 1 1 0 0 0 :boot_base_kernel_64_gPA 1 1 0 0 0 :boot_smp_acpi_win2k3_64 1 1 0 0 0 :boot_smp_acpi_win2k_64_ 1 1 0 0 0 :boot_base_kernel_64_g64 1 1 0 0 0 :bootx_64_gPAE 1 1 0 0 0 :kb_nightly_64_gPAE 1 1 0 0 0 :ltp_nightly_64_g64 1 1 0 0 0 :boot_up_acpi_64_g64 1 1 0 0 0 :boot_up_noacpi_win2k_64 1 1 0 0 0 :boot_smp_acpi_xp_64_gPA 1 1 0 0 0 :boot_up_acpi_win2k3_64_ 1 1 0 0 0 :reboot_xp_64_gPAE 1 1 0 0 0 :bootx_64_g64 1 1 0 0 0 :reboot_xp_64_g64 1 1 0 0 0 :boot_up_vista_64_g64 1 1 0 0 0 :boot_up_acpi_xp_64_g64 1 1 0 0 0 :boot_up_vista_64_gPAE 1 1 0 0 0 :ltp_nightly_64_gPAE 1 1 0 0 0 :boot_smp_acpi_win2k3_64 1 1 0 0 0 :boot_up_noacpi_win2k3_6 1 1 0 0 0 :kb_nightly_64_g64 1 1 0 0 0 ===================================================================== Total 40 37 2 1 0 Best wishes, Yunfeng ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue 2008-02-25 8:41 KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue Zhao, Yunfeng @ 2008-02-25 9:31 ` Yang, Sheng 2008-02-25 9:34 ` Avi Kivity 0 siblings, 1 reply; 10+ messages in thread From: Yang, Sheng @ 2008-02-25 9:31 UTC (permalink / raw) To: kvm-devel On Monday 25 February 2008 16:41:25 Zhao, Yunfeng wrote: > Hi, all, > > This is today's KVM test result against kvm.git > 81e4400b4df4e597a81c19c1161aa03c73613710 and kvm-userspace.git > 08385e49dcff3585f597870af67301d7659a1ecb. > > One new issue has been found in today's testing: > 1. fc5/fc6/rhel5u1 no-acpi up guests can't boot on pae host > https://sourceforge.net/tracker/index.php?func=detail&aid=1901208&group_ > id=180599&atid=893831 A quick bisect shows that the problem caused by "kvm: qemu: fix host_cpuid() on x86_64". > > Five old issues: > 2. Fails to save/restore guests > https://sourceforge.net/tracker/index.php?func=detail&aid=1824525&group_ > id=180599&atid=893831 > 3. smp windows installer crashes while rebooting > https://sourceforge.net/tracker/index.php?func=detail&aid=1877875&group_ > id=180599&atid=893831 > 4. Timer of guest is inaccurate > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1826080&gro > up_id=180599 > 5. Installer of 64bit vista guest will pause for ten minutes after > reboot > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1836905&gro > up_id=180599 > 6. Cannot boot 32bit smp RHEL5.1 guest with nic on 64bit host > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1812043&gro > up_id=180599 Should be fixed now. Wait for your result tomorrow. :) > > Test environment > ================================================ > > Platform Woodcrest > CPU 4 > Memory size 8G' > > > Details > ================================================ > > IA32-pae: > > 1. boot guest with 256M memory PASS > 2. boot two windows xp guest PASS > 3. boot 4 same guest in parallel PASS > 4. boot linux and windows guest in parallel PASS > 5. boot guest with 1500M memory PASS > 6. boot windows 2003 with ACPI enabled PASS > 7. boot Windows xp with ACPI enabled PASS > 8. boot Windows 2000 without ACPI PASS > 9. kernel build on SMP linux guest PASS > 10. LTP on SMP linux guest PASS > 11. boot base kernel linux > PASS > 12. save/restore 32-bit HVM guests PASS > 13. live migration 32-bit HVM guests PASS > 14. boot SMP Windows xp with ACPI enabled PASS > 15. boot SMP Windows 2003 with ACPI enabled PASS > 16. boot SMP Windows 2000 with ACPI enabled PASS > > ================================================ > > IA32e: > > 1. boot four 32-bit guest in parallel > PASS > 2. boot four 64-bit guest in parallel > PASS > 3. boot 4G 64-bit guest > PASS > 4. boot 4G pae guest > PASS > 5. boot 32-bit linux and 32 bit windows guest in parallel PASS > 6. boot 32-bit guest with 1500M memory PASS > 7. boot 64-bit guest with 1500M memory PASS > 8. boot 32-bit guest with 256M memory PASS > 9. boot 64-bit guest with 256M memory PASS > 10. boot two 32-bit windows xp in parallel > PASS > 11. boot four 32-bit different guest in para > PASS > 12. save/restore 64-bit linux guests > PASS > 13. save/restore 32-bit linux guests > PASS > 14. boot 32-bit SMP windows 2003 with ACPI enabled PASS > 15. boot 32-bit SMP Windows 2000 with ACPI enabled PASS > 16. boot 32-bit SMP Windows xp with ACPI enabled PASS > 17. boot 32-bit Windows 2000 without ACPI PASS > 18. boot 64-bit Windows xp with ACPI enabled PASS > 19. boot 32-bit Windows xp without ACPI PASS > 20. boot 64-bit vista > PASS > 21. kernel build in 32-bit linux guest OS > PASS > 22. kernel build in 64-bit linux guest OS > PASS > 23. LTP on SMP 32-bit linux guest OS PASS > 24. LTP on SMP 64-bit linux guest OS PASS > 25. boot 64-bit guests with ACPI enabled > PASS > 26. boot 32-bit x-server > PASS > 27. boot 64-bit SMP windows XP with ACPI enabled PASS > 28. boot 64-bit SMP windows 2003 with ACPI enabled PASS > 29. live migration 64bit linux guests > PASS > 30. live migration 32bit linux guests > PASS > > > Report Summary on IA32-pae > > Summary Test Report of Last Session > ===================================================================== > Total Pass Fail NoResult Crash > ===================================================================== > control_panel 6 5 1 0 0 > Restart 2 2 0 0 0 > gtest 14 13 1 0 0 > ===================================================================== > control_panel 6 5 1 0 0 > > :KVM_LM_PAE_gPAE 1 0 1 0 0 > :KVM_four_sguest_PAE_gPA 1 1 0 0 0 > :KVM_256M_guest_PAE_gPAE 1 1 0 0 0 > :KVM_linux_win_PAE_gPAE 1 1 0 0 0 > :KVM_1500M_guest_PAE_gPA 1 1 0 0 0 > :KVM_two_winxp_PAE_gPAE 1 1 0 0 0 > > Restart 2 2 0 0 0 > > :GuestPAE_PAE_g64 1 1 0 0 0 > :BootTo32pae_PAE_g64 1 1 0 0 0 > > gtest 14 13 1 0 0 > > :ltp_nightly_PAE_gPAE 1 1 0 0 0 > :boot_up_acpi_PAE_gPAE 1 1 0 0 0 > :reboot_xp_PAE_gPAE 1 1 0 0 0 > :boot_up_vista_PAE_gPAE 1 1 0 0 0 > :boot_up_acpi_xp_PAE_gPA 1 1 0 0 0 > :boot_up_acpi_win2k3_PAE 1 1 0 0 0 > :boot_base_kernel_PAE_gP 1 1 0 0 0 > :boot_smp_acpi_win2k3_PA 1 1 0 0 0 > :boot_smp_acpi_win2k_PAE 1 1 0 0 0 > :boot_up_acpi_win2k_PAE_ 1 1 0 0 0 > :boot_smp_acpi_xp_PAE_gP 1 1 0 0 0 > :boot_up_noacpi_win2k_PA 1 1 0 0 0 > :bootx_PAE_gPAE 1 0 1 0 0 > :kb_nightly_PAE_gPAE 1 1 0 0 0 > > ===================================================================== > Total 22 20 2 0 0 > > Report Summary on IA32e > > Summary Test Report of Last Session > ===================================================================== > Total Pass Fail NoResult Crash > ===================================================================== > control_panel 13 10 2 1 0 > Restart 3 3 0 0 0 > gtest 24 24 0 0 0 > ===================================================================== > control_panel 13 10 2 1 0 > > :KVM_LM_64_g64 1 0 1 0 0 > :KVM_four_sguest_64_gPAE 1 1 0 0 0 > :KVM_4G_guest_64_g64 1 1 0 0 0 > :KVM_four_sguest_64_g64 1 1 0 0 0 > :KVM_linux_win_64_gPAE 1 0 1 0 0 > :KVM_1500M_guest_64_gPAE 1 1 0 0 0 > :KVM_LM_64_gPAE 1 0 0 1 0 > :KVM_256M_guest_64_g64 1 1 0 0 0 > :KVM_4G_guest_64_gPAE 1 1 0 0 0 > :KVM_1500M_guest_64_g64 1 1 0 0 0 > :KVM_256M_guest_64_gPAE 1 1 0 0 0 > :KVM_two_winxp_64_gPAE 1 1 0 0 0 > :KVM_four_dguest_64_gPAE 1 1 0 0 0 > > Restart 3 3 0 0 0 > > :GuestPAE_64_gPAE 1 1 0 0 0 > :BootTo64_64_gPAE 1 1 0 0 0 > :Guest64_64_gPAE 1 1 0 0 0 > > gtest 24 24 0 0 0 > > :boot_up_acpi_64_gPAE 1 1 0 0 0 > :boot_up_noacpi_xp_64_gP 1 1 0 0 0 > :boot_smp_acpi_xp_64_g64 1 1 0 0 0 > :boot_base_kernel_64_gPA 1 1 0 0 0 > :boot_smp_acpi_win2k3_64 1 1 0 0 0 > :boot_smp_acpi_win2k_64_ 1 1 0 0 0 > :boot_base_kernel_64_g64 1 1 0 0 0 > :bootx_64_gPAE 1 1 0 0 0 > :kb_nightly_64_gPAE 1 1 0 0 0 > :ltp_nightly_64_g64 1 1 0 0 0 > :boot_up_acpi_64_g64 1 1 0 0 0 > :boot_up_noacpi_win2k_64 1 1 0 0 0 > :boot_smp_acpi_xp_64_gPA 1 1 0 0 0 > :boot_up_acpi_win2k3_64_ 1 1 0 0 0 > :reboot_xp_64_gPAE 1 1 0 0 0 > :bootx_64_g64 1 1 0 0 0 > :reboot_xp_64_g64 1 1 0 0 0 > :boot_up_vista_64_g64 1 1 0 0 0 > :boot_up_acpi_xp_64_g64 1 1 0 0 0 > :boot_up_vista_64_gPAE 1 1 0 0 0 > :ltp_nightly_64_gPAE 1 1 0 0 0 > :boot_smp_acpi_win2k3_64 1 1 0 0 0 > :boot_up_noacpi_win2k3_6 1 1 0 0 0 > :kb_nightly_64_g64 1 1 0 0 0 > > ===================================================================== > Total 40 37 2 1 0 > > Best wishes, > Yunfeng > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel -- Thanks Yang, Sheng ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue 2008-02-25 9:31 ` Yang, Sheng @ 2008-02-25 9:34 ` Avi Kivity 2008-02-25 10:28 ` Alexander Graf 0 siblings, 1 reply; 10+ messages in thread From: Avi Kivity @ 2008-02-25 9:34 UTC (permalink / raw) To: Yang, Sheng; +Cc: kvm-devel, Alexander Graf Yang, Sheng wrote: > On Monday 25 February 2008 16:41:25 Zhao, Yunfeng wrote: > >> Hi, all, >> >> This is today's KVM test result against kvm.git >> 81e4400b4df4e597a81c19c1161aa03c73613710 and kvm-userspace.git >> 08385e49dcff3585f597870af67301d7659a1ecb. >> >> One new issue has been found in today's testing: >> 1. fc5/fc6/rhel5u1 no-acpi up guests can't boot on pae host >> https://sourceforge.net/tracker/index.php?func=detail&aid=1901208&group_ >> id=180599&atid=893831 >> > > A quick bisect shows that the problem caused by "kvm: qemu: fix host_cpuid() > on x86_64". > Yeah, I just found this out the hard way (by trying to debug this -- silly me). The effects were that the "GenuineIntel" in cpuid identification was corrupted. I'm reverting that patch. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue 2008-02-25 9:34 ` Avi Kivity @ 2008-02-25 10:28 ` Alexander Graf 2008-02-25 10:45 ` Avi Kivity 0 siblings, 1 reply; 10+ messages in thread From: Alexander Graf @ 2008-02-25 10:28 UTC (permalink / raw) To: Avi Kivity; +Cc: kvm-devel [-- Attachment #1: Type: text/plain, Size: 1029 bytes --] On Feb 25, 2008, at 10:34 AM, Avi Kivity wrote: > Yang, Sheng wrote: >> On Monday 25 February 2008 16:41:25 Zhao, Yunfeng wrote: >> >>> Hi, all, >>> >>> This is today's KVM test result against kvm.git >>> 81e4400b4df4e597a81c19c1161aa03c73613710 and kvm-userspace.git >>> 08385e49dcff3585f597870af67301d7659a1ecb. >>> >>> One new issue has been found in today's testing: >>> 1. fc5/fc6/rhel5u1 no-acpi up guests can't boot on pae host >>> https://sourceforge.net/tracker/index.php?func=detail&aid=1901208&group_ >>> id=180599&atid=893831 >>> >> >> A quick bisect shows that the problem caused by "kvm: qemu: fix >> host_cpuid() >> on x86_64". >> > > Yeah, I just found this out the hard way (by trying to debug this -- > silly me). The effects were that the "GenuineIntel" in cpuid > identification was corrupted. Could you please execute this source on a computer that fails with the argument "0" (please compile with the same switches as qemu) and give me the results + disassembly? > > > I'm reverting that patch. [-- Attachment #2: test.c --] [-- Type: application/octet-stream, Size: 801 bytes --] #include <stdio.h> #define uint32_t unsigned int static void host_cpuid(uint32_t function, uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx) { uint32_t vec[4]; asm volatile("movl %%ebx, %%esi \n\t" "cpuid \n\t" "movl %%ebx, %1 \n\t" "movl %%esi, %%ebx" : "=a"(vec[0]), "=r"(vec[1]), "=c"(vec[2]), "=d"(vec[3]) : "0"(function) : "esi"); if (eax) *eax = vec[0]; if (ebx) *ebx = vec[1]; if (ecx) *ecx = vec[2]; if (edx) *edx = vec[3]; } int main(int argc, char **argv) { unsigned int a,b,c,d; host_cpuid(atoi(argv[1]), &a, &b, &c, &d); printf("%#x = %#x %#x %#x %#x\n", atoi(argv[1]), a, b, c, d); } [-- Attachment #3: Type: text/plain, Size: 228 bytes --] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ [-- Attachment #4: Type: text/plain, Size: 158 bytes --] _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue 2008-02-25 10:28 ` Alexander Graf @ 2008-02-25 10:45 ` Avi Kivity 2008-02-25 12:55 ` Alexander Graf 2008-02-25 17:37 ` [PATCH] fix CPUID handling Alexander Graf 0 siblings, 2 replies; 10+ messages in thread From: Avi Kivity @ 2008-02-25 10:45 UTC (permalink / raw) To: Alexander Graf; +Cc: kvm-devel Alexander Graf wrote: > > On Feb 25, 2008, at 10:34 AM, Avi Kivity wrote: > >> Yang, Sheng wrote: >>> On Monday 25 February 2008 16:41:25 Zhao, Yunfeng wrote: >>> >>>> Hi, all, >>>> >>>> This is today's KVM test result against kvm.git >>>> 81e4400b4df4e597a81c19c1161aa03c73613710 and kvm-userspace.git >>>> 08385e49dcff3585f597870af67301d7659a1ecb. >>>> >>>> One new issue has been found in today's testing: >>>> 1. fc5/fc6/rhel5u1 no-acpi up guests can't boot on pae host >>>> https://sourceforge.net/tracker/index.php?func=detail&aid=1901208&group_ >>>> >>>> id=180599&atid=893831 >>>> >>> >>> A quick bisect shows that the problem caused by "kvm: qemu: fix >>> host_cpuid() >>> on x86_64". >>> >> >> Yeah, I just found this out the hard way (by trying to debug this -- >> silly me). The effects were that the "GenuineIntel" in cpuid >> identification was corrupted. > > Could you please execute this source on a computer that fails with the > argument "0" (please compile with the same switches as qemu) and give > me the results + disassembly? 0000101c <host_cpuid>: 101c: 55 push %ebp 101d: 89 e5 mov %esp,%ebp 101f: 57 push %edi 1020: 56 push %esi 1021: 53 push %ebx 1022: 83 ec 3c sub $0x3c,%esp 1025: 89 55 d4 mov %edx,-0x2c(%ebp) 1028: 89 de mov %ebx,%esi 102a: 0f a2 cpuid 102c: 89 db mov %ebx,%ebx 102e: 89 f3 mov %esi,%ebx 1030: 89 d7 mov %edx,%edi 1032: 89 55 e4 mov %edx,-0x1c(%ebp) 1035: 8b 55 d4 mov -0x2c(%ebp),%edx 1038: 85 d2 test %edx,%edx 103a: 89 4d c4 mov %ecx,-0x3c(%ebp) 103d: 89 5d d0 mov %ebx,-0x30(%ebp) 1040: 89 45 d8 mov %eax,-0x28(%ebp) 1043: 89 5d dc mov %ebx,-0x24(%ebp) 1046: 89 4d e0 mov %ecx,-0x20(%ebp) 1049: 74 05 je 1050 <host_cpuid+0x34> 104b: 8b 55 d4 mov -0x2c(%ebp),%edx 104e: 89 02 mov %eax,(%edx) 1050: 8b 75 08 mov 0x8(%ebp),%esi 1053: 85 f6 test %esi,%esi 1055: 74 08 je 105f <host_cpuid+0x43> 1057: 8b 5d d0 mov -0x30(%ebp),%ebx 105a: 8b 4d 08 mov 0x8(%ebp),%ecx 105d: 89 19 mov %ebx,(%ecx) 105f: 8b 5d 0c mov 0xc(%ebp),%ebx 1062: 85 db test %ebx,%ebx 1064: 74 08 je 106e <host_cpuid+0x52> 1066: 8b 55 c4 mov -0x3c(%ebp),%edx 1069: 8b 45 0c mov 0xc(%ebp),%eax 106c: 89 10 mov %edx,(%eax) 106e: 8b 4d 10 mov 0x10(%ebp),%ecx 1071: 85 c9 test %ecx,%ecx 1073: 74 05 je 107a <host_cpuid+0x5e> 1075: 8b 4d 10 mov 0x10(%ebp),%ecx 1078: 89 39 mov %edi,(%ecx) 107a: 83 c4 3c add $0x3c,%esp 107d: 5b pop %ebx 107e: 5e pop %esi 107f: 5f pop %edi 1080: c9 leave 1081: c3 ret Looks like %ebx was chosen for %1. I also don't see where %eax is loaded. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue 2008-02-25 10:45 ` Avi Kivity @ 2008-02-25 12:55 ` Alexander Graf 2008-02-25 17:40 ` Avi Kivity 2008-02-25 17:37 ` [PATCH] fix CPUID handling Alexander Graf 1 sibling, 1 reply; 10+ messages in thread From: Alexander Graf @ 2008-02-25 12:55 UTC (permalink / raw) To: Avi Kivity; +Cc: kvm-devel [-- Attachment #1: Type: text/plain, Size: 4430 bytes --] On Feb 25, 2008, at 11:45 AM, Avi Kivity wrote: > Alexander Graf wrote: >> >> On Feb 25, 2008, at 10:34 AM, Avi Kivity wrote: >> >>> Yang, Sheng wrote: >>>> On Monday 25 February 2008 16:41:25 Zhao, Yunfeng wrote: >>>> >>>>> Hi, all, >>>>> >>>>> This is today's KVM test result against kvm.git >>>>> 81e4400b4df4e597a81c19c1161aa03c73613710 and kvm-userspace.git >>>>> 08385e49dcff3585f597870af67301d7659a1ecb. >>>>> >>>>> One new issue has been found in today's testing: >>>>> 1. fc5/fc6/rhel5u1 no-acpi up guests can't boot on pae host >>>>> https://sourceforge.net/tracker/index.php?func=detail&aid=1901208&group_ >>>>> >>>>> id=180599&atid=893831 >>>>> >>>> >>>> A quick bisect shows that the problem caused by "kvm: qemu: fix >>>> host_cpuid() >>>> on x86_64". >>>> >>> >>> Yeah, I just found this out the hard way (by trying to debug this -- >>> silly me). The effects were that the "GenuineIntel" in cpuid >>> identification was corrupted. >> >> Could you please execute this source on a computer that fails with >> the >> argument "0" (please compile with the same switches as qemu) and give >> me the results + disassembly? > > > 0000101c <host_cpuid>: > 101c: 55 push %ebp > 101d: 89 e5 mov %esp,%ebp > 101f: 57 push %edi > 1020: 56 push %esi > 1021: 53 push %ebx > 1022: 83 ec 3c sub $0x3c,%esp > 1025: 89 55 d4 mov %edx,-0x2c(%ebp) > 1028: 89 de mov %ebx,%esi > 102a: 0f a2 cpuid > 102c: 89 db mov %ebx,%ebx > 102e: 89 f3 mov %esi,%ebx > 1030: 89 d7 mov %edx,%edi > 1032: 89 55 e4 mov %edx,-0x1c(%ebp) > 1035: 8b 55 d4 mov -0x2c(%ebp),%edx > 1038: 85 d2 test %edx,%edx > 103a: 89 4d c4 mov %ecx,-0x3c(%ebp) > 103d: 89 5d d0 mov %ebx,-0x30(%ebp) > 1040: 89 45 d8 mov %eax,-0x28(%ebp) > 1043: 89 5d dc mov %ebx,-0x24(%ebp) > 1046: 89 4d e0 mov %ecx,-0x20(%ebp) > 1049: 74 05 je 1050 <host_cpuid+0x34> > 104b: 8b 55 d4 mov -0x2c(%ebp),%edx > 104e: 89 02 mov %eax,(%edx) > 1050: 8b 75 08 mov 0x8(%ebp),%esi > 1053: 85 f6 test %esi,%esi > 1055: 74 08 je 105f <host_cpuid+0x43> > 1057: 8b 5d d0 mov -0x30(%ebp),%ebx > 105a: 8b 4d 08 mov 0x8(%ebp),%ecx > 105d: 89 19 mov %ebx,(%ecx) > 105f: 8b 5d 0c mov 0xc(%ebp),%ebx > 1062: 85 db test %ebx,%ebx > 1064: 74 08 je 106e <host_cpuid+0x52> > 1066: 8b 55 c4 mov -0x3c(%ebp),%edx > 1069: 8b 45 0c mov 0xc(%ebp),%eax > 106c: 89 10 mov %edx,(%eax) > 106e: 8b 4d 10 mov 0x10(%ebp),%ecx > 1071: 85 c9 test %ecx,%ecx > 1073: 74 05 je 107a <host_cpuid+0x5e> > 1075: 8b 4d 10 mov 0x10(%ebp),%ecx > 1078: 89 39 mov %edi,(%ecx) > 107a: 83 c4 3c add $0x3c,%esp > 107d: 5b pop %ebx > 107e: 5e pop %esi > 107f: 5f pop %edi > 1080: c9 leave > 1081: c3 ret > > > Looks like %ebx was chosen for %1. I also don't see where %eax is > loaded. The ebx store was done because of PIC code, which does not allow ebx to get clobbered. If we are not in PIC code, =r contains ebx as GPR though, so the assumption that ebx needs to be restored was wrong then. This new version only enables the store/restore code if i386 and PIC code are used. There is no need to distinguish between x86_64 and i386 for the other cases. So does this version work? [-- Attachment #2: test.c --] [-- Type: application/octet-stream, Size: 947 bytes --] #include <stdio.h> #define uint32_t unsigned int static void host_cpuid(uint32_t function, uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx) { uint32_t vec[4]; #if defined(__i386__) && defined(__PIC__) asm volatile("movl %%ebx, %%esi \n\t" "cpuid \n\t" "movl %%ebx, %1 \n\t" "movl %%esi, %%ebx" : "=a" (vec[0]), "=r" (vec[1]), "=c" (vec[2]), "=d" (vec[3]) : "0"(function) : "esi", "cc"); #else asm volatile("cpuid" : "=a" (vec[0]), "=b" (vec[1]),"=c" (vec[2]), "=d" (vec[3]) : "0"(function) : "cc"); #endif if (eax) *eax = vec[0]; if (ebx) *ebx = vec[1]; if (ecx) *ecx = vec[2]; if (edx) *edx = vec[3]; } int main(int argc, char **argv) { unsigned int a,b,c,d; host_cpuid(atoi(argv[1]), &a, &b, &c, &d); printf("%#x = %#x %#x %#x %#x\n", atoi(argv[1]), a, b, c, d); } [-- Attachment #3: Type: text/plain, Size: 1 bytes --] [-- Attachment #4: Type: text/plain, Size: 228 bytes --] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ [-- Attachment #5: Type: text/plain, Size: 158 bytes --] _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue 2008-02-25 12:55 ` Alexander Graf @ 2008-02-25 17:40 ` Avi Kivity 2008-02-25 18:35 ` Alexander Graf 0 siblings, 1 reply; 10+ messages in thread From: Avi Kivity @ 2008-02-25 17:40 UTC (permalink / raw) To: Alexander Graf; +Cc: kvm-devel Alexander Graf wrote: > > The ebx store was done because of PIC code, which does not allow ebx > to get clobbered. If we are not in PIC code, =r contains ebx as GPR > though, so the assumption that ebx needs to be restored was wrong > then. This new version only enables the store/restore code if i386 and > PIC code are used. There is no need to distinguish between x86_64 and > i386 for the other cases. > > So does this version work? > It probably will, but it seems fragile to depend on the details of PIC. I committed something more generic: #ifdef __x86_64__ asm volatile("cpuid" : "=a"(vec[0]), "=b"(vec[1]), "=c"(vec[2]), "=d"(vec[3]) : "0"(function) : "cc"); #else asm volatile("pusha \n\t" "cpuid \n\t" "mov %%eax, 0(%1) \n\t" "mov %%ebx, 4(%1) \n\t" "mov %%ecx, 8(%1) \n\t" "mov %%edx, 12(%1) \n\t" "popa" : "a"(function), "S"(vec) : "memory", "cc"); #endif -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue 2008-02-25 17:40 ` Avi Kivity @ 2008-02-25 18:35 ` Alexander Graf 2008-02-25 19:26 ` Avi Kivity 0 siblings, 1 reply; 10+ messages in thread From: Alexander Graf @ 2008-02-25 18:35 UTC (permalink / raw) To: Avi Kivity; +Cc: kvm-devel On Feb 25, 2008, at 6:40 PM, Avi Kivity wrote: > Alexander Graf wrote: >> >> The ebx store was done because of PIC code, which does not allow >> ebx to get clobbered. If we are not in PIC code, =r contains ebx as >> GPR though, so the assumption that ebx needs to be restored was >> wrong then. This new version only enables the store/restore code if >> i386 and PIC code are used. There is no need to distinguish between >> x86_64 and i386 for the other cases. >> >> So does this version work? >> > > It probably will, but it seems fragile to depend on the details of > PIC. I committed something more generic: > > #ifdef __x86_64__ > asm volatile("cpuid" > : "=a"(vec[0]), "=b"(vec[1]), > "=c"(vec[2]), "=d"(vec[3]) > : "0"(function) : "cc"); This code works fine for all targets, including i386. With PIC enabled, gcc registers the ebx registers and complains about this, thus errors out. This is the only special case I am aware of, so I doubt we should treat any case different from the "normal" case but the PIC one. > > #else > asm volatile("pusha \n\t" > > "cpuid \n\t" > "mov %%eax, 0(%1) \n\t" > "mov %%ebx, 4(%1) \n\t" > "mov %%ecx, 8(%1) \n\t" > "mov %%edx, 12(%1) \n\t" > > "popa" > : "a"(function), "S"(vec) : "memory", "cc"); > #endif Basically #ifdef __x86_64__ is even wrong, as the problem is not that too many registers are being used, but that ebx is reserved and can't be saved/restored automatically. Furthermore I believe that the less assembler is used, the better the code looks. So for cases the snippet above is not required, why use it? Overusing assembler is imho exactly the reason the previous code broke. There's one more thing I'd like to add here. Gcc optimizes really well when one lets it to. So for this exact case with -O2 used, there are no memory accesses. The vector is simply stored in 4 registers and thus no more movs are required. Alex ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue 2008-02-25 18:35 ` Alexander Graf @ 2008-02-25 19:26 ` Avi Kivity 0 siblings, 0 replies; 10+ messages in thread From: Avi Kivity @ 2008-02-25 19:26 UTC (permalink / raw) To: Alexander Graf; +Cc: kvm-devel Alexander Graf wrote: > > On Feb 25, 2008, at 6:40 PM, Avi Kivity wrote: > >> Alexander Graf wrote: >>> >>> The ebx store was done because of PIC code, which does not allow ebx >>> to get clobbered. If we are not in PIC code, =r contains ebx as GPR >>> though, so the assumption that ebx needs to be restored was wrong >>> then. This new version only enables the store/restore code if i386 >>> and PIC code are used. There is no need to distinguish between >>> x86_64 and i386 for the other cases. >>> >>> So does this version work? >>> >> >> It probably will, but it seems fragile to depend on the details of >> PIC. I committed something more generic: >> >> #ifdef __x86_64__ >> asm volatile("cpuid" >> : "=a"(vec[0]), "=b"(vec[1]), >> "=c"(vec[2]), "=d"(vec[3]) >> : "0"(function) : "cc"); > > This code works fine for all targets, including i386. With PIC > enabled, gcc registers the ebx registers and complains about this, > thus errors out. This is the only special case I am aware of, so I > doubt we should treat any case different from the "normal" case but > the PIC one. > >> >> #else >> asm volatile("pusha \n\t" >> >> "cpuid \n\t" >> "mov %%eax, 0(%1) \n\t" >> "mov %%ebx, 4(%1) \n\t" >> "mov %%ecx, 8(%1) \n\t" >> "mov %%edx, 12(%1) \n\t" >> >> "popa" >> : "a"(function), "S"(vec) : "memory", "cc"); >> #endif > > Basically #ifdef __x86_64__ is even wrong, as the problem is not that > too many registers are being used, but that ebx is reserved and can't > be saved/restored automatically. > > Furthermore I believe that the less assembler is used, the better the > code looks. So for cases the snippet above is not required, why use > it? Overusing assembler is imho exactly the reason the previous code > broke. > I agree with all of this, but I think this case is an exception. gcc doesn't behave well with many register constraints on i386 and the PIC case shows things are not straightforward. I want something I can forget about. > There's one more thing I'd like to add here. Gcc optimizes really well > when one lets it to. So for this exact case with -O2 used, there are > no memory accesses. The vector is simply stored in 4 registers and > thus no more movs are required. > Again I agree, but host_cpuid() is hardly an optimization target. you can add a usleep(10000) there with no noticable effect. btw the cpuid instruction execution time itself will likely overwhelm any instructions around it (since it is microcoded). -- Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] fix CPUID handling 2008-02-25 10:45 ` Avi Kivity 2008-02-25 12:55 ` Alexander Graf @ 2008-02-25 17:37 ` Alexander Graf 1 sibling, 0 replies; 10+ messages in thread From: Alexander Graf @ 2008-02-25 17:37 UTC (permalink / raw) To: Avi Kivity; +Cc: kvm-devel [-- Attachment #1: Type: text/plain, Size: 156 bytes --] So this is a new version of the same patch. It should be rather safe now, as most cases are handled by gcc. Signed-off-by: Alexander Graf <alex@csgraf.de> [-- Attachment #2: cpuid.patch --] [-- Type: text/x-patch, Size: 1793 bytes --] diff --git a/qemu/qemu-kvm-x86.c b/qemu/qemu-kvm-x86.c index 37354fb..3062d1b 100644 --- a/qemu/qemu-kvm-x86.c +++ b/qemu/qemu-kvm-x86.c @@ -427,36 +427,22 @@ static void host_cpuid(uint32_t function, uint32_t *eax, uint32_t *ebx, { uint32_t vec[4]; - vec[0] = function; - asm volatile ( -#ifdef __x86_64__ - "sub $128, %%rsp \n\t" /* skip red zone */ - "push %0; push %%rsi \n\t" - "push %%rax; push %%rbx; push %%rcx; push %%rdx \n\t" - "mov 8*5(%%rsp), %%rsi \n\t" - "mov (%%rsi), %%eax \n\t" - "cpuid \n\t" - "mov %%eax, (%%rsi) \n\t" - "mov %%ebx, 4(%%rsi) \n\t" - "mov %%ecx, 8(%%rsi) \n\t" - "mov %%edx, 12(%%rsi) \n\t" - "pop %%rdx; pop %%rcx; pop %%rbx; pop %%rax \n\t" - "pop %%rsi; pop %0 \n\t" - "add $128, %%rsp" +#if defined(__i386__) && defined(__PIC__) + /* We need to handle ebx manually, as PIC code requires it */ + asm volatile("movl %%ebx, %%esi \n\t" + "cpuid \n\t" + "movl %%ebx, %1 \n\t" + "movl %%esi, %%ebx" + : "=a" (vec[0]), "=r" (vec[1]), "=c" (vec[2]), "=d" (vec[3]) + : "0"(function) + : "esi", "cc"); #else - "push %0; push %%esi \n\t" - "push %%eax; push %%ebx; push %%ecx; push %%edx \n\t" - "mov 4*5(%%esp), %%esi \n\t" - "mov (%%esi), %%eax \n\t" - "cpuid \n\t" - "mov %%eax, (%%esi) \n\t" - "mov %%ebx, 4(%%esi) \n\t" - "mov %%ecx, 8(%%esi) \n\t" - "mov %%edx, 12(%%esi) \n\t" - "pop %%edx; pop %%ecx; pop %%ebx; pop %%eax \n\t" - "pop %%esi; pop %0 \n\t" + asm volatile("cpuid" + : "=a" (vec[0]), "=b" (vec[1]),"=c" (vec[2]), "=d" (vec[3]) + : "0"(function) + : "cc"); #endif - : : "rm"(vec) : "memory"); + if (eax) *eax = vec[0]; if (ebx) [-- Attachment #3: Type: text/plain, Size: 228 bytes --] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ [-- Attachment #4: Type: text/plain, Size: 158 bytes --] _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel ^ permalink raw reply related [flat|nested] 10+ messages in thread
end of thread, other threads:[~2008-02-25 19:26 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-02-25 8:41 KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue Zhao, Yunfeng 2008-02-25 9:31 ` Yang, Sheng 2008-02-25 9:34 ` Avi Kivity 2008-02-25 10:28 ` Alexander Graf 2008-02-25 10:45 ` Avi Kivity 2008-02-25 12:55 ` Alexander Graf 2008-02-25 17:40 ` Avi Kivity 2008-02-25 18:35 ` Alexander Graf 2008-02-25 19:26 ` Avi Kivity 2008-02-25 17:37 ` [PATCH] fix CPUID handling Alexander Graf
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox