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