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

[Doi.Tsunehisa@xxxxxxxxxxxxxx]

You (yamahata) said:
>>   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.)

  Hmm, I've thought that gnttab_release_mapping() ensures it...

>>> - 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"?

  I meen domain destruction.

> It's so sutble that you had to defer the p2m table freeing, didn't you?

  Yes, I wanted to defer the p2m table freeing.

> After arch_domain_destroy() no other domain modify the p2m table,
> so breaking the page reference convesion is O.K. after that.

  Yes, but arch_domain_destroy() is final stage of domain destruction
called by domain_destroy() which is called until d->refcnt becomes zero.
I think that it has to do during p2m table destruction.

> 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.

  Yes, it might access them. In past, I thought so, but after
discussion about delayed p2m table destruction of shadow2, I've be
satisfied that get_page avoids memory corruption finally.

>>> 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/ ?

  Oh! It's good idea. I'll change prefix with this idea.

Thanks,
- Tsunehisa Doi

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