qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank s


From: Gonglei (Arei)
Subject: Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
Date: Fri, 26 Jul 2013 01:57:01 +0000



> >> Il 25/07/2013 15:13, Gonglei (Arei) ha scritto:
> >>> Hi,
> >>>     I found a problem: For windows XP guest booting by qemu upstream,
> >>> using the RDP(Remote Desktop Protocol) and VNC protocol to connect the
> >> windows XP guest
> >>> which booting by Qemu upstream respectively. the VNC client will become
> >> blank screen last
> >>> 13 seconds or so on XEN platform, and last 2 seconds on KVM. And through
> >> debugging,
> >>> the cirrus VGA card does not produce dirty pages during the blank screen's
> >> times.
> >>>     When -vga is changed from cirrus to std the issue goes away and the
> >> update proceeds at normal speed.
> >>> In addition, when using the Qemu-dm replace Qemu upstream on XEN
> >> platform,
> >>> the cirrus VGA works good and the issue goes away also.
> >>>
> >>>     Today, lots of googling have seen the same behavior:
> >>>
> >>> https://github.com/joyent/smartos-live/issues/215
> >>> http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg02105.html
> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574988
> >>> etc...
> >>>
> >>>     But, I test the latest qemu-1.5.1, the problem exist firmly.
> >>>
> >>>     Any ideas? Thanks!
> >>>
> >>> Best Regards!
> >>> -Gonglei
> >>> _______________________________________________
> >>> Xen-devel mailing list
> >>> address@hidden
> >>> http://lists.xen.org/xen-devel
> >> I've seen the perfomance problem too with vnc when I started to try
> >> upstream qemu. I already reported it on the end of 2011 but no solution 
> >> yet.
> >> I found spice as an alternative: qxl vga will not work on xen until SSE
> >> support will be added on hvm domU, but spice is usable with stdvga and
> >> performance is better that vnc. Combined with vdagent and usb
> >> redirection it makes a perfect vkvm, and more.
> >> Spice basic support in xl is already present and for more features I
> >> posted some patches here but they are not included in upstream for now.
> >> Cirrus vga drivers are also old and have limitations on both windows and
> >> linux and they can add other problems, they are probably not good for
> >> recent os/de.
> > Thanks for responding. I don't understand why the Qemu-dm works well
> > but the upstream qemu is not for the same windows XP guest image.
> > Does the Cirrus vga emulation have some differences between qemu-dm
> > and unstream qemu ?
> >
> > -Gonglei
> I did test on cirrus vga a long time ago, last was on videoram settings
> patch.
> Try to increase videoram setting to see if you see an increasing in
> performances and/or the problem persists.
> On my tests the performance seem identical.

I set the videoram 8M, because of the upstream qemu will crash if the videoram 
less than 8M On the Xen prlatform, and the qemu's log show:

qemu: hardware error: xen: failed to populate ram at 7fc00000
CPU #0:
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000633
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 ffff0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     00000000 0000ffff
IDT=     00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=0
0000000  
etc...
> Probably the causes of video problems with upstream qemu are some
> hardcoding on xen (probably on hvmloader and fixed seabios tables).
> I wasn't able to found exactly problem.

Next, I will compare them.

-Gonglei


reply via email to

[Prev in Thread] Current Thread [Next in Thread]