From mboxrd@z Thu Jan  1 00:00:00 1970
From: Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: Re: [PATCH] Support swap a page from user  space
	tools-- Was RE: [RFC][PATCH] Basic support for page  offline
Date: Fri, 20 Mar 2009 09:48:32 +0000
Message-ID: <C5E916F0.59D2%keir.fraser@eu.citrix.com>
References: <49C37322.76E4.0078.0@novell.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <49C37322.76E4.0078.0@novell.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Jan Beulich <jbeulich@novell.com>, Yunhong Jiang <yunhong.jiang@intel.com>
Cc: Tim Deegan <Tim.Deegan@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

On 20/03/2009 09:42, "Jan Beulich" <jbeulich@novell.com> wrote:

>> Ah yes, I found the email now. Well I'm still confused as to why it is
>> needed. It seems to me you could scan for all PTEs mapping old_pfn, stash
>> them in a list and temporarily make them not-present, and take a copy of
>> old_pfn. Then do a normal XENMEM_exchange: on failure revert all PTEs, on
>> success switch over all PTEs and copy old_pfn data into new_pfn. Well it is
>> more hypercalls (two updates per PTE) I suppose, but I doubt this matters
>> unless you're offlining a lot of pages, and we don't support offlining
>> memory banks really at the moment. Also some of this will potentially batch
>> up into multicalls or MMUOP_ lists nicely anyway.
> 
> A normal XENMEM_exchange wouldn't work here, would it? The old page
> must have no other references for it to succeed, and will go back to the
> allocator right afterwards - it's contents won't be recoverable. This would
> probably require a new flag to XENMEM_exchange (which I agree would be
> much simpler than adding a full-blown new [sub-]hypercall).

If the XENMEM_exchange succeeds then you don't need the old_pfn any more.
You only need recover if the excahnge fails, and in that case the page isn't
released by XENMEM_exchange. This is my understanding at least. :-) I'm
trying to work out whether I'm wrong or whether the extra Xen bits are not
needed.

 -- Keir