All of lore.kernel.org
 help / color / mirror / Atom feed
From: Samuel Thibault <samuel.thibault@eu.citrix.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [RFC] PVFB: Add refresh period to XenStore parameters?
Date: Tue, 4 Mar 2008 16:12:20 +0000	[thread overview]
Message-ID: <20080304161220.GA9852@implementation.uk.xensource.com> (raw)
In-Reply-To: <873ar67anv.fsf@pike.pond.sub.org>

Markus Armbruster, le Tue 04 Mar 2008 16:48:20 +0100, a écrit :
> Samuel Thibault <samuel.thibault@eu.citrix.com> 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.

> * 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).

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

  reply	other threads:[~2008-03-04 16:12 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-29 12:08 [RFC] PVFB: Add refresh period to XenStore parameters? Samuel Thibault
2008-03-03 11:07 ` Samuel Thibault
2008-03-03 18:03 ` Markus Armbruster
2008-03-03 19:18   ` Samuel Thibault
2008-03-04 12:36     ` Trolle Selander
2008-03-04 14:32     ` Markus Armbruster
2008-03-04 14:49       ` Samuel Thibault
2008-03-04 15:11         ` Samuel Thibault
2008-03-04 15:48         ` Markus Armbruster
2008-03-04 16:12           ` Samuel Thibault [this message]
2008-03-04 17:06             ` Markus Armbruster
2008-03-04 17:19               ` Samuel Thibault
2008-03-05  8:03                 ` Markus Armbruster
2008-03-05  9:59                   ` Samuel Thibault
2008-05-01 17:55             ` Samuel Thibault
2008-05-02 16:06               ` Samuel Thibault
2008-05-05  8:26                 ` Markus Armbruster
2008-05-05  9:18                   ` Samuel Thibault
2008-05-05  9:58                     ` Markus Armbruster
2008-05-05 10:21                       ` Samuel Thibault
2008-05-05 16:50                       ` Samuel Thibault
2008-05-06 13:50                         ` Markus Armbruster
2008-05-06 14:07                           ` Keir Fraser
2008-05-06 16:32                           ` Samuel Thibault
2008-05-06 16:50                             ` Markus Armbruster
2008-05-06 17:29                               ` Samuel Thibault
2008-05-07 14:43                                 ` Markus Armbruster
2008-05-07 14:54                                   ` Samuel Thibault
2008-05-08  8:25                                     ` Markus Armbruster
2008-05-08 15:01                                       ` Samuel Thibault
2008-05-09  8:43                                         ` Markus Armbruster
2008-05-09 10:31                                           ` Samuel Thibault
2008-05-09 10:48                                             ` Markus Armbruster
2008-05-09 13:43                                               ` Samuel Thibault
2008-03-05 11:19     ` Markus Armbruster
2008-03-05 11:27       ` Samuel Thibault

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080304161220.GA9852@implementation.uk.xensource.com \
    --to=samuel.thibault@eu.citrix.com \
    --cc=armbru@redhat.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.