[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [RFC] Nested Paging Live Migration
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
Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, XenSource UK Limited
Registered office c/o EC2Y 5EB, UK; company number 05334508
Xen-devel mailing list