| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: Re: [PATCH 2/2] Virtual frame buffer: user space bac
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.
christian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home