WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH 2/2] xen: Introduce VGA sync dirty bitmap support

To: Jan Kiszka <jan.kiszka@xxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 2/2] xen: Introduce VGA sync dirty bitmap support
From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
Date: Wed, 12 Jan 2011 16:53:19 +0000 (GMT)
Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, QEMU-devel <qemu-devel@xxxxxxxxxx>
Delivery-date: Wed, 12 Jan 2011 08:54:26 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D2D7C67.90801@xxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1294760223-26151-1-git-send-email-anthony.perard@xxxxxxxxxx> <1294760223-26151-3-git-send-email-anthony.perard@xxxxxxxxxx> <4D2D7C67.90801@xxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 1.10 (DEB 962 2008-03-14)
On Wed, 12 Jan 2011, Jan Kiszka wrote:

> Am 11.01.2011 16:37, anthony.perard@xxxxxxxxxx wrote:
> > From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
> >
> > This patch introduces phys memory client for Xen.
> >
> > Only sync dirty_bitmap and set_memory are actually implemented.
> > migration_log will stay empty for the moment.
> >
> > Xen can only log one range for bit change, so only the range in the
> > first call will be synced.
> >
> > Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
> > ---
> >  hw/vga.c   |    7 ++
> >  hw/xen.h   |    2 +
> >  xen-all.c  |  233 
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  xen-stub.c |   11 +++
> >  4 files changed, 253 insertions(+), 0 deletions(-)
> >
> > diff --git a/hw/vga.c b/hw/vga.c
> > index c057f4f..5f7a181 100644
> > --- a/hw/vga.c
> > +++ b/hw/vga.c
> > @@ -29,6 +29,7 @@
> >  #include "pixel_ops.h"
> >  #include "qemu-timer.h"
> >  #include "kvm.h"
> > +#include "xen.h"
> >
> >  //#define DEBUG_VGA
> >  //#define DEBUG_VGA_MEM
> > @@ -1599,6 +1600,9 @@ void vga_dirty_log_start(VGACommonState *s)
> >  {
> >      if (kvm_enabled() && s->map_addr)
> >          kvm_log_start(s->map_addr, s->map_end - s->map_addr);
> > +    if (xen_enabled() && s->map_addr) {
> > +        xen_log_start(s->map_addr, s->map_end - s->map_addr);
> > +    }
> >
> >      if (kvm_enabled() && s->lfb_vram_mapped) {
> >          kvm_log_start(isa_mem_base + 0xa0000, 0x8000);
> > @@ -1616,6 +1620,9 @@ void vga_dirty_log_stop(VGACommonState *s)
> >  {
> >      if (kvm_enabled() && s->map_addr)
> >     kvm_log_stop(s->map_addr, s->map_end - s->map_addr);
> > +    if (xen_enabled() && s->map_addr) {
> > +        xen_log_stop(s->map_addr, s->map_end - s->map_addr);
> > +    }
> >
> >      if (kvm_enabled() && s->lfb_vram_mapped) {
> >     kvm_log_stop(isa_mem_base + 0xa0000, 0x8000);
>
> This is probably the right time to make dirty_log_start/stop callbacks
> in CPUPhysMemoryClient as well. Would remove any KVM or Xen reference
> from vga code.
>
> We just need to think about how to deal with the quirks of its users:
> KVM requires the isa vram to be reported in two chunks, Xen can't handle
> more than one region at all. If Xen is able to filter out those events
> it can handle, we could replace kvm_log_start/stop with some
> cpu_notify_log_start/stop.

The first thing I think of, is to handle only the first call of
_log_start.

The other choice is to sync dirty bitmap only when a call to
xc_domain_add_to_physmap is working. This call is done inside the
set_memory client when the flags is IO_MEM_RAM.

-- 
Anthony PERARD

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