[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [PATCH] Support swap a page from user space tools-- Was RE: [RFC][PATCH] Basic support for page offline



On 20/03/2009 09:42, "Jan Beulich" <jbeulich@xxxxxxxxxx> 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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.