Hi Alex,
Alex Williamson wrote:
>>> I think the issue is same as reported in the below thread.
>>> http://lists.xensource.com/archives/html/xen-ia64-devel/2006-09/msg00204.html
>>> 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.
>
> 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.
Thanks
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 29cae9cfc9e5b8d1893dc67fc455f5fedb323805
# Parent da717c160155a99c90e91049400ef32bff2a579f
Preliminary fix to avoid hypervisor crash during domain destruction
Signed-off-by: Tsunehisa Doi <[EMAIL PROTECTED]>
diff -r da717c160155 -r 29cae9cfc9e5 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c Wed Oct 18 15:27:08 2006 +0900
+++ b/xen/arch/ia64/xen/mm.c Wed Oct 18 15:33:53 2006 +0900
@@ -399,11 +399,10 @@ 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;
+ return INVALID_MFN;
}
pte = lookup_domain_mpa(d,gpfn << PAGE_SHIFT, NULL);
if (!pte) {
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
