Re: [Xen-devel] xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0

[Pasi Kärkkäinen <pasik@xxxxxx>]

On Fri, Jun 05, 2009 at 11:37:44AM +0000, Ian Campbell wrote:
> On Fri, 2009-06-05 at 07:23 -0400, Pasi Kärkkäinen wrote:
> > > Do you know which line of xen_set_pte() the fault is occurring at? I
> > > assume either "ptep->pte_high =" or "ptep->pte_low =".
> > > 
> > 
> > I haven't looked for that.. I guess I should compile debug=y Xen build
> > again.
> 
> xen_set_pte() is in the kernel rather than Xen so e.g. from
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-01-with-highpte.txt:
> [...]
> EIP: 0061:[<c0405d63>] EFLAGS: 00010296 CPU: 0
> [...]
> 
> Can you use gdb to find out what 0xc0405d63 is, e.g. with "list
> *0xc0405d63" and/or "disas 0xc0405d63"
> 

(gdb) list *0xc0405d63
0xc0405d63 is in xen_set_pte (arch/x86/xen/mmu.c:683).
678             ADD_STATS(pte_update_batched, paravirt_get_lazy_mode() == 
PARAVIRT_LAZY_MMU);
679
680     #ifdef CONFIG_X86_PAE
681             ptep->pte_high = pte.pte_high;
682             smp_wmb();
683             ptep->pte_low = pte.pte_low;
684     #else
685             *ptep = pte;
686     #endif
687     }

Dump of assembler code for function xen_set_pte:
0xc0405cda <xen_set_pte+0>:     push   %ebp
0xc0405cdb <xen_set_pte+1>:     mov    %esp,%ebp
0xc0405cdd <xen_set_pte+3>:     push   %edi
0xc0405cde <xen_set_pte+4>:     push   %esi
0xc0405cdf <xen_set_pte+5>:     mov    %ecx,%esi
0xc0405ce1 <xen_set_pte+7>:     push   %ebx
0xc0405ce2 <xen_set_pte+8>:     mov    %eax,%ebx
0xc0405ce4 <xen_set_pte+10>:    mov    %edx,%eax
0xc0405ce6 <xen_set_pte+12>:    sub    $0x4,%esp
0xc0405ce9 <xen_set_pte+15>:    and    $0x400,%eax
0xc0405cee <xen_set_pte+20>:    je     0xc0405cff <check_zero>
0xc0405cf0 <xen_set_iomap_pte+0>:       mov    %ebx,%eax
0xc0405cf2 <xen_set_iomap_pte+2>:       push   $0x7ff1
0xc0405cf7 <xen_set_iomap_pte+7>:       call   0xc0405c35 <xen_set_domain_pte>
0xc0405cfc <xen_set_iomap_pte+12>:      pop    %ebx
0xc0405cfd <xen_set_iomap_pte+13>:      jmp    0xc0405d65 <xen_set_pte+139>
0xc0405cff <check_zero+0>:      cmpb   $0x0,0xc08f334c
0xc0405d06 <check_zero+7>:      je     0xc0405d1b <xen_set_pte+65>
0xc0405d08 <__constant_c_and_count_memset+0>:   mov    $0x33,%ecx
0xc0405d0d <__constant_c_and_count_memset+5>:   mov    $0xc08f3280,%edi
0xc0405d12 <__constant_c_and_count_memset+10>:  rep stos %eax,%es:(%edi)
0xc0405d14 <check_zero+21>:     movb   $0x0,0xc08f334c
0xc0405d1b <xen_set_pte+65>:    incl   0xc08f32a4
0xc0405d21 <check_zero+0>:      cmpb   $0x0,0xc08f334c
0xc0405d28 <check_zero+7>:      je     0xc0405d3f <xen_set_pte+101>
0xc0405d2a <__constant_c_and_count_memset+0>:   mov    $0x33,%ecx
0xc0405d2f <__constant_c_and_count_memset+5>:   mov    $0xc08f3280,%edi
0xc0405d34 <__constant_c_and_count_memset+10>:  xor    %eax,%eax
0xc0405d36 <__constant_c_and_count_memset+12>:  rep stos %eax,%es:(%edi)
0xc0405d38 <check_zero+23>:     movb   $0x0,0xc08f334c
0xc0405d3f <xen_set_pte+101>:   mov    0xc08f32ac,%edi
0xc0405d45 <xen_set_pte+107>:   mov    %edx,-0x10(%ebp)
0xc0405d48 <xen_set_pte+110>:   call   0xc0422f2a <paravirt_get_lazy_mode>
0xc0405d4d <xen_set_pte+115>:   dec    %eax
0xc0405d4e <xen_set_pte+116>:   sete   %al
0xc0405d51 <xen_set_pte+119>:   movzbl %al,%eax
0xc0405d54 <xen_set_pte+122>:   lea    (%eax,%edi,1),%edi
0xc0405d57 <xen_set_pte+125>:   mov    %edi,0xc08f32ac
0xc0405d5d <xen_set_pte+131>:   mov    %esi,0x4(%ebx)
0xc0405d60 <xen_set_pte+134>:   mov    -0x10(%ebp),%edx
0xc0405d63 <xen_set_pte+137>:   mov    %edx,(%ebx)
0xc0405d65 <xen_set_pte+139>:   lea    -0xc(%ebp),%esp
0xc0405d68 <xen_set_pte+142>:   pop    %ebx
0xc0405d69 <xen_set_pte+143>:   pop    %esi
0xc0405d6a <xen_set_pte+144>:   pop    %edi
0xc0405d6b <xen_set_pte+145>:   pop    %ebp
0xc0405d6c <xen_set_pte+146>:   ret
End of assembler dump.
(gdb) 


> Trying a debug=y Xen might be interesting as well though, it does more
> checks etc so perhaps we can spot something odd earlier. Also all my
> repro attempts were with debug=y so it would be interesting to know what
> happens for you.
> 

I'll build debug=y Xen hypervisor, and also new CONFIG_HIGHPTE=y kernel with
the debug patch you sent. 

Btw. I just realized you said earlier that you tested with dom0_mem=512M ..
that doesn't give you any highmem.. ? Maybe that's why you aren't seeing the
problem..

I have dom0_mem=1024M

-- Pasi

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