* 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
* [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
* 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
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