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

Re: [Xen-devel] Shadow Code Reorganization

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Shadow Code Reorganization
From: Gerd Knorr <kraxel@xxxxxxx>
Date: Wed, 27 Jul 2005 09:27:52 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Michael Vrable <mvrable@xxxxxxxxxxx>
Delivery-date: Wed, 27 Jul 2005 07:29:09 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D2827AE@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <A95E2296287EAD4EB592B5DEEFCE0E9D2827AE@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
  Hi,

> Depends what you mean by "normal". The mode that we need for migration
> of a paravirtualized guest is log_dity but with refcounts in the *guest*
> pages i.e. SHM_refcounts is not set.

Ah, *that* the log_dirty option is good for.  Looked like some
performance measurement counter on a first quick look ...

> > But it's not clear to me how the transition between "normal" 
> > and "translated" shadow mode works.  Does that need support 
> > by the guest os?
> 
> Guests typically don't make this transition -- it's currently a guest
> compile time option whether to use the paravirtualized or translated
> shadow mode interface. This isn't strictly necessary.

Ok, more general:  How does xen and/or the guest os handle the
changes in machine<=>phys mapping as they happen on
suspend/resume and migration because the guest gets a different
set of machine pages?  Especially the guest page table updates?

  Gerd

-- 
panic("it works"); /* avoid being flooded with debug messages */

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