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