Donald,
>Are you accessing the guest from the serial line rather than the VGA
console?
I'm sure that I'm accessing the guest from the VGA console.
>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 }
After making these changes, I did a 'make && make install' from the
tools/ioemu directory to rebuild the qemu-dm binary.
The guests still behave normally after commenting out calls to
vram_dirty(), and these changes cause the CPU% to drop from 20 to about
8.
>there's a shadow frame buffer that `vram_dirty' compares to see if the
HVM guest has modified it's frame buffer
What could be causing the screen to be updated if vram_dirty() isn't
even being called here to compare the shadow frame buffer with the HVMs'
frame buffer? Is any one else seeing this?
Thanks for all of your help,
T. McAfee
Xen Testing
-----Original Message-----
From: Dugger, Donald D [mailto:donald.d.dugger@xxxxxxxxx]
Sent: Wednesday, September 20, 2006 5:40 PM
To: Anthony Liguori; McAfee, Tommie M
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] qemu-dm performance
Since I wrote the code all I can do is say that Anthony is completely
correct, there's a shadow frame buffer that `vram_dirty' compares to see
if the HVM guest has modified it's frame buffer. Deleting this function
should result in a blank VGA screen for your HVM guest, I'm really
curious how you got this to work. Are you accessing the guest from the
serial line rather than the VGA console?
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Donald.D.Dugger@xxxxxxxxx
Ph: (303)443-3786
>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
>Anthony Liguori
>Sent: Wednesday, September 20, 2006 2:13 PM
>To: Tommie McAfee
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [Xen-devel] qemu-dm performance
>
>There was a long thread about this topic already plus a patch floating
>around. I don't think vram_dirty is the problem.
>
>vram_dirty seems to be Xen-specific. Presumably, since we map the
>framebuffer directly into the guest, we cannot use write-faulting
>anymore to track dirtying. Instead, it looks like we rely on a double
>buffer to determine which portions of the screen change.
>
>Regards,
>
>Anthony Liguori
>
>Tommie McAfee wrote:
>> I've been investigating why qemu-dm is causing %CPU to be high when
>> viewing fully vitalized guests with vncviewer( about 20% usage ).
>>
>> I've looked at the code, and one area that I'm curious about is the
>> vram_dirty() function in tools/ioemu/hw/vga.c. Please
>correct me if I'm
>> wrong, but vram_dirty() seems to be using SSE inline functions to
>> optimize it's
>bit-shifting/masking/loading/storing/comparison operations
>> to see if dirty bits need to be set for a page within the
>shadow table.
>> Also, I used gdb to make sure that I'm really executing the SSE
>> optimized version of vram_dirty() that utilizes xmm0 registers.
>>
>> So out of curiosity, I decided to comment out calls to
>vram_dirty() from
>> vga_draw_graphic() and the guests still behave normally, but CPU% now
>> drops to 8%. I know this is silly, and that I should expect
>a CPU drop
>> for commenting out code, but why is vram_dirty() adding 12% CPU
>> utilization when it can be commented out without crashing my
>viewer, and
>> without me even noticing a difference in the guests behavior? Can
>> someone help me to understand the purpose vram_dirty serves
>and perhaps
>> why it seems 2 be so CPU intensive without really changing the way my
>> virtual guest behaves?
>>
>> Also, where else should I look in the code for possible
>explanations to
>> why qemu-dm uses 20% CPU simply to view a guest. All comments and
>> suggestions regarding this matter are appreciated,
>>
>> thx,
>>
>> T. McAfee
>> Xen Testing
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>>
>>
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home