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] [RFC] Nested Paging Live Migration

To: Wei Huang <wei.huang2@xxxxxxx>
Subject: Re: [Xen-devel] [RFC] Nested Paging Live Migration
From: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Date: Wed, 6 Jun 2007 10:54:46 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 06 Jun 2007 02:53:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <46663824.6030200@xxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <7D748C767B7FA541A8AC5504A4C89A23030EF9B2@xxxxxxxxxxxxxxxxx> <20070601161726.GB16995@xxxxxxxxxxxxxxxxxxxxx> <46663824.6030200@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)
Hi, 

At 23:29 -0500 on 05 Jun (1181086164), Wei Huang wrote:
> 2. shadow/hap_log_dirty_enable() and shadow/hap_log_dirty_disable()
> These four functions were not changed. However, I really want to create 
> two common functions (paging_log_dirty_disable() and 
> paging_log_dirty_enable()) for them. To do this, it requires two 
> function pointers (*log_dirty_enable() and *log_dirty_disable()), which 
> point to shadow-specific code or hap-specific code. For example, 
> *log_dirty_enable() points to shadow_log_dirty_enable().
> 
> Tim, let me know if you like this approach.

Yep, that seems fine.
 
> 3. p2m_set_l1e_flags() is renamed to p2m_set_flags_global() as 
> requested. It does NOT walk P2M. Instead, it still relies on 
> set_p2m_entry() to walk P2M table.
> 
> The reason: I feel uncomfortable to duplicate the code of 
> set_p2m_entry() in this method. Most of them will be same as 
> set_p2m_entry() and p2m_next_level(). What is your opinion?

I think it'd be fairly easy to do with a few nested loops since it
doesn't need to care about contents or changing the shape of the tree,
or have to handle different PT layouts at run-time.

I was worried about the cost of reading the struct page-info and the m2p
and doing _two_ traverses of the p2m for every frame in the domain; but
I don't suppose that enabling log-dirty mode is too time-critical an
operation. :)

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, XenSource UK Limited
Registered office c/o EC2Y 5EB, UK; company number 05334508

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