From: xen-...@lists.xensource.com

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