[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-ia64-devel] Modify to introduce delayed p2m table destruction



On Mon, Nov 06, 2006 at 09:37:32AM +0900, Doi.Tsunehisa@xxxxxxxxxxxxxx wrote:
>   I think, the p2m table of the domain (during destruction indeed)
> is not modified by any domain. Gran table reference has a possiblity
> of p2m table modified by other domain, but in this case, grant table
> reference releases before `shadow_teardown'.

Grant table page transfer does. (So In fact before this issue raise,
the p2m destruction code was already broken. Fortunately
no one hit this.)


> > - your patch breaks page reference convension.
>   During domain creation and destruction, it might be broken, but
> it has to do, I think.

What do you mean by "destruction"?
It's so sutble that you had to defer the p2m table freeing, didn't you?
After arch_domain_destroy() no other domain modify the p2m table,
so breaking the page reference convesion is O.K. after that.
However during shadow_teardown_xxx() in your patch
other domain might access the p2m table and struct page_info.
Page reference convension must be kept right during them.


> >>> - Why shadow prefix? it isn't related to shadow.
> >> 
> >>   In IA64 code, it doesn't have shadow page table, but it regards
> >> that it has shadow mode, I think. Thus I adopted shadow prefix to
> >> follow other arch.
> > 
> > Shadow prefix is confusing here. (At least for me)
> 
>   I don't have so good idea. 
> 
>   What do you think about below ?
> 
>     - shadow_teardown        ->  teardown_mm
>     - shadow_final_teardown  ->  final_teardown_mm
>     - shadow_p2m_teardown    ->  final_p2m_teardown

How about s/shadow/mm/ ?


-- 
yamahata

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.