Li, Haicheng
2008-Mar-24 09:46 UTC
[Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no new issue
Hi all,
This is today''s nightly testing report; no new issue today. Most of
case
failures are due to bug #1183 and #1194 listed below.
For bug #1194, the issue `Linux booting hangs with "hda: dma..."
errors`
got fixed on this c/s; but neither Windows nor Linux X can boot up with
setting sdl=1 and opengl=1 if guest''s resolution is set as 800 * 600 or
higher.
Old issues:
=============================================1. 32pae Win2k hvm guest can not
boot up on 32pae and 32e host.
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1183
2. Hvm windows guest shows abnormal color.
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1180
3. Failed to install guest OS on both 32e and PAE host.
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1177
4. [Guest Test] SMP VISTA HVM guest might be blue screen when doing
large I/O in dom0.
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1117
5. HVM domain performance would downgrade, after doing save/restore.
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1143
6. XenU guest will hang if booted just after destorying a HVM guest.
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1139
7. PV drivers broken again: module xen-vnif.ko inserting failed.
8. both Linux and Windows HVM guest can not boot up,
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1194.
Testing Environments:
=============================================PAE
CPU : Xeon(r) processor 5300 series
Dom0 OS : FC6
Memory size : 8G
IA32e
CPU : Xeon(r) processor 5300 series
Dom0 OS : RHEL5
Memory size : 8G
Details:
=============================================Platform : PAE
Service OS : Fedora Core release 6 (Zod)
Hardware : Clovertown
Xen package: 17270:76c9cf11ce23
Date: Sat Mar 22 09:41:00 CST 2008
1. 2 PAE SMP VMX domains and 2 xenU domains coexist FAIL
2. Live and migration PASS
3. Save and Restore PASS
4. one PAE SMP Linux VMX domain with memory 256M PASS
5. one PAE SMP Linux VMX domain with memory 1500M PASS
6. one PAE SMP Linux VMX domain with memory 4G PASS
7. boot 4 VMX per processor at the same time PASS
8. boot up 1 winXP VMX and 1 linux PAE VMX PASS
9. Single domain with single vcpu bind a CPU PASS
10. boot up two winXP per processor at the same time PASS
11. boot up one linux VMX with 4 vcpus PASS
12. boot up four linux VMX one by one PASS
13. boot up VMX with acpi=1, vcpu=1 PASS
14. subset LTP test in RHEL4U2 PAE SMP VMX domain PASS
15. Boot Linux 2.6.23 base kernel in RHEL4U1 PAE SMP Linux VMX domain
PASS
16. one IA32 UP ACPI Windows 2K VMX domain FAIL
17. one IA32 UP ACPI Windows 2K3 VMX domain PASS
18. one IA32 UP ACPI Windows XP VMX domain PASS
19. one IA32 UP ACPI Vista VMX domain
FAIL
20. one IA32 SMP ACPI Windows 2K VMX domain FAIL
21. one IA32 SMP ACPI Windows 2K3 VMX domain PASS
22. one IA32 SMP ACPI Windows XP VMX domain PASS
23. one IA32 SMP ACPI Vista VMX domain
FAIL
24. one IA32 UP NOACPI Windows 2K VMX domain FAIL
25. one IA32 UP NOACPI Windows 2K3 VMX domain PASS
26. one IA32 UP NOACPI Windows XP VMX domain PASS
27. kernel build in one linux VMX PASS
28. startx in dom0 PASS
29. boot up one IA32 RHEL5u1 VMX domain. PASS
30. reboot Windows xp after it boot up. PASS
31. reboot Fedora core 6 after it boot up. PASS
32. VBD and VNIF works on UP VMX domain
NORESULT
33. VBD and VNIF works on SMP VMX domain
NORESULT
34. assign one pcie nic to one UP Linux guest with vtd. PASS
35. assign one pcie nic to one SMP Linux guest with vtd. PASS
36. assign one pcie nic to one UP WinXP guest with vtd. FAIL
37. assign one pci nic to one SMP Linux guest with vtd. PASS
38. assign one pci nic to one UP WinXP guest with vtd. FAIL
39. assign one pci nic to one UP Linux guest with vtd PASS
40. scp a big file in Linux guest via the pci nic assigned with vt-d.
PASS
41. assign one pcie nic to one SMP WinXP guest with vtd.
FAIL
42. assign one pci nic to one SMP WinXP guest with vtd.
FAIL
43. scp a big file in Linux guest via the pcie nic assigned with vt-d.
PASS
Platform : PAE
Service OS : Fedora Core release 6 (Zod)
Hardware : Clovertown
Xen package: 17270:76c9cf11ce23
Date: Sat Mar 22 09:41:00 CST 2008
Summary Test Report of Last Session
====================================================================
Total Pass Fail NoResult Crash
====================================================================vtd
10 6 4 0 0
device_model 2 0 0 2 0
control_panel 12 12 0 0 0
Restart 1 1 0 0 0
gtest 19 14 5 0 0
====================================================================vtd
10 6 4 0 0
:one_pcie_scp_PAE_gPAE 1 1 0 0 0
:one_pci_smp_xp_PAE_gPAE 1 0 1 0 0
:one_pcie_up_xp_PAE_gPAE 1 0 1 0 0
:one_pci_smp_PAE_gPAE 1 1 0 0 0
:one_pci_up_xp_PAE_gPAE 1 0 1 0 0
:one_pcie_smp_PAE_gPAE 1 1 0 0 0
:one_pcie_smp_xp_PAE_gPA 1 0 1 0 0
:one_pci_scp_PAE_gPAE 1 1 0 0 0
:one_pcie_up_PAE_gPAE 1 1 0 0 0
:one_pci_up_PAE_gPAE 1 1 0 0 0
device_model 2 0 0 2 0
:pv_on_up_PAE_gPAE 1 0 0 1 0
:pv_on_smp_PAE_gPAE 1 0 0 1 0
control_panel 12 12 0 0 0
:XEN_4G_guest_PAE_gPAE 1 1 0 0 0
:XEN_four_vmx_xenu_seq_P 1 1 0 0 0
:XEN_LM_PAE_gPAE 1 1 0 0 0
:XEN_four_dguest_co_PAE_ 1 1 0 0 0
:XEN_linux_win_PAE_gPAE 1 1 0 0 0
:XEN_SR_PAE_gPAE 1 1 0 0 0
:XEN_vmx_vcpu_pin_PAE_gP 1 1 0 0 0
:XEN_two_winxp_PAE_gPAE 1 1 0 0 0
:XEN_256M_guest_PAE_gPAE 1 1 0 0 0
:XEN_1500M_guest_PAE_gPA 1 1 0 0 0
:XEN_vmx_4vcpu_PAE_gPAE 1 1 0 0 0
:XEN_four_sguest_seq_PAE 1 1 0 0 0
Restart 1 1 0 0 0
:GuestPAE_PAE_gPAE 1 1 0 0 0
gtest 19 14 5 0 0
:boot_up_acpi_PAE_gPAE 1 1 0 0 0
:ltp_nightly_PAE_gPAE 1 1 0 0 0
:boot_up_acpi_xp_PAE_gPA 1 1 0 0 0
:reboot_xp_PAE_gPAE 1 1 0 0 0
:boot_up_vista_PAE_gPAE 1 0 1 0 0
:boot_up_acpi_win2k3_PAE 1 1 0 0 0
:boot_smp_acpi_win2k3_PA 1 1 0 0 0
:boot_smp_acpi_win2k_PAE 1 0 1 0 0
:boot_up_acpi_win2k_PAE_ 1 0 1 0 0
:boot_smp_acpi_xp_PAE_gP 1 1 0 0 0
:boot_up_noacpi_win2k_PA 1 1 0 0 0
:boot_smp_vista_PAE_gPAE 1 0 1 0 0
:boot_up_noacpi_win2k3_P 1 1 0 0 0
:boot_rhel5u1_PAE_gPAE 1 1 0 0 0
:boot_base_kernel_PAE_gP 1 1 0 0 0
:boot_up_noacpi_xp_PAE_g 1 1 0 0 0
:bootx_PAE_gPAE 1 0 1 0 0
:reboot_fc6_PAE_gPAE 1 1 0 0 0
:kb_nightly_PAE_gPAE 1 1 0 0 0
====================================================================Total
44 33 9 2 0
Platform : x86_64
Service OS : Red Hat Enterprise Linux Server release 5 (Tikanga)
Hardware : Clovertown
Xen package: 17270:76c9cf11ce23
Date: Sat Mar 22 10:13:21 CST 2008
1. boot up four PAE linux VMX one by one
PASS
2. one PAE xenU domain with memory 256M PASS
3. one PAE SMP Linux VMX domain with memory 1500M PASS
4. one PAE SMP Linux VMX domain with memory 4G PASS
5. one PAE SMP Linux VMX domain with memory 256M PASS
6. 2 ia32E SMP VMX domains and 2 xenU domains coexist FAIL
7. Live and migration PASS
8. Save and Restore PASS
9. one ia32E SMP Linux VMX domain with memory 1500M PASS
10. one ia32E SMP Linux VMX domain with memory 4G
PASS
11. one ia32E SMP Linux VMX domain with memory 256M PASS
12. boot 4 VMX per processor at the same time PASS
13. boot up 1 winXP VMX and 1 linux VMX FAIL
14. Single domain with single vcpu bind a CPU PASS
15. boot up two winXP per processor at the same time FAIL
16. boot up one linux VMX with 4 vcpus PASS
17. boot up four linux VMX one by one PASS
18. Boot up VMX with acpi=1, vcpu=1 PASS
19. subset LTP test in RHEL4U2 ia32E SMP VMX domain PASS
20. one IA32E UP ACPI Windows 2K3 VMX domain FAIL
21. one IA32E UP ACPI Windows 2K VMX domain FAIL
22. one IA32E UP ACPI Windows XP VMX domain FAIL
23. one IA32E UP ACPI Vista VMX domain
FAIL
24. one IA32E SMP ACPI Windows 2K3 VMX domain FAIL
25. one IA32E SMP ACPI Windows 2K VMX domain FAIL
26. one IA32E SMP ACPI Windows XP VMX domain FAIL
27. one IA32E SMP ACPI Vista VMX domain
FAIL
28. one IA32E UP NOACPI Windows 2K VMX domain FAIL
29. boot Linux 2.6.23 base kernel in ia32E SMP Linux VMX domain PASS
30. kernel build in one ia32E linux VMX PASS
31. startx in dom0 FAIL
32. boot up one IA32E RHEL5u1 VMX domain. PASS
33. reboot Windows xp after it boot up. FAIL
34. reboot Fedora core 6 after it boot up. PASS
35. VBD and VNIF works on UP VMX domain
NORESULT
36. VBD and VNIF works on SMP VMX domain
NORESULT
37. assign one pcie nic to one UP Linux guest with vtd. PASS
38. assign one pcie nic to one SMP Linux guest with vtd. PASS
39. assign one pcie nic to one UP WinXP guest with vtd. FAIL
40. assign one pci nic to one SMP Linux guest with vtd. PASS
41. assign one pci nic to one UP WinXP guest with vtd. FAIL
42. assign one pci nic to one UP Linux guest with vtd PASS
43. scp a big file in Linux guest via the pci nic assigned with vt-d.
PASS
44. assign one pcie nic to one SMP WinXP guest with vtd.
FAIL
45. assign one pci nic to one SMP WinXP guest with vtd.
FAIL
46. scp a big file in Linux guest via the pcie nic assigned with vt-d.
PASS
Platform : x86_64
Service OS : Red Hat Enterprise Linux Server release 5 (Tikanga)
Hardware : Clovertown
Xen package: 17270:76c9cf11ce23
Date: Sat Mar 22 10:13:21 CST 2008
Summary Test Report of Last Session
====================================================================
Total Pass Fail NoResult Crash
====================================================================vtd
10 6 4 0 0
device_model 2 0 0 2 0
control_panel 17 14 3 0 0
Restart 2 2 0 0 0
gtest 17 6 11 0 0
====================================================================vtd
10 6 4 0 0
:one_pcie_smp_xp_64_g64 1 0 1 0 0
:one_pci_smp_xp_64_g64 1 0 1 0 0
:one_pcie_up_xp_64_g64 1 0 1 0 0
:one_pcie_up_64_g64 1 1 0 0 0
:one_pcie_scp_64_g64 1 1 0 0 0
:one_pci_scp_64_g64 1 1 0 0 0
:one_pci_up_xp_64_g64 1 0 1 0 0
:one_pci_smp_64_g64 1 1 0 0 0
:one_pcie_smp_64_g64 1 1 0 0 0
:one_pci_up_64_g64 1 1 0 0 0
device_model 2 0 0 2 0
:pv_on_smp_64_g64 1 0 0 1 0
:pv_on_up_64_g64 1 0 0 1 0
control_panel 17 14 3 0 0
:XEN_1500M_guest_64_g64 1 1 0 0 0
:XEN_256M_xenu_64_gPAE 1 1 0 0 0
:XEN_vmx_4vcpu_64_g64 1 1 0 0 0
:XEN_1500M_guest_64_gPAE 1 1 0 0 0
:XEN_4G_guest_64_gPAE 1 1 0 0 0
:XEN_256M_guest_64_g64 1 1 0 0 0
:XEN_SR_64_g64 1 1 0 0 0
:XEN_four_sguest_seq_64_ 1 1 0 0 0
:XEN_vmx_vcpu_pin_64_g64 1 1 0 0 0
:XEN_linux_win_64_g64 1 0 1 0 0
:XEN_256M_guest_64_gPAE 1 1 0 0 0
:XEN_LM_64_g64 1 1 0 0 0
:XEN_two_winxp_64_g64 1 0 1 0 0
:XEN_four_vmx_xenu_seq_6 1 0 1 0 0
:XEN_four_sguest_seq_64_ 1 1 0 0 0
:XEN_4G_guest_64_g64 1 1 0 0 0
:XEN_four_dguest_co_64_g 1 1 0 0 0
Restart 2 2 0 0 0
:Guest64_64_gPAE 1 1 0 0 0
:GuestPAE_64_g64 1 1 0 0 0
gtest 17 6 11 0 0
:boot_smp_acpi_xp_64_g64 1 0 1 0 0
:boot_base_kernel_64_g64 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_acpi_win2k3_64_ 1 0 1 0 0
:bootx_64_g64 1 0 1 0 0
:reboot_xp_64_g64 1 0 1 0 0
:boot_smp_acpi_win2k_64_ 1 0 1 0 0
:boot_up_vista_64_g64 1 0 1 0 0
:boot_up_noacpi_win2k_64 1 0 1 0 0
:boot_up_acpi_win2k_64_g 1 0 1 0 0
:boot_smp_vista_64_g64 1 0 1 0 0
:reboot_fc6_64_g64 1 1 0 0 0
:boot_up_acpi_xp_64_g64 1 0 1 0 0
:boot_smp_acpi_win2k3_64 1 0 1 0 0
:boot_rhel5u1_64_g64 1 1 0 0 0
:kb_nightly_64_g64 1 1 0 0 0
====================================================================Total
48 28 18 2 0
-- haicheng
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Samuel Thibault
2008-Mar-24 10:15 UTC
Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no new issue
Li, Haicheng, le Mon 24 Mar 2008 17:46:29 +0800, a écrit :> 2. Hvm windows guest shows abnormal color. > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1180Oh, it is really still present? I can''t reproduce it any more> 5. HVM domain performance would downgrade, after doing save/restore. > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1143That also should have been fixed Thanks for testing! Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Li, Haicheng
2008-Mar-25 06:17 UTC
RE: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no newissue
Samuel Thibault wrote:> Li, Haicheng, le Mon 24 Mar 2008 17:46:29 +0800, a écrit : >> 2. Hvm windows guest shows abnormal color. >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1180 > > Oh, it is really still present? I can''t reproduce it any moreRetested it on c/s 17270, the setting of resolution and color depth can be changed to higher value; but with higher setting applied, the color still looks abnormal without obvious change comparing to lower resolution and color depth.>> 5. HVM domain performance would downgrade, after doing save/restore. >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1143 > > That also should have been fixedYes, it has been fixed. I''ve marked this bug as verified. Thanks. -- haicheng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Mar-25 11:18 UTC
Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no new issue
On 24/3/08 09:46, "Li, Haicheng" <haicheng.li@intel.com> wrote:> This is today''s nightly testing report; no new issue today. Most of case > failures are due to bug #1183 and #1194 listed below. > > For bug #1194, the issue `Linux booting hangs with "hda: dma..." errors` > got fixed on this c/s; but neither Windows nor Linux X can boot up with > setting sdl=1 and opengl=1 if guest''s resolution is set as 800 * 600 or > higher.Haicheng, I guess you do your testing offline, but do you have a feel for how fast guest installation is now compared with a few weeks ago (before mmio emulation changes)? I''m thinking it''s slowed down rather a lot, at least on my old Pentium 4 test system. :-( -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Li, Haicheng
2008-Mar-26 09:36 UTC
RE: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- nonew issue
Keir Fraser wrote:> On 24/3/08 09:46, "Li, Haicheng" <haicheng.li@intel.com> wrote: > >> This is today''s nightly testing report; no new issue today. Most of >> case failures are due to bug #1183 and #1194 listed below. >> >> For bug #1194, the issue `Linux booting hangs with "hda: dma..." >> errors` got fixed on this c/s; but neither Windows nor Linux X can >> boot up with setting sdl=1 and opengl=1 if guest''s resolution is set >> as 800 * 600 or higher. > > Haicheng, > > I guess you do your testing offline, but do you have a feel for how > fast guest installation is now compared with a few weeks ago (before > mmio emulation changes)? I''m thinking it''s slowed down rather a lot, > at least on my old Pentium 4 test system. :-(Keir, we checked guest installation with rhel4u3 today, we compared c/s 17284 with c/s 16720, The result shows latest c/s with mmio emulation changes is a little bit faster than before on our test system with Xeon(r) processors, about 20 seconds faster. -- haicheng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Mar-26 10:00 UTC
Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- nonew issue
On 26/3/08 09:36, "Li, Haicheng" <haicheng.li@intel.com> wrote:>> I guess you do your testing offline, but do you have a feel for how >> fast guest installation is now compared with a few weeks ago (before >> mmio emulation changes)? I''m thinking it''s slowed down rather a lot, >> at least on my old Pentium 4 test system. :-( > > Keir, we checked guest installation with rhel4u3 today, we compared c/s > 17284 with c/s 16720, > The result shows latest c/s with mmio emulation changes is a little bit > faster than before on our test system with Xeon(r) processors, about 20 > seconds faster.That''s pretty surprising! I found out that slowdown on my P4 system for WinXP installation is about 15%, so not as bad as I thought. And I can probably reclaim most of that performance loss. I find it hard to explain a performance *win* though! -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Mar-26 10:13 UTC
Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- nonew issue
On 26/3/08 10:00, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:>> Keir, we checked guest installation with rhel4u3 today, we compared c/s >> 17284 with c/s 16720, >> The result shows latest c/s with mmio emulation changes is a little bit >> faster than before on our test system with Xeon(r) processors, about 20 >> seconds faster. > > That''s pretty surprising! I found out that slowdown on my P4 system for > WinXP installation is about 15%, so not as bad as I thought. And I can > probably reclaim most of that performance loss. > > I find it hard to explain a performance *win* though!Actually, how long does the install take in total? 20 seconds is probably in the noise. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Mar-26 15:34 UTC
Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- nonew issue
On 26/3/08 10:00, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:>> Keir, we checked guest installation with rhel4u3 today, we compared c/s >> 17284 with c/s 16720, >> The result shows latest c/s with mmio emulation changes is a little bit >> faster than before on our test system with Xeon(r) processors, about 20 >> seconds faster. > > That''s pretty surprising! I found out that slowdown on my P4 system for > WinXP installation is about 15%, so not as bad as I thought. And I can > probably reclaim most of that performance loss. > > I find it hard to explain a performance *win* though!Well, I implemented a virtual-address to mmio-physical-address lookaside cache for x86_emulate(), and with that I get following results for install of WinXP (time is up to second reboot, after graphical part of install, from an auto-install CD image): xen 3.2: 1 hour 20 minutes 23 seconds xen unstable using x86_emulate(): 1 hour 33 minutes 4 seconds xen unstable with new optimisation: 1 hour 12 minutes 57 seconds Considering first result (Xen 3.2) as a baseline control experiment, basic x86_emulate() mmio performance is 16% slower, while with the simple extra optimisation I get a 10% speedup (so that''s 22% speedup compared without the optimisation). Pretty nice! -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Li, Haicheng
2008-Mar-27 02:36 UTC
RE: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 --nonew issue
Keir Fraser wrote:> On 26/3/08 10:00, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: > >>> Keir, we checked guest installation with rhel4u3 today, we compared >>> c/s 17284 with c/s 16720, The result shows latest c/s with mmio >>> emulation changes is a little bit faster than before on our test >>> system with Xeon(r) processors, about 20 seconds faster. >> >> That''s pretty surprising! I found out that slowdown on my P4 system >> for WinXP installation is about 15%, so not as bad as I thought. And >> I can probably reclaim most of that performance loss. >> >> I find it hard to explain a performance *win* though! > > Actually, how long does the install take in total? 20 seconds is > probably in the noise. >About 7 ~ 8 min for a basic installation of rhel4u3, about 3~4% faster; but from user side, 20 sec would be ignored. -- haicheng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Cui, Dexuan
2008-Mar-27 02:43 UTC
RE: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 --nonew issue
Keir Fraser wrote:> Well, I implemented a virtual-address to mmio-physical-address > lookaside cache for x86_emulate(), and with that I get following > results for install of WinXP (time is up to second reboot, after > graphical part of install, from an auto-install CD image): > xen 3.2: 1 hour 20 minutes 23 seconds > xen unstable using x86_emulate(): 1 hour 33 minutes 4 seconds > xen unstable with new optimisation: 1 hour 12 minutes 57 seconds > > Considering first result (Xen 3.2) as a baseline control experiment, > basic x86_emulate() mmio performance is 16% slower, while with the > simple extra optimisation I get a 10% speedup (so that''s 22% speedup > compared without the optimisation). > > Pretty nice! > > -- KeirReally great! -- Dexuan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Li, Haicheng
2008-Mar-27 03:00 UTC
RE: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- nonew issue
Keir Fraser wrote:> On 26/3/08 10:00, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: > >>> Keir, we checked guest installation with rhel4u3 today, we compared >>> c/s 17284 with c/s 16720, The result shows latest c/s with mmio >>> emulation changes is a little bit faster than before on our test >>> system with Xeon(r) processors, about 20 seconds faster. >> >> That''s pretty surprising! I found out that slowdown on my P4 system >> for WinXP installation is about 15%, so not as bad as I thought. And >> I can probably reclaim most of that performance loss. >> >> I find it hard to explain a performance *win* though! > > Well, I implemented a virtual-address to mmio-physical-address > lookaside cache for x86_emulate(), and with that I get following > results for install of WinXP (time is up to second reboot, after > graphical part of install, from an auto-install CD image): > xen 3.2: 1 hour 20 minutes 23 seconds > xen unstable using x86_emulate(): 1 hour 33 minutes 4 seconds > xen unstable with new optimisation: 1 hour 12 minutes 57 seconds > > Considering first result (Xen 3.2) as a baseline control experiment, > basic x86_emulate() mmio performance is 16% slower, while with the > simple extra optimisation I get a 10% speedup (so that''s 22% speedup > compared without the optimisation). > > Pretty nice! > > -- KeirPretty good enhancement. Seems on your P4 system, WinXP installation can well expose this performance issue :). In our environment, install rhel4u3 with full packages of editors, test-internet, authoring-and-publishing, development-tools, admin-tools and system-tools. c/s 17284 : 422s c/s 16720 : 438s -- haicheng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Xu, Dongxiao
2008-Mar-28 10:01 UTC
RE: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no newissue
Hi, Samuel,
Recently, I look into the bug 1180: Hvm windows guest shows abnormal color.
I find that, if we use X window to boot a windows guest, the color is correct;
and if we use vnc viewer to connect to the host and boot a windows guest, the
color is abnormal. This issue comes from Xen C/S 17171.
BTW, I set sdl=1 and vnc=0 in my configuration file. If set sdl=0 and vnc=1 in
configuration file, both color from vnc viewer or X window are correct.
Best regards,
-- Dongxiao
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Samuel Thibault
Sent: 2008年3月24日 18:15
To: Li, Haicheng
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no
newissue
Li, Haicheng, le Mon 24 Mar 2008 17:46:29 +0800, a écrit
:> 2. Hvm windows guest shows abnormal color.
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1180
Oh, it is really still present? I can''t reproduce it any more
> 5. HVM domain performance would downgrade, after doing save/restore.
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1143
That also should have been fixed
Thanks for testing!
Samuel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2008-Mar-28 10:27 UTC
Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no newissue
It''s weird that we have not reproduced the issue here. I always use VNC to a remote host, and I see no colour issues with a newly-installed WinXP SP2 guest. Is this difference in observed behaviour explainable? -- Keir On 28/3/08 10:01, "Xu, Dongxiao" <dongxiao.xu@intel.com> wrote:> Hi, Samuel, > Recently, I look into the bug 1180: Hvm windows guest shows abnormal > color. I find that, if we use X window to boot a windows guest, the color is > correct; and if we use vnc viewer to connect to the host and boot a windows > guest, the color is abnormal. This issue comes from Xen C/S 17171. > > BTW, I set sdl=1 and vnc=0 in my configuration file. If set sdl=0 and vnc=1 in > configuration file, both color from vnc viewer or X window are correct. > > Best regards, > -- Dongxiao > > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Samuel Thibault > Sent: 2008年3月24日 18:15 > To: Li, Haicheng > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no > newissue > > Li, Haicheng, le Mon 24 Mar 2008 17:46:29 +0800, a écrit : >> 2. Hvm windows guest shows abnormal color. >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1180 > > Oh, it is really still present? I can''t reproduce it any more > >> 5. HVM domain performance would downgrade, after doing save/restore. >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1143 > > That also should have been fixed > > Thanks for testing! > Samuel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2008-Mar-28 10:53 UTC
Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no newissue
Xu, Dongxiao wrote:> Hi, Samuel, > Recently, I look into the bug 1180: Hvm windows guest shows abnormal color. I find that, if we use X window to boot a windows guest, the color is correct; and if we use vnc viewer to connect to the host and boot a windows guest, the color is abnormal. This issue comes from Xen C/S 17171. > > BTW, I set sdl=1 and vnc=0 in my configuration file. If set sdl=0 and vnc=1 in configuration file, both color from vnc viewer or X window are correct. >Sorry I don''t fully understand: is when you where using sdl=1 and vnc=0 (that is the SDL windows) that you saw abnormal colours or when you where using sdl=0 and vnc=1 (vnc interface)? These informations would be helpful: - the colour depth and resolution in the window guest - the colour depth and resolution of your dom0 X window system - which vnc viewer you are using (if the problem is with vnc) Regards, Stefano Stabellini P.S. I was independently able to reproduce another colour problem that happens only when the guest colour resolution is 8 bpp. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Xu, Dongxiao
2008-Mar-29 09:17 UTC
RE: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no newissue
Hi, Stefano and Keir,
When I set sdl=1, vnc=0 and use VNC viewer to connect a host, then boot a
windows guest, the color is abnormal.
If I set sdl=0, vnc=1 and use VNC viewewr to connect a host, then boot a
windows guest, the color is correct.
If I use Domain0''s X window to boot a windows guest and whatever
sdl=1, vnc=0 or sdl=0, vnc=1, the color is correct.
The color depth and resolution of my windows guest is: 800*600, 24bit or
16bit. And my VNC version is: VNC Viewer Free Edision 4.1.1. I will check my
Domain0''s resolution and color depth when I back to company on Monday.
Best regards,
-- Dongxiao
-----Original Message-----
From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
Sent: 2008年3月28日 18:54
To: Xu, Dongxiao
Cc: Samuel Thibault; Li, Haicheng; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no
newissue
Xu, Dongxiao wrote:> Hi, Samuel,
> Recently, I look into the bug 1180: Hvm windows guest shows abnormal
color. I find that, if we use X window to boot a windows guest, the color is
correct; and if we use vnc viewer to connect to the host and boot a windows
guest, the color is abnormal. This issue comes from Xen C/S 17171.
>
> BTW, I set sdl=1 and vnc=0 in my configuration file. If set sdl=0 and vnc=1
in configuration file, both color from vnc viewer or X window are correct.
>
Sorry I don''t fully understand: is when you where using sdl=1 and vnc=0
(that is the SDL windows) that you saw abnormal colours or when you
where using sdl=0 and vnc=1 (vnc interface)?
These informations would be helpful:
- the colour depth and resolution in the window guest
- the colour depth and resolution of your dom0 X window system
- which vnc viewer you are using (if the problem is with vnc)
Regards,
Stefano Stabellini
P.S.
I was independently able to reproduce another colour problem that
happens only when the guest colour resolution is 8 bpp.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2008-Mar-29 09:27 UTC
Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no newissue
Should VNC viewing work at all if vnc=0? What about X Windows viewing and sdl=0? If they should work, what are the sdl and vnc config options for in the first place? -- Keir On 29/3/08 09:17, "Xu, Dongxiao" <dongxiao.xu@intel.com> wrote:> Hi, Stefano and Keir, > > When I set sdl=1, vnc=0 and use VNC viewer to connect a host, then boot a > windows guest, the color is abnormal. > If I set sdl=0, vnc=1 and use VNC viewewr to connect a host, then boot a > windows guest, the color is correct. > If I use Domain0''s X window to boot a windows guest and whatever sdl=1, > vnc=0 or sdl=0, vnc=1, the color is correct. > > The color depth and resolution of my windows guest is: 800*600, 24bit or > 16bit. And my VNC version is: VNC Viewer Free Edision 4.1.1. I will check my > Domain0''s resolution and color depth when I back to company on Monday. > > Best regards, > -- Dongxiao > > -----Original Message----- > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com] > Sent: 2008年3月28日 18:54 > To: Xu, Dongxiao > Cc: Samuel Thibault; Li, Haicheng; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no > newissue > > Xu, Dongxiao wrote: >> Hi, Samuel, >> Recently, I look into the bug 1180: Hvm windows guest shows abnormal >> color. I find that, if we use X window to boot a windows guest, the color is >> correct; and if we use vnc viewer to connect to the host and boot a windows >> guest, the color is abnormal. This issue comes from Xen C/S 17171. >> >> BTW, I set sdl=1 and vnc=0 in my configuration file. If set sdl=0 and vnc=1 >> in configuration file, both color from vnc viewer or X window are correct. >> > > Sorry I don''t fully understand: is when you where using sdl=1 and vnc=0 > (that is the SDL windows) that you saw abnormal colours or when you > where using sdl=0 and vnc=1 (vnc interface)? > > These informations would be helpful: > > - the colour depth and resolution in the window guest > > - the colour depth and resolution of your dom0 X window system > > - which vnc viewer you are using (if the problem is with vnc) > > Regards, > > Stefano Stabellini > > P.S. > I was independently able to reproduce another colour problem that > happens only when the guest colour resolution is 8 bpp._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2008-Mar-29 17:29 UTC
Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no newissue
Keir Fraser wrote:> Should VNC viewing work at all if vnc=0? What about X Windows viewing and > sdl=0? If they should work, what are the sdl and vnc config options for in > the first place? >I don''t really think they should work at all. Or at least they are not supposed to work. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Mar-30 09:36 UTC
Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no newissue
On 29/3/08 18:29, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com> wrote:> Keir Fraser wrote: >> Should VNC viewing work at all if vnc=0? What about X Windows viewing and >> sdl=0? If they should work, what are the sdl and vnc config options for in >> the first place? > > I don''t really think they should work at all. > Or at least they are not supposed to work.Okay, then the ''abnormal colours'' bug is a misconfiguration, since it is not allowed to use VNC viewing when vnc=0. If any fix is to be considered, it should be to stop qemu-dm from opening a listening socket in this case. Has this behaviour changed recently? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Xu, Dongxiao
2008-Mar-31 02:22 UTC
RE: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no newissue
Hi, Stefano and Keir,
I think you may misunderstand my description. I use VNC viewer to connect
the Domain0 host (not the windows guest) and then boot the windows guest. Set
sdl=1 and vnc=0 in configuration file means that qemu uses sdl lib to draw the
guest GUI. I think in this case VNC viewer should still present the correct
color.
Best regards,
-- Dongxiao
-----Original Message-----
From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
Sent: 2008年3月30日 1:30
To: Keir Fraser
Cc: Xu, Dongxiao; Samuel Thibault; Li, Haicheng; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no
newissue
Keir Fraser wrote:> Should VNC viewing work at all if vnc=0? What about X Windows viewing and
> sdl=0? If they should work, what are the sdl and vnc config options for in
> the first place?
>
I don''t really think they should work at all.
Or at least they are not supposed to work.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2008-Mar-31 07:26 UTC
Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no newissue
Oh, that makes more sense! -- Keir On 31/3/08 03:22, "Xu, Dongxiao" <dongxiao.xu@intel.com> wrote:> Hi, Stefano and Keir, > I think you may misunderstand my description. I use VNC viewer to connect > the Domain0 host (not the windows guest) and then boot the windows guest. Set > sdl=1 and vnc=0 in configuration file means that qemu uses sdl lib to draw the > guest GUI. I think in this case VNC viewer should still present the correct > color. > > Best regards, > -- Dongxiao > > -----Original Message----- > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com] > Sent: 2008年3月30日 1:30 > To: Keir Fraser > Cc: Xu, Dongxiao; Samuel Thibault; Li, Haicheng; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no > newissue > > Keir Fraser wrote: >> Should VNC viewing work at all if vnc=0? What about X Windows viewing and >> sdl=0? If they should work, what are the sdl and vnc config options for in >> the first place? >> > > I don''t really think they should work at all. > Or at least they are not supposed to work._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Xu, Dongxiao
2008-Apr-01 09:23 UTC
RE: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no newissue
Hi, Keir and Stefano,
Can you now reproduce this colour bug now? I just tried the latest version
of VNC viewer, but the windows colour is still abnormal.
Best Regards,
-- Dongxiao
-----Original Message-----
From: Keir Fraser [mailto:keir.fraser@eu.citrix.com]
Sent: 2008年3月31日 15:27
To: Xu, Dongxiao; Stefano Stabellini
Cc: Samuel Thibault; Li, Haicheng; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no
newissue
Oh, that makes more sense!
-- Keir
On 31/3/08 03:22, "Xu, Dongxiao" <dongxiao.xu@intel.com> wrote:
> Hi, Stefano and Keir,
> I think you may misunderstand my description. I use VNC viewer to
connect
> the Domain0 host (not the windows guest) and then boot the windows guest.
Set
> sdl=1 and vnc=0 in configuration file means that qemu uses sdl lib to draw
the
> guest GUI. I think in this case VNC viewer should still present the correct
> color.
>
> Best regards,
> -- Dongxiao
>
> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: 2008年3月30日 1:30
> To: Keir Fraser
> Cc: Xu, Dongxiao; Samuel Thibault; Li, Haicheng;
xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 --
no
> newissue
>
> Keir Fraser wrote:
>> Should VNC viewing work at all if vnc=0? What about X Windows viewing
and
>> sdl=0? If they should work, what are the sdl and vnc config options for
in
>> the first place?
>>
>
> I don''t really think they should work at all.
> Or at least they are not supposed to work.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Stefano Stabellini
2008-Apr-01 09:31 UTC
Re: [Xen-devel] VMX status report. Xen: #17270 & Xen0: #488 -- no newissue
Xu, Dongxiao wrote:> Hi, Keir and Stefano, > Can you now reproduce this colour bug now? I just tried the latest version of VNC viewer, but the windows colour is still abnormal. >I am working on a patch that should solve many of the current rendering issues. I am hoping to solve also that problem with this patch or the next. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Possibly Parallel Threads
- VMX status report. Xen: #17702 & Xen0: #559 -- no new issue
- VMX status report. Xen: #17917 & Xen0: #583 -- no new issue
- Weekly VMX status report. Xen: #18132 & Xen0: #616
- VMX status report. Xen: #17714 & Xen0: #559 -- one new issue
- VMX status report. Xen:#16646 & Xen0: #370 -- Xen 3.2 RC2 -- two new issues