RE: [Xen-ia64-devel] PATCH: slightly improve stability

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

Hi Anthony --

I tried your patch overnight and still got a segmentation
fault in 1 run out of 50.  I didn't try Tristan's patch yet,
so will try both at the same time next... perhaps there
are two different problems that show up as the segmentation
fault.

Dan 

> -----Original Message-----
> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx] 
> Sent: Thursday, April 27, 2006 9:19 PM
> To: Xu, Anthony; Tristan Gingold; 
> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx; Magenheimer, Dan (HP Labs 
> Fort Collins); Williamson, Alex (Linux Kernel Dev)
> Subject: RE: [Xen-ia64-devel] PATCH: slightly improve stability
> 
> Hi Tristan,
> Could you please check whether this patch address RSE issue?
> 
> Yes, Intel QA team is doing the test in the meantime.
> 
> 
> Thanks,
> -Anthony 
> 
> >-----Original Message-----
> >From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On 
> Behalf Of Xu, Anthony
> >Sent: 2006?4?28? 9:48
> >To: Tristan Gingold; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx; 
> Magenheimer, Dan (HP
> >Labs Fort Collins); Alex Williamson
> >Subject: RE: [Xen-ia64-devel] PATCH: slightly improve stability
> >
> >>From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >>[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On 
> Behalf Of Tristan
> >>Gingold
> >>Sent: 2006?4?27? 23:14
> >>To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx; Magenheimer, Dan 
> (HP Labs Fort
> >>Collins); Alex Williamson
> >>Subject: [Xen-ia64-devel] PATCH: slightly improve stability
> >>
> >>Hi,
> >>
> >>as reported earlier, this patch seems to improve stability: 
> crashes are at
> >>least more coherent and maybe less frequent.
> >>
> >>RSE handling seems to have a bug: crahes are now due to 
> either a bad value in
> >>a stacked register or a use of an invalid stacked register 
> (although cfm
> >>seems correct in gdb!)
> >
> >I'm looking at this too,
> >Yes there is a bug about handle_lazy_cover.
> >
> >void ia64_do_page_fault (unsigned long address, unsigned 
> long isr, struct
> >pt_regs *regs, unsigned long itir)
> >{
> >     unsigned long iip = regs->cr_iip, iha;
> >     // FIXME should validate address here
> >     unsigned long pteval;
> >     unsigned long is_data = !((isr >> IA64_ISR_X_BIT) & 1UL);
> >     IA64FAULT fault;
> >
> >     if ((isr & IA64_ISR_IR) && handle_lazy_cover(current, 
> isr, regs)) return;
> >
> >This code sequence is intended to handle following scenario.
> >
> >1. Guest executes br.ret, this may cause mandatory RSE load, 
> and this load may
> >cause TLB miss.
> >2. VMM gets control, but VMM can't handle this TLB miss 
> itself, then VMM injects
> >TLB miss to Guest TLB miss handler, when VMM executing "rfi" 
> to jump to Guest
> >TLB miss handler, this TLB miss happens again.
> >3. At this time, interrupt_collection_enabled is 0, so 
> handle_lazy_cover
> >executes "cover" on behalf of Guest, and return to Guest TLB 
> miss handler again,
> >this time there is no TLB miss.
> >
> >
> >Following code sequence is in ia64_leave_kernel path with 
> psr.ic and psr.i off.
> >When br.ret.dptk.many b0 is executed, there may be a 
> mandatory load, thus
> >There may be a tlb miss, according to above description 
> handle_lazy_cover
> >executes "cover" on behalf of Guest and return to Guest, 
> this is no correct
> >in this scenario.
> >
> >I didn't find an easy way to fix this bug.
> >
> >
> >     mov loc6=0
> >     mov loc7=0
> >(pRecurse) br.call.dptk.few b0=rse_clear_invalid
> >     ;;
> >     mov loc8=0
> >     mov loc9=0
> >     cmp.ne pReturn,p0=r0,in1        // if recursion count 
> != 0, we need to do a
> >br.ret
> >     mov loc10=0
> >     mov loc11=0
> >(pReturn) br.ret.dptk.many b0
> >#endif /* !CONFIG_ITANIUM */
> >#    undef pRecurse
> >#    undef pReturn
> >     ;;
> >     alloc r17=ar.pfs,0,0,0,0        // drop current register frame
> >     ;;
> >     loadrs
> >
> >Thanks,
> >Anthony
> >
> >
> >>
> >>Tested by doing many linux kernel compilation in SMP domU (> 100).
> >>
> >>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