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: [RFC][PATCH] Basic support for page offline

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] RE: [RFC][PATCH] Basic support for page offline
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Thu, 19 Feb 2009 22:37:56 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 19 Feb 2009 06:38:29 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <E2263E4A5B2284449EEBD0AAB751098401C7AAC751@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <E2263E4A5B2284449EEBD0AAB751098401C781605D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20090213170341.GC17060@xxxxxxxxxxxxxxxxxxxxx> <E2263E4A5B2284449EEBD0AAB751098401C796A70E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20090216143122.GD17060@xxxxxxxxxxxxxxxxxxxxx> <E2263E4A5B2284449EEBD0AAB751098401C7A47FED@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20090218152020.GB28209@xxxxxxxxxxxxxxxxxxxxx> <E2263E4A5B2284449EEBD0AAB751098401C7AAC751@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcmR3G/kLTMb1wpeRHKE7dRCJ6fwhwAiY1SAAA4FPxA=
Thread-topic: [RFC][PATCH] Basic support for page offline
>> It should be possible to have the tools do all the PTE manipulations
>> with MMU update hypercalls (I think -- Keir may correct me here). Then
>> the final hypercall to surrender the page will fail if the grant tables
>> are wrong; if it does, put the PTEs back and fall back to a live
>> migration.  Isn't that what your in-xen code does anyway?

Tim, after checking the code more carefully, seems currently the MMU update 
hypercalls (including mod_lx_entry ) assume it is for current domain, while in 
our usage model, it will update MMU for other domain, so I will try to do 
following changes: 1) change mod_lx_entry() to get a domain parameter 2) Add a 
new hypercall (or a new command to do_mmu_update ) to update the MMU for other 
domain. I'm not sure if there are other usage model for such requirement, and 
if such changes acceptable? Any feedback is welcome.

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