[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [PATCH 2/2] Virtual frame buffer: user space backend

  • To: "Anthony Liguori" <anthony@xxxxxxxxxxxxx>
  • From: "Christian Limpach" <christian.limpach@xxxxxxxxx>
  • Date: Fri, 7 Jul 2006 19:33:24 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 07 Jul 2006 11:33:59 -0700
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RKW28aq1mP1v6o+1v7wVDykOyLI0j0+48NW+otttsFKOqF/B+2XwuSY9pefFRiC5IzDSVBiYr8WAMxzSojRCv69nMc1RbN0Kmz8CV7bHqUAjGprwlmRdI/nFpOpcYgHVdmTpobRiLFWTIkHERQp7yA8nMpU733M3/vBYL9wFOMo=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On 7/7/06, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote:
On Fri, 07 Jul 2006 17:57:52 +0100, Christian Limpach wrote:

> On 6/26/06, Markus Armbruster <armbru@xxxxxxxxxx> wrote:
>> Straightforward conversion to Xenstore.
>> Applies to hg repository at http://hg.codemonkey.ws/vncfb
> Ideally, we'd move qemu's vnc support into a library to make it reusable.

I had considered this.  It's a little awkward since b/c of the dependence
on QEMU's async IO routines but it wouldn't be that bad.

At this point, it probably makes most sense to communicate the linear
offsets within the framebuffer that are dirty instead of computing a rect.
 Since the QEMU VNC code already does rectangle finding and maintains
 dirty tile bitmap, we don't really have to attempt to find the rect in
the frontend at all.

Well, I can only guess what you were thinking when you wrote the
framebuffer code, but isn't the current code merging updates to a
single update at the configured framerate and aren't you doing that to
avoid flooding the ring?  And if that's the case, wouldn't
communicating the linear offsets have the same problems?

We think that having a dirty bitmap as part of the frontend/backend
protocol would be a good thing and are planning to use the same
protocol with dirty bit scanning in the pagetables mapping the video
ram of HVM guests.  It would work like this:
- have a page with two dirty bitmaps, each 64bit by 128 plus and
indicator which bitmap is the active bitmap from the frontends point
of view
- [1] frontend records dirty information in the active bitmap
- timer or external event causes backend to check if the indicator has changed
- if not, then it either synchronously requests the frontend to switch
bitmap or waits some more
- backend then scans/clears the inactive bitmap
- backend requests frontend to set a timer a few ms before the next
time the backend wants to scan a bitmap
- when the frontend's timer fires, frontend switches bitmap and
updates the indicator
- go back to [1]

This allows the backend to control the rate at which it wants to scan
the bitmap without having to synchronously ask the frontend to flush
the bitmap it is updating.

We tile the screen in upto 64 vertical strips and upto 128 horizontal
strips.  We could move the indicator outside of this page and get
finer grained updates.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.