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: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Subject: [Xen-devel] Re: [RFC][PATCH] Basic support for page offline
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Date: Mon, 2 Mar 2009 11:56:07 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Mon, 02 Mar 2009 03:56:36 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <E2263E4A5B2284449EEBD0AAB751098401C7AAC886@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> <E2263E4A5B2284449EEBD0AAB751098401C7AAC886@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.17 (2007-11-01)
At 14:37 +0000 on 19 Feb (1235054276), Jiang, Yunhong wrote:
> 
> >> 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.
> 

Sorry for the delay -- I was travelling around the summit and this got
lost.  Yes, I think this is an OK approach.  I doubt there will be many
other users of such a hypercall since most OSes will get upset by their
PTEs changing under their feet, but I prefer it to the current patch.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

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