|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 16/17] xenctx: Allow output for offline vcpu when specified.
On 03/21/14 11:11, Ian Campbell wrote: On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:xc_domain_hvm_getcontext_partial() will fail to get data for an offline cpu. Switch back to PV mode of calculating ctxt_word_size and guest_word_size in the case.Does that provide sensible results? I wouldn't have thought so.
It does display sensible results for the registers.
At boot time you get:
xenctx -s /boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 2 1
xc_vcpu_getcontext: No data available
But once a cpu is used you get correct data.
I found out that I add missed a change to xc_translate_foreign_address()
(also check for errno == EBADSLT) which is needed to do the correct
virtual to physical address conversion. Will be part of this patch in the
next version. Here is some output using this new version.
Before "echo 0 > /sys/devices/system/cpu/cpu1/online":
xenctx -s /boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 1 1
rip: ffffffff810387db native_safe_halt+0xb
flags: 00000246 i z p
rsp: ffff88003e417ed8
rax: 0000000000000000 rcx: 0000000000000000 rdx: 0000000000000000
rbx: 0000000000000001 rsi: 0000000000000001 rdi: ffffffff81ddc228
rbp: ffff88003e417ed8 r8: 0000000000000000 r9: 0000000000000000
r10: 0000001bdca0ef03 r11: ffff88003e417e78 r12: ffffffff81c03800
r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
cs: 0010 ss: 0018 ds: 0018 es: 0018
fs: 0000 @ 0000000000000000
gs: 0000 @ ffff88000b420000/0000000000000000/
Code (instr addr ffffffff810387db)
44 00 00 fb c9 c3 0f 1f 40 00 55 48 89 e5 0f 1f 44 00 00 fb f4 <c9> c3 0f 1f 00
55 48 89 e5 0f 1f
Stack:
ffff88003e417ef8 ffffffff810149cd ffff88003e417fd8 ffffffff81c03800
ffff88003e417f28 ffffffff81009e06 ffff88003e417f18 a0460d871075161c
0000000000000000 0000000000000000 ffff88003e417f48 ffffffff814f6e1f
0000000000000000 00000001814f6bf5 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
Call Trace:
[<ffffffff810387db>] native_safe_halt+0xb <--
[<ffffffff810149cd>] default_idle+0x4d
[<ffffffff81009e06>] cpu_idle+0xb6
[<ffffffff814f6e1f>] start_secondary+0x22a
After "echo 0 > /sys/devices/system/cpu/cpu1/online":
xenctx -s /boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 1 1
Note: vcpu1 offline:
rip: ffffffff8102acc1 native_play_dead+0x51
flags: 00000006 nz p
rsp: ffff88003e417ee8
rax: ffff88000b420000 rcx: 0000000000000020 rdx: ffff88000b420000
rbx: 0000000000016500 rsi: 0000000000000086 rdi: 0000000000000005
rbp: ffff88003e417ef8 r8: 0000000000000000 r9: ffff88000b4315a8
r10: 0000000000000005 r11: 0000000000000000 r12: 0000000000016500
r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
cs: 0010 ss: 0018 ds: 0018 es: 0018
fs: 0000 @ 0000000000000000
gs: 0000 @ ffff88000b420000/0000000000000000/
Code (instr addr ffffffff8102acc1)
00 00 42 80 3c 20 03 76 0b 0f 09 0f 1f 44 00 00 0f 1f 40 00 f4 <eb> fd 48 8d 3c
18 e8 04 92 fe ff
Stack:
ffff88003e417fd8 ffffffff81c03800 ffff88003e417f28 ffffffff81009e4b
ffff88003e417f18 a0460d871075161c 0000000000000000 0000000000000000
ffff88003e417f48 ffffffff814f6e1f 0000000000000000 00000001814f6bf5
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
Call Trace:
[<ffffffff8102acc1>] native_play_dead+0x51 <--
[<ffffffff81009e4b>] cpu_idle+0xfb
[<ffffffff814f6e1f>] start_secondary+0x22a
Using offline.ko module (posted on the list, with the change to output
routine addresses) gives me on domU's serial console:
[ 393.119432] offline 1.1 who=0x1 wait=0 cpu=1 depth=0 count=100
[ 393.132654] init_module=ffffffffa0058210 offline_self=ffffffffa0058070
fill_stack=ffffffffa00580d0
[ 393.158013] offline done who=0x1
Which is telling me that insmod is on cpu1, and we are offlineing cpu0:
xenctx -s /boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 1 0
Note: vcpu0 offline:
rip: ffffffffa0058093
flags: 00000097 s nz a p c
rsp: ffff88000b403f58
rax: 0000000000000000 rcx: ffffffff81a8f020 rdx: 0000000000000001
rbx: ffff88000b403f68 rsi: 0000000000000000 rdi: 0000000000000000
rbp: ffff88000b403f58 r8: ffff88000b431800 r9: 0000000000000001
r10: 0000000000000000 r11: 0000000000000000 r12: ffff88000b431800
r13: 0000000000000001 r14: ffff88003dea96c0 r15: 00000000ffffffff
cs: 0010 ss: 0018 ds: 0018 es: 0018
fs: 0000 @ 0000000000000000
gs: 0000 @ ffff88000b400000/0000000000000000/
Code (instr addr ffffffffa0058093)
e0 00 00 83 f8 1f 77 0d 8b 15 e8 48 00 00 0f a3 c2 73 02 fa f4 <c9> c3 66 66 2e
0f 1f 84 00 00 00
Since this kernel module is not part of kernel text, the stack display is
skipped. So
Use the new feature -d to force it out:
xenctx -s /boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 1 0 -d
0xffff88000b403f58 -t -T
Note: vcpu0 offline:
Stack:
ffff88000b403f58: ffff88000b403f98 ffffffff810a87e9 ffff88000b403f68
ffff88000b403f68
ffff88000b403f78: ffff88000b403f98 ffff88003dea96c0 ffffffff81a8f020
0000000000000000
ffff88000b403f98: ffff88000b403fa8 ffffffff8102a8f7 ffff88003efd3d30
ffffffff8100bdb3
ffff88000b403fb8: ffff88003efd3d30 0000000000000000 0000000000000000
0000000000000000
ffff88000b403fd8: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
Call Trace:
ffff88000b403f60: [<ffffffff810a87e9>]
generic_smp_call_function_single_interrupt+0xa9
ffff88000b403fa0: [<ffffffff8102a8f7>] smp_call_function_single_interrupt+0x27
ffff88000b403fb0: [<ffffffff8100bdb3>] call_function_single_interrupt+0x13
Which is exactly the Call Trace that it should have.
Here is the state of vcpu1:
xenctx -s /boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 1 1 -t -T
rip: ffffffff810387db native_safe_halt+0xb
flags: 00000246 i z p
rsp: ffff88003e417ed8
rax: 0000000000000000 rcx: 0000000000000000 rdx: 0000000000000000
rbx: 0000000000000001 rsi: 0000000000000001 rdi: ffffffff81ddc228
rbp: ffff88003e417ed8 r8: 0000000000000000 r9: 0000000000000000
r10: 0000000000000000 r11: 0000000000000000 r12: ffffffff81c03800
r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
cs: 0010 ss: 0018 ds: 0018 es: 0018
fs: 0000 @ 0000000000000000
gs: 0000 @ ffff88000b420000/0000000000000000/
Code (instr addr ffffffff810387db)
44 00 00 fb c9 c3 0f 1f 40 00 55 48 89 e5 0f 1f 44 00 00 fb f4 <c9> c3 0f 1f 00
55 48 89 e5 0f 1f
Stack:
ffff88003e417ed8: ffff88003e417ef8 ffffffff810149cd ffff88003e417fd8
ffffffff81c03800
ffff88003e417ef8: ffff88003e417f28 ffffffff81009e06 ffff88003e417f18
bd1aee47aad97866
ffff88003e417f18: 0000000000000000 0000000000000000 ffff88003e417f48
ffffffff814f6e1f
ffff88003e417f38: 0000000000000000 00000001814f6bf5 0000000000000000
0000000000000000
ffff88003e417f58: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
Call Trace:
[<ffffffff810387db>] native_safe_halt+0xb <--
ffff88003e417ee0: [<ffffffff810149cd>] default_idle+0x4d
ffff88003e417f00: [<ffffffff81009e06>] cpu_idle+0xb6
ffff88003e417f30: [<ffffffff814f6e1f>] start_secondary+0x22a
Using gdbsx to also look at this data:
[root@dcs-xen-54 ~]# gdbsx -c 1 64 1
===> Context for DOMID:1
--> VCPU:1
rip:ffffffff810387db rsp:ffff88003e417ed8 flags:0000000000000246
rax:0000000000000000 rbx:0000000000000001 rcx:0000000000000000
rdx:0000000000000000 rsi:0000000000000001 rdi:ffffffff81ddc228
r08:0000000000000000 r09:0000000000000000 r10:0000000000000000
r11:0000000000000000 r12:ffffffff81c03800 r13:0000000000000000
r14:0000000000000000 r15:0000000000000000 rbp:ffff88003e417ed8
cs:0000000000000010 ds:0000000000000018 fs:0000000000000000 gs:0000000000000000
Call Trace:
[ffffffff810387db]
[ffffffff810149cd]
[ffffffff81c03800]
[ffffffff81009e06]
[ffffffff814f6e1f]
[ffffffff81a991e0]
[ffffffff8107f5f0]
[ffffffff81136a99]
[ffffffff81136a99]
[ffffffff81125b31]
[ffffffff81136a99]
[root@dcs-xen-54 ~]# gdbsx -c 1 64 0
===> Context for DOMID:1
--> VCPU:0
rip:ffffffffa0058093 rsp:ffff88000b403f58 flags:0000000000000097
rax:0000000000000000 rbx:ffff88000b403f68 rcx:ffffffff81a8f020
rdx:0000000000000001 rsi:0000000000000000 rdi:0000000000000000
r08:ffff88000b431800 r09:0000000000000001 r10:0000000000000000
r11:0000000000000000 r12:ffff88000b431800 r13:0000000000000001
r14:ffff88003dea96c0 r15:00000000ffffffff rbp:ffff88000b403f58
cs:0000000000000010 ds:0000000000000018 fs:0000000000000000 gs:0000000000000000
Call Trace:
[ffffffffa0058093]
[ffffffff810a87e9]
[ffffffff81a8f020]
[ffffffff8102a8f7]
[ffffffff8100bdb3]
[ffffffffffffffff]
[ffffffffffffffff]
[ffffffffffffffff]
[ffffffffffffffff]
[ffffffffffffffff]
[ffffffffffffffff]
(gdb) disass/r 0xffffffffa0058070,0xffffffffa0058097
Dump of assembler code from 0xffffffffa0058070 to 0xffffffffa0058097:
0xffffffffa0058070: 55 push %rbp
0xffffffffa0058071: 48 89 e5 mov %rsp,%rbp
0xffffffffa0058074: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
0xffffffffa0058079: 65 8b 04 25 b8 e0 00 00 mov %gs:0xe0b8,%eax
0xffffffffa0058081: 83 f8 1f cmp $0x1f,%eax
0xffffffffa0058084: 77 0d ja 0xffffffffa0058093
0xffffffffa0058086: 8b 15 e8 48 00 00 mov 0x48e8(%rip),%edx #
0xffffffffa005c974
0xffffffffa005808c: 0f a3 c2 bt %eax,%edx
0xffffffffa005808f: 73 02 jae 0xffffffffa0058093
0xffffffffa0058091: fa cli
0xffffffffa0058092: f4 hlt
=> 0xffffffffa0058093: c9 leaveq
0xffffffffa0058094: c3 retq
0xffffffffa0058095: 66 66 2e 0f 1f 84 00 00 00 00 00 data32 nopw
%cs:0x0(%rax,%rax,1)
End of assembler dump.
Why not just print nothing for that vcpu? That is what "-C" does. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |