WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [RFC] PVFB: Add refresh period to XenStore parameters?

Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx> writes:

> Markus Armbruster, le Tue 04 Mar 2008 16:48:20 +0100, a écrit :
>> Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx> writes:
>> > Markus Armbruster, le Tue 04 Mar 2008 15:32:57 +0100, a écrit :
>> >> > In my case, I'm using PVFB to expose the stubdomain qemu display.  The
>> >> > problem is that every 30ms, qemu wakes up to memcmp() the whole video
>> >> > memory with a shadow buffer so as to track changes.  If it knew that the
>> >> 
>> >> Wait a second!  You're talking about *your* frontend here, aren't you?
>> >> 
>> >> Maintaining a shadow copy in the frontend (which requires compare and
>> >> copy) to minimize copying in the backend sounds pretty self-defeating
>> >> to me.  Why is this a good idea?
>> >
>> > Because in my case the domain is HVM, and I don't want to trap the
>> > writes to the video RAM since that's awfully slow.
>> >
>> >> Why not refrain from sending update messages and have the backend
>> >> simply redisplay everything?
>> >
>> > Because as explained above, I can't avoid a shadow copy.
>> 
>> I imagine (perhaps naively):
>> 
>> * The domU writes to a framebuffer provided by the frontend.
>>
>> * The framebuffer (not a copy of it) can be shared with the backend,
>>   which only reads.
>
> Well, that's not always the case, when the guest is in text mode for
> instance, the PV shared buffer is converted from the guest text buffer.

Optimize for the common case.  Which I figure is a 32 bpp framebuffer.

Anyway, compare and copy for some legacy 80x25 text mode shouldn't eat
that much CPU.

>> * If the frontend can track changes efficiently, it sends update
>>   messages to the backend, which can use them to only redisplay
>>   changed areas.
>> 
>>   Else the backend needs to assume the worst and periodically
>>   redisplay everything.  It is free to maintain a shadow copy to track
>>   changes and minimize redisplay, if that turns out to be faster.
>> 
>> What's wrong with that?
>
> Well, that was actually my next target :)
> (but for that we badly need the resize/redepth support).

We'll see another iteration of the patch soon, I hope.

> However, that doesn't solve something that still bugs me, which is
> that the VGA emulation layer wakes up every 30ms to just notice that
> the width/height/depth registers didn't change etc. even if the actual
> window is not shown.
>
> Samuel

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