On 17/10/2012 18:07, "Jacob Shin" <jacob.shin@amd.com> wrote:
> Hi,
>
> When running xenoprof with backtrace (--callgraph) enabled, with HVM
passive
> domain I trigger the following BUG:
>
> It looks like there were changes in locking over time and this code path
never
> kept up .. Any thoughts/hints on how to get this working again?
It''s never been valid to acquire locks in NMI context, due to the
potential
for deadlock. The backtrace looks quite misguided, the event should be
logged to a simple buffer and then the posting to guest memory done later in
a suitable safe context. Or the guest memory needs to be pinned and mapped
in hypervisor address space so that it can be accessed from NMI context with
no need for locks.
-- Keir
> Thanks!
>
> (XEN) Xen BUG at spinlock.c:48
> (XEN) ----[ Xen-4.3-unstable x86_64 debug=y Not tainted ]----
> (XEN) CPU: 4
> (XEN) RIP: e008:[<ffff82c480124ad2>] check_lock+0x32/0x3e
> (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor
> (XEN) rax: 0000000000000000 rbx: ffff8301d0111a60 rcx: 0000000000000001
> (XEN) rdx: 0000000000000000 rsi: ffff8301d0111a60 rdi: ffff8301d0111a64
> (XEN) rbp: ffff8302298afbb0 rsp: ffff8302298afbb0 r8: 0000000000000000
> (XEN) r9: 0000000000000002 r10: 0000000000000000 r11: 0000000000000000
> (XEN) r12: ffff8302298afc04 r13: ffff8301d0111a60 r14: 0000000000000001
> (XEN) r15: 0000000000000000 cr0: 0000000080050033 cr4: 00000000000406f0
> (XEN) cr3: 000000021fcfa000 cr2: 0000000000000000
> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
> (XEN) Xen stack trace from rsp=ffff8302298afbb0:
> (XEN) ffff8302298afbc8 ffff82c480124e7c ffff8302298afc84
ffff8302298afc38
> (XEN) ffff82c4801d99c4 ffff8302298afc38 ffff82c4801ddbd5
ffff83022d995000
> (XEN) 00000002801c1003 ffff8302298afc58 ffff82c4801b66be
ffff83022d995000
> (XEN) 0000000000001ff0 0000000000001ff0 0000000000000008
0000000000000001
> (XEN) 0000000000000000 ffff8302298afcb8 ffff82c4801b11c3
ffff830009258000
> (XEN) ffff82f6045b5be0 0000000000000004 ffff830009258000
ffff8302298afd30
> (XEN) 0000000100000004 01008301d013d058 ffff8302298afd28
ffff83021fefa000
> (XEN) 0000000000001ff0 0000000000000008 ffff8302298afd30
ffff830009258000
> (XEN) 0000000000000000 ffff8302298afcc8 ffff82c4801b149d
ffff8302298afcf8
> (XEN) ffff82c4801b1520 ffff8302298afd08 0000000000001ff0
0000000000000005
> (XEN) ffff8302298a8000 ffff8302298afd68 ffff82c48021a46f
ffff8302298a8000
> (XEN) ffff8302298a8000 00ff8302298afd38 ffff8302298afd68
ffff82c48013797f
> (XEN) 0000000000000000 000000000000e831 ffff83022d995000
ffff830009258000
> (XEN) ffff8301eff10000 0000000000000000 0000000000000000
ffff8302298afdb8
> (XEN) ffff82c480138acd ffff8302298afe68 000000000000e831
0000000000000000
> (XEN) 0000000000000000 ffff82c4802ff140 0000000000000000
ffff8302298afe68
> (XEN) ffff8302298a8000 ffff8302298afe18 ffff82c480219f2f
0000000000000004
> (XEN) 000000000000e831 00000000298afde8 ffff82c400000006
ffff8302298afe58
> (XEN) ffff8302298afe68 ffff8302298afe68 0000000000000000
0000000000000000
> (XEN) 0000000000000000 ffff8302298afe38 ffff82c4802183da
0000000000000004
> (XEN) Xen call trace:
> (XEN) [<ffff82c480124ad2>] check_lock+0x32/0x3e
> (XEN) [<ffff82c480124e7c>] _read_lock+0x11/0x55
> (XEN) [<ffff82c4801d99c4>] get_page_from_gfn_p2m+0xc3/0x26a
> (XEN) [<ffff82c4801b11c3>] __hvm_copy+0xdf/0x33c
> (XEN) [<ffff82c4801b149d>]
hvm_copy_from_guest_virt_nofault+0x15/0x17
> (XEN) [<ffff82c4801b1520>] copy_from_user_hvm+0x81/0x9d
> (XEN) [<ffff82c48021a46f>] xenoprof_backtrace+0x133/0x254
> (XEN) [<ffff82c480138acd>] xenoprof_log_event+0x143/0x159
> (XEN) [<ffff82c480219f2f>] athlon_check_ctrs+0x117/0x524
> (XEN) [<ffff82c4802183da>] nmi_callback+0x2a/0x9e
> (XEN) [<ffff82c48018616e>] do_nmi+0x34/0x13a
> (XEN) [<ffff82c480224e88>] handle_ist_exception+0x58/0x60
> (XEN) [<ffff82c4801cb2a7>] svm_stgi_label+0/0x49
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel