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?

To: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] PVFB: Add refresh period to XenStore parameters?
From: Markus Armbruster <armbru@xxxxxxxxxx>
Date: Mon, 05 May 2008 10:26:14 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 05 May 2008 01:26:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080502160638.GG4819@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> (Samuel Thibault's message of "Fri\, 2 May 2008 17\:06\:38 +0100")
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20080229120806.GA8268@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <873ar7ptvh.fsf@xxxxxxxxxxxxxxxxx> <20080303191804.GA11699@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <873ar68spy.fsf@xxxxxxxxxxxxxxxxx> <20080304144952.GA9230@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <873ar67anv.fsf@xxxxxxxxxxxxxxxxx> <20080304161220.GA9852@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080501175536.GV4797@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080502160638.GG4819@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx> writes:

> Samuel Thibault, le Thu 01 May 2008 18:55:36 +0100, a écrit :
>> Getting back to that old issue.
>> 
>> Samuel Thibault, le Tue 04 Mar 2008 16:12:20 +0000, a écrit :
>> > > * If the frontend can track changes efficiently, it sends update
>> > >   messages to the backend, which can use them to only redisplay
>> > >   changed areas.
>> > 
>> > Well, that was actually my next target :)
>> > (but for that we badly need the resize/redepth support).
>> > 
>> > 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.
>> 
>> What could be done is to make the backend set request-update to 0 when
>> the window is minimized, which makes the frontend understand that there
>> is temporarily no need to send updates any more, and set it back to 1
>> when the window is restored.  Would that be OK?
>
> Here is how it would be implemented:
>
>
> ioemu: transmit idleness information to avoid useless polls
>
> Signed-off-by: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>

Any particular reason for going through xenstore instead of the event
rings?

If I read your patch correctly, xenfb_read_frontend_fb_config() sets
request-update in xenstore depending on xenfb->ds->idle, during
startup.  The only place that changes it is xenfb_update(), which is
#ifdef CONFIG_STUBDOM.

What if ds->idle is true when xenfb_read_frontend_fb_config() runs
during startup of the ordinary (!CONFIG_STUBDOM) backend?  Can this
happen?  If not, why?

Other than that, the change seems to affect only Mini-OS and
CONFIG_STUBDOM, which are both outside the area of my expertise (and
frankly, interest).

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