RE: [Xen-devel] [PATCH] VGA acceleration utilizing shadow logdirtyfunctionality

["Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>]

> 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
space
> through one shadow control hypercall. VGA
> dm updates dirty pages of vram according to the dirty
bitmap.Hypervisor
> marks the vram pages read-only for the guest, in order to log the
write
> 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
the
> 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.

Thanks,
Ian







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