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

RE: [Xen-devel] [PATCH] VGA acceleration utilizing shadowlogdirtyfunctionality


  • To: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>, "Huang, Xinmei" <xinmei.huang@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
  • Date: Fri, 18 May 2007 13:28:04 +0800
  • Delivery-date: Thu, 17 May 2007 22:26:28 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AceYZSldSoX4x3tKTEyhYB9cAR9S5AAA7FKwAADR1sAAKBiQkA==
  • Thread-topic: [Xen-devel] [PATCH] VGA acceleration utilizing shadowlogdirtyfunctionality

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote:
> I think the most efficient way of accelerating the framebuffer scan is
> to use the dirty bits in the PTEs that map it. Typically, most
> OSes will
> use just a single set of PTEs for mapping the framebuffer, and
> it should
> be possible to scan these to fill out a bitmap of what's been changed.

I think we are saying shadow PTEs here, a potential problem here is that
the shadow PTEs may disappear for some reason like recycling etc.

But we can walkaround this like:
        Keep track of guest frame's dirty bitmap in hypervisor and
update it 
if a dirty shadow PTE for VRAM is recycled. In this way we keep the lost

info though a little bit ugly.

Is this what you want? BTW, Do u agree we can assume there is no
multiple 
map of guest VRAM for now, othrewise the patch need more to do?

Eddie

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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