[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-ia64-devel] BUG at mm.c:605
You (yamahata) said:
> I think the issue is same as reported in the below thread.
> I tried to convince him, but failed.
> I think that the best way is to revert the patch and we should seek
> for the right fix.
I agree with Isaku's opinion. I think that the patch was preliminary
to avoid crash hypervisor.
> I guess that making xennet.rx_copy default enabled is the beginning.
> The root cause is that relinquish_memory() writes the P2M simulteniously
> with __acquire_grant_for_copy().
I think so.
> relinquish_memory() of IA64 assumes that no one else read the P2M
> table at the same time. However the such assumption is wrong now.
In my investigation, it was right the assumption before shadow2 on
x86. But shadow2 changed it. In shadow2 code, the P2M table destruction
was moved from domain_kill phase to domain_destroy() phase. I guess
that the spec change is for VNIF copy receiver indeed.
> Although I haven't dug into its details, I suspect that
> the race between relinquish_memory() and get_page()
> (or __acquire_grant_for_copy()) exists not only on ia64,
> but also on x86.
Before shadow2 age, the P2M table can be destructed in
domain_relinquish_resource(), because gnttab_release_mapping() releases
P2M table referencing concerned with grant table.
203 void domain_kill(struct domain *d)
207 if ( test_and_set_bit(_DOMF_dying, &d->domain_flags) )
214 send_guest_global_virq(dom0, VIRQ_DOM_EXC);
But after the copy receiver of VNIF intruduction,
gnttab_release_mapping() became not to be able to release to reference
P2M table. Thus, shadow2 introduced `delayed destruction of P2M table',
I'm afraid that P2M table may be available after the page body
releasing in shadow2. But I've not spend to investigate this issue.
- Tsunehisa Doi
Xen-ia64-devel mailing list