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] Re: [PATCH] Support swap a page from user space tools --

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: [PATCH] Support swap a page from user space tools -- Was RE: [RFC][PATCH] Basic support for page offline
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Fri, 20 Mar 2009 10:52:36 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 19 Mar 2009 19:54:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C5E8270F.48DA%keir.fraser@xxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <E2263E4A5B2284449EEBD0AAB751098401C7EC072A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C5E8270F.48DA%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcmodaxGpRh5muaRTCCma6vBJRy3NQAAdKadAAA4ExAAAMDH0QAFXe2AAAE9geEAAiC0AAAAdVtEAAAjjoAABFWZhwAT5hzw
Thread-topic: [Xen-devel] Re: [PATCH] Support swap a page from user space tools -- Was RE: [RFC][PATCH] Basic support for page offline
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx <> wrote:
> On 19/03/2009 14:42, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
> 
>>>> It is ok for us to use an arbitrary new mfn, and then do the
>>>> update_entry. But what happen if this process failed and we want to turn
>>>> back to the old page? We still need this mechanism at that situation.
>>> 
>>> If what failed? The update_entry? How could that happen?
>> 
>> Per discussion before, when the page is granted to other domain, then
>> after we update all entry, there will still have reference to left.
> 
> Hmmm I don't really understand.

The basic idea to offline a page is:

1) mark a page offline pending
2) If the page is owned by a HVM domain, user have to live migrate it
3) If the page is owned by a PV domain, we will try to exchange the offline 
pending page to a new one and free the old page. (This is target of this series 
patches).

The method to exchange the offline pending page for PV domain is:
1) Suspend the guest.
2) Allocate a new page for the guest
3) Get a copy for the content
4) User space tools will scan all page table page to see if any reference to 
the offending page, if yes, then it will hypercall to Xen to replace the entry 
to point to the new one. (Through the mmu_*ops)
5) After update all page tables, user space tools will try to exchange the old 
page with the new page. If the new mfn has no reference anymore (i.e. 
count_info & count_mask = 1), the exchange will update the m2p and return 
success, otherwise it will return fail. (the page may be referenced by other 
domain, like grant table or foreign mapped).
6) If step 5 is success, user space tools will update the content of the new 
page and the p2m table, else it will try to undo step 4 to revert page table 
changes.
7) Resume the guest.

This requires we need to allocate the new page before the exchange call and we 
have to pass both old_mfn and new_mfn in step 5 to exchange the memory. 
However, current hypercall will always allocate a new page to replace the old 
one.

Currently I try to add a new hypercall for this purpose. 

Maybe we can enhance the current XENMEM_exchange to accept a mem_flags, when 
that flag is set, the exch.out.extent_start will be the new_mfn instead of the 
gpfn, and the gpfn will be always same as corresponding gpfn in the 
exch.in.ext_start. But I do think this is a bit tricky, it change the meaning 
of exch.out.extent_start and how the gpn is pass down. 

Thanks
Yunhong Jiang





> 
> K.


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

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