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

[Xen-devel] RE: [PATCH] Support swap a page from user space tools -- Was

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: [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: Thu, 19 Mar 2009 21:01:18 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 19 Mar 2009 06:03:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C5E7CB58.57F1%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: <E2263E4A5B2284449EEBD0AAB751098401C7EC069A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C5E7CB58.57F1%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcmodaxGpRh5muaRTCCma6vBJRy3NQAAdKadAAA4ExAAAMDH0QAFXe2A
Thread-topic: [PATCH] Support swap a page from user space tools -- Was RE: [RFC][PATCH] Basic support for page offline
Keir Fraser <mailto:keir.fraser@xxxxxxxxxxxxx> wrote:
> On 19/03/2009 09:57, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
> 
>>> Thirdly, perhaps this makes more sense as a MMU_* op hanging off
>>> mmu_update()? That call takes pairs of u64 values, which could give you
>>> the space you require. Then you can add a nice comment explaining how
>>> your new command differs from MMU_NORMAL_PT_UPDATE.
>> 
>> I turn to the mmu_ext_op because it has only 1 entry left. So do you mean
>> it is ok to be there?
> 
> Yes, I think it makes most sense there. It's close in behaviour to
> MMU_NORMAL_PT_UPDATE, except for the 'foreigness'.
> 
> -- Keir

This is updated version.
Instead of add a new mmu_*op, I try to change the  MMU_NORMAL_PT_UPDATE to 
support update foreign page table. There will be some restirction for it, 
including the pagetable and the new mfn pointed should be owned by same domain, 
and the domain should be suspeneded already. The update_foregin_pt.patch is for 
this. I'm not sure if this method is feasible.

The exchange_page.patch is to replace a mfn with a new one. Although there is 
already a memory_exchange hypercall, but that hypercall will not accept new 
page, add that support will break current ABI. Also it does not support foreign 
domain. This function add those support

The other two have not much changes. The only change is the user space tools 
need two hypercall, one is to update the page table, while the second is to 
exchange the pages.

Please have a look on it.

Thanks
Yunhong Jiang

Attachment: writable_p2m.patch
Description: writable_p2m.patch

Attachment: update_foriegn_pt.patch
Description: update_foriegn_pt.patch

Attachment: free_page.patch
Description: free_page.patch

Attachment: exchange_page.patch
Description: exchange_page.patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>