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


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: 26 Jul 2005 14:44:29 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Michael Vrable <mvrable@xxxxxxxxxxx>
Delivery-date: Tue, 26 Jul 2005 12:43:41 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D28275D@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>
Organization: SUSE Labs, Berlin
References: <A95E2296287EAD4EB592B5DEEFCE0E9D28275D@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
"Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx> writes:

> The shadow32.c file (formerly shadow.c) still exists because it's had
> more testing than the new file, and we want both in the tree until we're
> convinced there's been no regression between the two. We'll then delete
> shadow32 and compile shadow.c in 32 bit mode. Base any new development
> on the new shadow.c

While we are at it and I'll go work on shadow mode as well soon some
followup questions ;)

 * "normal" shadow mode is almost identical to shadow mode off,
   i.e. the guest does machine<=>phys translations.  The guest hasn't
   to mark pages containing page tables r/o because xen can do that in
   the shadow tables.

 * In "translated" shadow mode the guest kernel handles a linear
   physical address space starting at addr zero and xen does the
   machine<=>phys translations when copying guest tables into the
   shadow page tables.

 * "external" is translated shadow mode + separated address space,
   i.e. no hypervisor window in the address space, used for vt.

Correct so far?

Enabling/switching shadow modes works by dropping all shadow tables,
start with a zero-ed toplevel page directory (almost, except
hypervisor window) and update the shadow pagetable tree as faults are
coming in.  Correct?

But it's not clear to me how the transition between "normal" and
"translated" shadow mode works.  Does that need support by the guest


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

Xen-devel mailing list