Hi,
You (Tim.Deegan) said:
>> * Before shadow2 age, x86 and ia64 use same logic for domain
>> destruction.
>> - at first, release gnttab references
>> - destruct page table for VCPU
>> - destruct P2M table for domain
>> - relinquish memory for domain
>>
>> * After shadow2 age, x86 introduces delayed P2M table destruction.
>> - release gnttab references
>> - destruct page table for VCPU
>> - relinquish memory for domain
>> - destruct P2M table for domain in domain_destroy()
>> *** I don't have confidence in my investigation.
>> *** Am I right ?
>
> Yep. The P2M table can't be destroyed in domain_relinquish_resources,
> as it is needed when pulling down grant references, and foreign domains
> may have outstanding grant references to the dying domain's memory even
> after domain_relinquish_resources.
Thanks.
I've supposed that the introduce of P2M table delayed destruction was
for gnttab_copy feature indeed. It seems that other grant table
references are released with gnttab_release_mapping() in domain_kill().
>> If my speculation is correct, shadow2 may occur a problem of memory
>> corruption.
>
> I don't follow quite why this would lead to memory corruption. Can you
> explain?
I'll try to explain it.
Basically, the referencee should not be released during to exist the
referencer, I think.
In domain_kill phase, domain_relinquish_resource releases a memory
of destroying domain. So, the memory may use other domain. But, P2M
table of the domain exists, then the memory might be corrupted by
gnttab_copy.
In __gnttab_copy code, it will avoid to corrupt a memory that was
used in destroying domain with __acquire_grant_for_copy and get_page.
But, I think that it has atomicity issue of owner.
In my opinion, P2M table should be destroyed before releasing memory.
So, if gnttab_copy will use it, it shall be failed as invalid access,
because the gnttab_copy doesn't have to succeed during the domain
destruction.
What do you think about ?
Thanks,
- Tsunehisa Doi
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home