VMX status report. Xen: #17270 & Xen0: #488 -- no new issue

VMX status report. Xen: #17270 & Xen0: #488 -- no new issue

[Li, Haicheng]

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

Re: VMX status report. Xen: #17270 & Xen0: #488 -- no new issue

[Samuel Thibault]

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

RE: VMX status report. Xen: #17270 & Xen0: #488 -- no newissue

[Li, Haicheng]

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 more

Retested 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 fixed
Yes, it has been fixed. I've marked this bug as verified. Thanks.


-- haicheng

Re: VMX status report. Xen: #17270 & Xen0: #488 -- no new issue

[Keir Fraser]

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

RE: VMX status report. Xen: #17270 & Xen0: #488 -- nonew issue

[Li, Haicheng]

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

Re: VMX status report. Xen: #17270 & Xen0: #488 -- nonew issue

[Keir Fraser]

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

Re: VMX status report. Xen: #17270 & Xen0: #488 -- nonew issue

[Keir Fraser]

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

Re: VMX status report. Xen: #17270 & Xen0: #488 -- nonew issue

[Keir Fraser]

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

RE: VMX status report. Xen: #17270 & Xen0: #488 --nonew issue

[Li, Haicheng]

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

RE: VMX status report. Xen: #17270 & Xen0: #488 --nonew issue

[Cui, Dexuan]

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!
> 
>  -- Keir

Really great!

-- Dexuan

RE: VMX status report. Xen: #17270 & Xen0: #488 -- nonew issue

[Li, Haicheng]

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!
> 
>  -- Keir

Pretty 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

RE: VMX status report. Xen: #17270 & Xen0: #488 -- no newissue

[Xu, Dongxiao]

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

Re: VMX status report. Xen: #17270 & Xen0: #488 -- no newissue

[Keir Fraser]

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

Re: VMX status report. Xen: #17270 & Xen0: #488 -- no newissue

[Stefano Stabellini]

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.

RE: VMX status report. Xen: #17270 & Xen0: #488 -- no newissue

[Xu, Dongxiao]

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.

Re: VMX status report. Xen: #17270 & Xen0: #488 -- no newissue

[Keir Fraser]

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.

Re: VMX status report. Xen: #17270 & Xen0: #488 -- no newissue

[Stefano Stabellini]

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.

Re: VMX status report. Xen: #17270 & Xen0: #488 -- no newissue

[Keir Fraser]

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

RE: VMX status report. Xen: #17270 & Xen0: #488 -- no newissue

[Xu, Dongxiao]

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.

Re: VMX status report. Xen: #17270 & Xen0: #488 -- no newissue

[Keir Fraser]

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.

RE: VMX status report. Xen: #17270 & Xen0: #488 -- no newissue

[Xu, Dongxiao]

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.

Re: VMX status report. Xen: #17270 & Xen0: #488 -- no newissue

[Stefano Stabellini]

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.