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

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

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