From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Knorr Subject: Re: Shadow Code Reorganization Date: Wed, 27 Jul 2005 09:27:52 +0200 Message-ID: <20050727072752.GB21834@bytesex> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: xen-devel@lists.xensource.com, Michael Vrable List-Id: xen-devel@lists.xenproject.org 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 */