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] Seamlessly sharing identical memory pages among domains

To: Kip Macy <kmacy@xxxxxxxxxxx>
Subject: Re: [Xen-devel] Seamlessly sharing identical memory pages among domains
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Fri, 21 May 2004 07:56:31 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, "Scheer, Roque" <roque.scheer@xxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Fri, 21 May 2004 07:58:09 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Thu, 20 May 2004 20:58:52 PDT." <20040520205407.Q70577@xxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> >
> > Doing a proper shared cache is slightly trickier given the
> > paravirtualised memory interface -- we'd have to introduce guests
> > to a new kind of write fault: "A write fault has occurred, and
> > you'll have to copy the page because this machine page is
> > immutable as it is already shared with other domains". Modifying
> > Linux to handle this wouldn't be hard.
> 
> Would this just involve adding an extra error code to what x86 already
> uses and then modifying the guest to understand that that error code
> means that the page has to be COWed?

Yep. The only slight subtlety is that that the page in question
may appear in multiple page tables and at multiple VAs: if the
page is truly read-write shared in the guest (e.g. sysv shared
memory [*]) then it it will be necessary to find all the ptes and
patch them to the newly allocated machine frame. I think such
pages are rare, and tracking them down by scanning the list of
vma's that are mapping the object (e.g. a file) in question is
pretty easy and quick. However, this would most sensibly be done
by making minor modifications to architecture independent code,
which is something we try to avoid. I guess we could just have
arch xen grub its way through the higher-level data structures...

Ian

[*] Hmm, do memory mapped files behave like this too? I can't
remember. 


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel