RE: [Xen-devel] qemu-dm performance

["Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>]

SLES uses TightVNC which has a problem with resize events (it doesn't
handle them).  If you replace the VNC client with RealVNC, which handles
resize events, this problem should go away.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Donald.D.Dugger@xxxxxxxxx
Ph: (303)443-3786 

>-----Original Message-----
>From: McAfee, Tommie M [mailto:Tommie.McAfee@xxxxxxxxxx] 
>Sent: Friday, September 22, 2006 12:58 PM
>To: Steven Smith
>Cc: Dugger, Donald D; Anthony Liguori; 
>xen-devel@xxxxxxxxxxxxxxxxxxx; sos22@xxxxxxxxxxxxx
>Subject: RE: [Xen-devel] qemu-dm performance
>
>
>
>Thanks a lot, this fix does reduce qemu overhead.
>
>Also, while testing I noticed a small bug with vncviewer using a
>sles9sp3 guest.  My initial attempt to view a guest causes vnc 
>to render
>a small window that doesn't respond to mouse movements.  I 
>have to close
>this window and then start the vncviewer again to get a resized and
>usable window.  I'm only seeing this on my first attempt to view the
>guest.  Any suggestions?
>
>Thx again for your help,
>
>T. McAfee
>Xen Testing
>
>
>
>-----Original Message-----
>From: Steven Smith [mailto:sos22@xxxxxxxxxxxxxxxx] On Behalf Of Steven
>Smith
>Sent: Thursday, September 21, 2006 3:23 PM
>To: McAfee, Tommie M
>Cc: Dugger, Donald D; Anthony Liguori; xen-devel@xxxxxxxxxxxxxxxxxxx;
>sos22@xxxxxxxxxxxxx
>Subject: Re: [Xen-devel] qemu-dm performance
>
>> >Deleting this function should result in a blank VGA screen for your
>HVM
>> guest,
>> 
>> I not sure why but I'm not seeing this.  Here is what how I commented
>> out vram_dirty (as shown in gdb):
>> 
>> 1563        for (y = 0; y < s->vram_size; y += TARGET_PAGE_SIZE){
>> 1564            /*if (vram_dirty(s, y, TARGET_PAGE_SIZE))
>> 1565                
>cpu_physical_memory_set_dirty(s->vram_offset + y);
>> */
>> 1566        }
>It turns out that there was a bug a little later on which meant that
>the dirty bits were never actually cleared.  Fixing this seems to have
>fairly drastically reduced qemu overhead.  The fix is now present in
>xen-unstable.
>
>Thanks,
>
>Steven.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel