WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] BUG at mm.c:605

To: Alex Williamson <alex.williamson@xxxxxx>, Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] BUG at mm.c:605
From: Doi.Tsunehisa@xxxxxxxxxxxxxx
Date: Wed, 18 Oct 2006 12:59:30 +0900
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 17 Oct 2006 21:00:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: Your message of Wed, 18 Oct 2006 11:02:31 +0900. <20061018020231.GG14325%yamahata@xxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1161126802.5444.15.camel@lappy><20061018020231.GG14325%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi,

You (yamahata) said:
> 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.

> 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)
   204  {
   205      domain_pause(d);
   206
   207      if ( test_and_set_bit(_DOMF_dying, &d->domain_flags) )
   208          return;
   209
   210      gnttab_release_mappings(d);
   211      domain_relinquish_resources(d);
   212      put_domain(d);
   213
   214      send_guest_global_virq(dom0, VIRQ_DOM_EXC);
   215  }

  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 think.

  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.

Thanks
- Tsunehisa Doi

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel

<Prev in Thread] Current Thread [Next in Thread>