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/
Home Products Support Community News


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

To: "Rik van Riel" <riel@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Re: [PATCH 2/2] Virtual frame buffer: user space backend
From: "Christian Limpach" <christian.limpach@xxxxxxxxx>
Date: Sat, 8 Jul 2006 02:38:00 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Anthony Liguori <anthony@xxxxxxxxxxxxx>
Delivery-date: Fri, 07 Jul 2006 18:38:21 -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=AhPruwUtm+UkXpQpVPsdncgDz0k0ztfo+AgACm3yWLFWIWnSvablhEwYRGuTj2SyEMNBjPwG2WUyv3CrCeMZJa5lesxchWuZR03PO4skbroHEAyluIzwkylT9e/j5GkHlfRiTsDQFgew1C+0+n9kTyTeCpCjSwrPt2bADa51fec=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44AEFDDE.3070504@xxxxxxxxxx>
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: <87ac80ghox.fsf@xxxxxxxxxxxxxxxxx> <871wtcghmr.fsf@xxxxxxxxxxxxxxxxx> <3d8eece20607070957p2d6bb1e5o7febaa5ca124429d@xxxxxxxxxxxxxx> <pan.2006.> <3d8eece20607071133m10b3a279hac1229bdcdf38bf4@xxxxxxxxxxxxxx> <pan.2006.> <3d8eece20607071550i7fcc98d7o634db68ec6d25b9c@xxxxxxxxxxxxxx> <44AEFDDE.3070504@xxxxxxxxxx>
Reply-to: Christian.Limpach@xxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 7/8/06, Rik van Riel <riel@xxxxxxxxxx> wrote:
Christian Limpach wrote:
> On 7/7/06, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote:

>> Instead of switching bitmaps, why not
>> just have the backend and frontend share a bitmap and do atomic get/sets
>> on it?
> Because we'd like to avoid atomic operations.

Atomic should not be needed.  Just synchronized access, ie.
no unexpected behaviour and proper read/write smp barriers.

You're right and now I remember that we didn't want the switching
bitmaps because of atomic updates to it but because we need to publish
the dirty bit information to the backend only after we've cleared the
dirty bits in the pagetables mapping the framebuffer in fully
virtualized guests, i.e.:
- scan and clear the pagetable dirty bits and update the dirty bitmap
- issue tlb flush across cpus
- let the backend act on the dirty bitmap
If we let the backend act on the dirty bitmap before we flush the tlb
across cpus, another cpu can already dirty a page again before the tlb
flush, the pagetable dirty bit doesn't get set for that access and if
the backend has already acted on the bit in the dirty bitmap, the
update will get lost.
By switching bitmaps, we avoid having to merge the bitmap we build in
the first step above into a single shared bitmap.


Xen-devel mailing list