Xen devel - May 2007 - [PATCH] VGA acceleration utilizing shadow logdirty functionality

Hi all, 

here''s a patch for vga acceleration. Can anyone give some suggestions ?

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. 

Any suggesion will be really appreciated.

Thanks !




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

> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

xen-devel-bounces@lists.xensource.com 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@lists.xensource.com
http://lists.xensource.com/xen-devel

> xen-devel-bounces@lists.xensource.com 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.
That shouldn''t happen too frequently. 

I think the easiest way of handling this is to return dirty status for
the PTEs we don''t know about, and then reshadow the missing page so
that
we''ll know next time around.

We''re only talking about a couple of pages here, so we''re not
going to
perturb all the shadow cache cleverness in any significant way.
> 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.
Lets try and keep it simple :)
> 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?

Absolutely.

Best,
Ian


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