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] [RFC] New shadow paging code

To: "Mike D. Day" <ncmike@xxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] New shadow paging code
From: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Date: Mon, 17 Jul 2006 16:30:26 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 17 Jul 2006 08:31:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44BB9F68.8070803@xxxxxxxxxx>
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: <20060714153907.GJ3328@xxxxxxxxxxxxxxxxxxxxx> <44BB9F68.8070803@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.11+cvs20060403
At 10:32 -0400 on 17 Jul (1153132328), Mike D. Day wrote:
> Can you explain how this works? It is not obvious to me from the patch. 
> In shadow2.c there is in fact a whole string of #ifs. What mechanism 
> causes the file to be multiply compiled? Or do I misunderstand how this 
> works?
It's handled by the makefile runes that go into in xen/arch/x86/Makefile.
For each type of host, a number of shadow2_gX_on_sY.o files are 
required, and the rule for shadow2_%.o compiles shadow2.c with the
appropriate definitions for GUEST_PAGING_LEVELS and SHADOW_PAGING_LEVELS.

> Also, can you comment on the differences and similarities with the 
> shadow code contributed by Ben Thomas?

There are some similarities: for example both patches allocate a pool of
shadow memory for each domain, rather than allocating from domheap on
the fly.  Also, we're currently working on incorporating the idea of
storing guest present/writable bits in the shadow pte for fast-path of
"genuine" faults.

The major difference in structure is that the XI patch keeps the
"out-of-sync" algorithm of the old shadow code, letting guests write to
their pagetables and re-syncing the shadow on a fault.  This works well
for linux's fork()/exit() behaviour, but for Windows, which mostly does
demand paging, it makes the cycle of fault-install-retry rather
expensive.  Instead, the shadow2 patch emulates all writes to
pagetables, without ever letting the guest write to a shadowed page

XI also has a reverse-mapping mechanism for recording where all the
pagetable entries are that reference each page; this doubles the memory
cost of shadow mode, and adds some book-keeping, but avoids having to
search through all the shadows when revoking write access to a guest
page.  We believe it's possible to use heuristics to speed up the
remove-all-writable-mappings process, without the memory overhead.  For
example, just looking in the kernel's linear map works in 99.8% of cases
for Windows 2003 Server.

As for features, XI supports only HVM guests on 64-bit Xen; shadow2
supports 32-bit and PAE Xen as well, and PV guests.  As I understand it,
there is no plan to make XI support any other modes.  XI supports
shadowing superpages directly with superpages, which shadow2 does not



Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>