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] [PATCH] VGA acceleration utilizing shadow logdirtyfuncti

To: "Huang, Xinmei" <xinmei.huang@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] VGA acceleration utilizing shadow logdirtyfunctionality
From: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>
Date: Thu, 17 May 2007 11:39:30 +0100
Delivery-date: Thu, 17 May 2007 03:38:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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: <823A93EED437D048963A3697DB0E35DE3BF733@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceYZSldSoX4x3tKTEyhYB9cAR9S5AAA7FKwAADR1sA=
Thread-topic: [Xen-devel] [PATCH] VGA acceleration utilizing shadow logdirtyfunctionality
> Shadow log dirty mode is enabled to track vram pages dirty status.When
> drawing guest graphic screen, VGA dm gets the dirty bitmap of mmio
> through one shadow control hypercall. VGA
> dm updates dirty pages of vram according to the dirty
> marks the vram pages read-only for the guest, in order to log the
> access to these pages from the guest. Once a vram page is written and
> logged by hypervisor, it becomes r/w for this guest. After returning
> dirty bitmap to VGA dm, hypervisor re-marks these vram pages read-only
> for next round.
> This patch would save the heavy overhead of current vram dirty
> algorithm(compare between vram and vram copy of last round), albeit
> brings overhead of ram page fault for dirty status log.

Have you any measurements showing what the overhead for graphics
intensive applications is, e.g. a video player?

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. 

When qemu requests a new bitmap of updates, xen should
locked-test-and-clear the dirty bit to zero, filling in the bitmap. 

If more we detect more than one PTE mapping a framebuffer page we can
disable the optimization (the read bitmap function would return a
special code indicating that a full scan is required).

Qemu would register an extent of GPFNs with Xen that are to have the
shadow PTE's mapping them tracked. We can assume that they will be
mapped in a contiguous fashion in virtual address space, the same
virtual address in all the page tables the guest has (i.e. they are
kernel mappings). This means we only need to keep track of one virtual
address in order to be able to walk the pagetables and do the scan.

I guess we could use a hybrid approach where after some number of
'empty' scans we have qemu instruct xen to remove all the writeable
mappings to the pages, so it no longer needs to scan and can get an
indication of when the framebuffer is being updated by the guest again.


Xen-devel mailing list