Re: [Xen-ia64-devel] FYI: domU stability with Isaku VP patch

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Jeudi 20 Avril 2006 15:14, Magenheimer, Dan (HP Labs Fort Collins) a écrit 
:
> I ran 40 compiles in dom0 overnight with Isaku's VP patch
> and got one segment fault. So I agree stability is
> improving... though the problem is still there. Maybe we
> are making it even harder
> to find the infamous "gcc segment fault" :-(
Maybe... 
A bug may hide many bugs...

> One possible clue: I got exactly one console message:
>
> *** NaT fault... attempting to handle as privop
> (XEN) isr=0000000400000020, ifa=0000000000000001, iip=2000000000182d10,
> ipsr=0000101308126010
> (XEN) priv_emulate: priv_handle_op fails, isr=0x400000020
>
> I don't know if this occurred concurrent with the gcc failure.
I have got many of such message during SMP-guest work.  I think this is due to 
stall itc entries.

A cause of the bug may be a missing flush after unmapping grant ref.  The code 
in common/grant_table.c is:
   for ( i = 0; i < count; i++ )
    {
        if ( unlikely(__copy_from_guest_offset(&op, uop, i, 1)) )
            goto fault;
        __gnttab_unmap_grant_ref(&op);
        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
            goto fault;
    }

    flush_tlb_mask(current->domain->domain_dirty_cpumask);
    return 0;

fault:
    flush_tlb_mask(current->domain->domain_dirty_cpumask);
    return -EFAULT;    
}

Since xen/ia64 never set domain_dirty_cpumask, the tlb is not flushed.  I have 
to try with setting the mask.  More results tomorrow.

I *really* think there is a bug here.  However, flushing the whole TLB is 
*very* costy on ia64.  We will certainly have to discuss with Xen/x86 team.

Tristan.



_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel