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

["Jan Beulich" <jbeulich@novell.com>]

>>> Keir Fraser <keir.fraser@eu.citrix.com> 20.03.09 10:28 >>>
>On 20/03/2009 09:16, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:
>
>>> Thanks for the description. I guess I will wait for your next
>>> patch, which
>>> should I think at least separate the foreign pagetable update hypercall from
>> 
>> I think I have split that patch last night. There is no foreign page table
>> hypercall anymore, instead, I just tried to enhance the current mmu_op. And
>> this new "weird" swap is now named mmu_ext_exchange_page.(Is it really so
>> weird to just pass the new mfn down?)
>
>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).

Jan