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] Stability has improved but there is still worktobe

To: "Xu, Anthony" <anthony.xu@xxxxxxxxx>, "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] Stability has improved but there is still worktobe done.
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Tue, 9 May 2006 10:16:49 +0200
Delivery-date: Tue, 09 May 2006 01:12:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <2BF508F394C196468CCBEC031320DCDF0116FE21@pdsmsx405>
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: <2BF508F394C196468CCBEC031320DCDF0116FE21@pdsmsx405>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Le Mardi 09 Mai 2006 03:50, Xu, Anthony a écrit :
> From: Tristan Gingold
>
> >Sent: 2006?5?5? 16:25
> >To: Magenheimer, Dan (HP Labs Fort Collins);
> >xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >Subject: Re: [Xen-ia64-devel] Stability has improved but there is still
> > worktobe done.
> >
> >Le Jeudi 04 Mai 2006 18:52, Magenheimer, Dan (HP Labs Fort Collins) a écrit 
:
> >> I started a test run of xen-unstable cset 9922, and
> >> accidentally only fixed half of Anthony's patch --
> >> I added the st4 in xenminstate.h but forgot to move
> >> the call to handle_lazy_cover in process.c.  (I also
> >> didn't use your tlb_pte cleanup patch.)  I am now
> >> up to 86 linux compiles.  I wonder if that one line
> >> addition (st4) is really all that is required to
> >> fix the "gcc segfault" bug?
> >>
> >> Tristan, since you have a fast machine, perhaps you
> >> could also try just that one line fix?
> >
> >I have only tested with my patch and st4 in xenminstate.h.
> >I have never tested with swapping handle_lazy_cover in process.c (I don't
> >understand this change, I though the cases were exclusive!)
>
> Sorry for not clear,
> Swapping handle_lazy_cover in process.c is necessary.
>
> 1. rse_clear_invalid function in ia64_leave_kernel path may be called
> recursively.
> 2. When rse_clear_invaild returns, there is mandatory RSE load, that may
>  cause data TLB miss with isr.ir =1.
> 3. Previously handle_lazy_cover is called to handle this, that's not
> correctly. 4. Because the RSE memory is mapped by guest TR, VMM should
> lookup guest TRs First, if the mapping is not covered by TRs, then
> handle_lazy_cover is called.
>
> This scenario appears very rarely, because most of time the mapping of RSE
> memory is in VHPT, data TLB miss happens very rarely in ia64_leave_kernel
> path, but it did happens.
>
> VTI-domain has the same issue as above, and I encountered this issue
> several times in VTI-domain.
Thank you for the details.

Tristan.

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

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