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: "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, "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: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
Date: Tue, 9 May 2006 09:50:44 +0800
Delivery-date: Mon, 08 May 2006 18:52:06 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZwHNAiCHZMhnhSRAiHqO4kSr0/sgC7BZ0Q
Thread-topic: [Xen-ia64-devel] Stability has improved but there is still worktobe done.
>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.

Thanks,
Anthony


>
>Today result: 136+175 (domU 4 ways), no crash.
>
>Tristan.
>
>
>_______________________________________________
>Xen-ia64-devel mailing list
>Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-ia64-devel

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

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