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

Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers in Xen


  • To: "Tim (Xen.org)" <tim@xxxxxxx>
  • From: Robert Phillips <robert.phillips@xxxxxxxxxx>
  • Date: Tue, 27 Nov 2012 10:58:59 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc: "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Tue, 27 Nov 2012 15:59:46 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac3DNFX5J8zQU2vnSVqGZuymYwiQ+AJgyYQg
  • Thread-topic: [Xen-devel] [PATCH] Provide support for multiple frame buffers in Xen

Hi,

The updated patch was sent out just a few minutes ago.


> -----Original Message-----
> From: Tim Deegan [mailto:tim@xxxxxxx]
> Sent: Thursday, November 15, 2012 8:23 AM
> To: Robert Phillips
> Cc: xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers
> in Xen
> 
> Hi,
> 
> We're very nearly there now.  I think I agree on almost all the technical
> decisions but there are still a few things to tidy up (some of which I
> mentioned before).
> 
> At 16:31 -0500 on 12 Nov (1352737913), Robert Phillips wrote:
> > Support is provided for both shadow and hardware assisted paging (HAP)
> modes.
> > This code bookkeeps the set of video frame buffers (vram), detects
> > when the guest has modified any of those buffers and, upon request,
> > returns a bitmap of the modified pages.
> > This lets other software components re-paint the portions of the monitor
> (or monitors) that have changed.
> > Each monitor has a frame buffer of some size at some position in guest
> physical memory.
> > The set of frame buffers being tracked can change over time as monitors
> are plugged and unplugged.
> > (Version 3 of this patch.)
> 
> Please linewrap at something less than 80 characters.

Done

> 
> > diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
> > index eea5555..e374aac 100644
> > --- a/xen/arch/x86/hvm/Makefile
> > +++ b/xen/arch/x86/hvm/Makefile
> > @@ -22,4 +22,4 @@ obj-y += vlapic.o
> >  obj-y += vmsi.o
> >  obj-y += vpic.o
> >  obj-y += vpt.o
> > -obj-y += vpmu.o
> > \ No newline at end of file
> > +obj-y += vpmu.o
> 
> This is an unrelated fix, so doesn't belong in this changeset.

Removed

> 
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index
> > 34da2f5..3a3e5e4 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -57,6 +57,7 @@
> >  #include <asm/hvm/cacheattr.h>
> >  #include <asm/hvm/trace.h>
> >  #include <asm/hvm/nestedhvm.h>
> > +#include <asm/dirty_vram.h>
> >  #include <asm/mtrr.h>
> >  #include <asm/apic.h>
> >  #include <public/sched.h>
> > @@ -66,6 +67,7 @@
> >  #include <asm/mem_event.h>
> >  #include <asm/mem_access.h>
> >  #include <public/mem_event.h>
> > +#include "../mm/mm-locks.h"
> >
> >  bool_t __read_mostly hvm_enabled;
> >
> > @@ -1433,8 +1435,20 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
> >           */
> >          if ( access_w )
> >          {
> > +            p2m_type_t pt;
> > +            pt = p2m_change_type(v->domain, gfn, p2m_ram_logdirty,
> > + p2m_ram_rw);
> > +
> > +            paging_lock(v->domain);
> > +            if ( pt == p2m_ram_logdirty )
> > +            {
> > +                dv_range_t *range;
> > +                v->domain->arch.paging.log_dirty.dirty_count++;
> > +                range = dirty_vram_range_find_gfn(v->domain, gfn);
> > +                if ( range )
> > +                    range->dirty_count++;
> > +            }
> >              paging_mark_dirty(v->domain, mfn_x(mfn));
> > -            p2m_change_type(v->domain, gfn, p2m_ram_logdirty,
> p2m_ram_rw);
> > +            paging_unlock(v->domain);
> 
> This is much nicer than the previous version, but I think it would be even
> better if this bookkeeping went into paging_mark_dirty() so that the other
> callers of paging_mark_dirty() also DTRT with the vram map.
> That would avoid leaking mm-locks.h into this non-mm code, too.
> 
> Then this change becomes just swapping the order of the two lines (and
> perhaps a comment to say why).

Done.  I had to split paging_mark_dirty() into two functions -- the old 
function does the gfn-to-mfn translation and then calls the new function 
paging_mark_dirty_gpfn() which does the heavy lifiting.  
The code above now calls the new function thereby bypassing the gfn-to-mfn 
translation.

> 
> > diff --git a/xen/arch/x86/mm/dirty_vram.c
> > b/xen/arch/x86/mm/dirty_vram.c new file mode 100644 index
> > 0000000..e3c7c1f
> > --- /dev/null
> > +++ b/xen/arch/x86/mm/dirty_vram.c
> > @@ -0,0 +1,992 @@
> > +/*
> > + * arch/x86/mm/dirty_vram.c: Bookkeep/query dirty VRAM pages
> > + * with support for multiple frame buffers.
> > + *
> > + * Copyright (c) 2012, Citrix Systems, Inc. (Robert Phillips)
> 
> Please bring in the copyright and authorship notices for the files you copied
> code from.  That's at least mm/shadow/common.c and mm/hap/hap.c.

Done

> 
> Apart from that this is looking good.
> 
> Are you willing to take on maintainership of this feature (that is, to respond
> to questions and fix bugs)? 

Yes

 >If so, we should make an update to the
> MAINTAINERS file for xen/arch/x86/mm/dirty_vram.c and xen/include/asm-
> x86/dirty_vram.h.  That can happen separately, as it'll need an ack from the
> other maintainers.
> 
> Cheers,
> 
> Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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