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

[Markus Armbruster <armbru@xxxxxxxxxx>]

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