Hi Alex,
Alex Williamson wrote:
>>> Ok, should I simply revert xen-ia64-unstable cset 11636:3470d9cd27e5?
>> Basically, yes. But we can't avoid hypervisor crash during domain
>> destruction.
>>
>> I think to modify above patch to remove VT-i domain checker like
>> attaced patch, until we will success to seek for the right fix.
>
> This seems worse. Instead of having an identifiable crash footprint,
> the system just hangs with this patch. Thanks,
I see. In this time, I inserted dump_stack() at the condition.
What do you think about it ?
Thanks
- Tsuneshisa Doi
Preliminary fix to avoid hypervisor crash during domain destruction
Signed-off-by: Tsunehisa Doi <Doi.Tsunehisa@xxxxxxxxxxxxxx>
diff -r ee7799388ab1 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c Wed Oct 18 22:07:18 2006 -0600
+++ b/xen/arch/ia64/xen/mm.c Thu Oct 19 17:01:41 2006 +0900
@@ -399,11 +399,11 @@ gmfn_to_mfn_foreign(struct domain *d, un
unsigned long pte;
// This function may be called from __gnttab_copy()
- // during destruction of VT-i domain with PV-on-HVM driver.
+ // during domain destruction with VNIF copy receiver.
// ** FIXME: This is not SMP-safe yet about p2m table. **
if (unlikely(d->arch.mm.pgd == NULL)) {
- if (VMX_DOMAIN(d->vcpu[0]))
- return INVALID_MFN;
+ dump_stack(); // collect footprint
+ return INVALID_MFN;
}
pte = lookup_domain_mpa(d,gpfn << PAGE_SHIFT, NULL);
if (!pte) {
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home