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
|