[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-ia64-devel] Stability has improved but there is still worktobe done.


  • To: "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.