On Fri, 07 Jul 2006 19:33:24 +0100, Christian Limpach wrote:
> 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?
It's no so much flooding the ring, but what to do when the ring is full.
The idea would be to push updates on the ring until it's full, and then
start storing the largest update. It's just laziness to avoid buffering
within the driver.
> 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.
Actually, a shared dirty bitmap is exactly what I wanted to do for the
next phase :-)
> 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
Since the best we can do is page granularity (for now), why not just have
a bitmap represent the dirty pages? Instead of switching bitmaps, why not
just have the backend and frontend share a bitmap and do atomic get/sets
on it?
For instance, when the front-end timer goes off, it walks the dirty
page list, and sets the bit of the corresponding page *after* calling
zap_page_range and before releasing the lock.
The back-end has it's own timer (which may or may not be the same as the
front-end). It walks through and does an atomic test-and-set to 0. With
the QEMU VNC code, it would then mark all tiles that fall within this
page. Those tiles happen to be 16x1 right now.
Not requiring communication back and forth between the domains is pretty
useful I think (especially if dom0 is on a different PCPU).
Plus, I think the size of your tiling probably depends on however the
backend is exposing things. Having tiles <= 16x16 is pretty useful for
implementing Hextile in VNC for instance.
We could even have the bitmap size be specified by the front-end. This
way it could be set for 4k right now, but in the future, to something like
32 bytes.
I think the key point is to have the bitmap represent linear regions of
framebuffer memory instead of logical rectangles within the current
resolution.
Just some random thoughts..
Regards,
Anthony Liguori
> - 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.
>
> christian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home