Re: [Xen-devel] [RFC] Nested Paging Live Migration

[Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>]

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