http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1258
Summary: xen 3.3 unstable: xend segfaults on amd64 when starting
a hvm domain
Product: Xen
Version: unstable
Platform: x86-64
OS/Version: other
Status: NEW
Severity: critical
Priority: P2
Component: Tools
AssignedTo: xen-bugs@xxxxxxxxxxxxxxxxxxx
ReportedBy: jk@xxxxxxxx
I'm trying to start a 32-bit windows hvm domU on a 64-bit opensolaris dom0,
using xen 3.3 unstable bits from the
http://xenbits.xensource.com/xen-unstable.hg
repository (+ some additional fixes for opensolaris).
changeset 17644: 29dc52031954
date: Thu May 15 09:38:00 2008 +0100 (6 days ago)
description: x86: Fix an S3 bug caused by x_firmware_waking_vector
Problem: when I try to start the windows domain, xend (that is, the python
interpreter) crashes with a segfault. Like this:
# xm create winxp
Using config file "/etc/xen/winxp".
Xend has probably crashed! Invalid or missing HTTP status code.
/var/adm/messages contains:
May 17 22:03:16 moritz genunix: [ID 603404 kern.notice] NOTICE: core_log:
python
[794] core dumped: /cores/python-794
Thread #48 got a SIGSEGV:
# pflags /cores/python-794
core '/cores/python-794' of 794: python /usr/lib/xend start
data model = _LP64 flags = ORPHAN|MSACCT|MSFORK
/1: flags = STOPPED pollsys(0x7fffffdfef00,0x0,0x7fffffdfefc0,0x0)
why = PR_SUSPENDED
/2: flags = DETACH|STOPPED accept(0x4,0x7ffffe5be320,0x7ffffe5be42c,0x1)
why = PR_SUSPENDED
/3: flags = DETACH|STOPPED accept(0x10,0x7ffffe3bf320,0x7ffffe3bf42c,0x1)
why = PR_SUSPENDED
/4: flags = DETACH|STOPPED pollsys(0x7ffffe1c0730,0x0,0x7ffffe1c07f0,0x0)
why = PR_SUSPENDED
/5: flags = DETACH|STOPPED lwp_park(0x0,0x0,0x0)
why = PR_SUSPENDED
/6: flags = STOPPED read(0x14,0x412f20,0x10)
why = PR_SUSPENDED
/7: flags = DETACH|STOPPED accept(0x15,0x7ffffdbc3170,0x7ffffdbc327c,0x1)
why = PR_SUSPENDED
/8: flags = DETACH|STOPPED accept(0x17,0x7ffffd9c3a60,0x7ffffd9c3b6c,0x1)
why = PR_SUSPENDED
/48: flags = DETACH
sigmask = 0xffffbefc,0x0000ffff cursig = SIGSEGV
And the stack backtrace for tread #48 looks like this
# pstack /cores/python-794
...
----------------- lwp# 48 / thread# 48 --------------------
00007ffffe9a5b2a cpuid () + 1a
00007ffffe9f6783 pyxc_dom_set_policy_cpuid () + 33
00007fffff2adacc PyCFunction_Call () + 17c
00007fffff2e5ead call_function () + 41d
00007fffff2e0dfe PyEval_EvalFrameReal () + c6e
00007fffff2e0180 PyEval_EvalFrame () + 20
00007fffff2e5fd0 fast_function () + b0
...
# mdb - /cores/python-794
Loading modules: [ libc.so.1 libuutil.so.1 ld.so.1 ]
> ::regs
%rax = 0x0000000080000018 %r8 = 0x0000000068747541
%rbx = 0x00000000fd56b860 %r9 = 0x0000000000000007
%rcx = 0x00000000444d4163 %r10 = 0x00007ffffd56b608
%rdx = 0x0000000069746e65 %r11 = 0x0000000000000000
%rsi = 0x00000000fd56b860 %r12 = 0x0000000000000007
%rdi = 0x00007ffffd56b858 %r13 = 0x0000000000000001
%r14 = 0x0000000000000008
%r15 = 0x00007ffffd56b858
%cs = 0x0053 %fs = 0x0000 %gs = 0x0000
%ds = 0x004b %es = 0x004b %ss = 0x004b
%rip = 0x00007ffffe9a5b2a libxenguest.so.3.2.0`cpuid+0x1a
%rbp = 0x00007ffffd56b8a0
%rsp = 0x00007ffffd56b848
%rflags = 0x00010213
id=0 vip=0 vif=0 ac=0 vm=0 rf=1 nt=0 iopl=0x0
status=<of,df,IF,tf,sf,zf,AF,pf,CF>
%gsbase = 0x0000000000000000
%fsbase = 0x00007ffffee44a00
%trapno = 0xe
%err = 0x6
> <rip::dis
libxenguest.so.3.2.0`cpuid: movl 0x4(%rdi),%eax
libxenguest.so.3.2.0`cpuid+3: xorl %ecx,%ecx
libxenguest.so.3.2.0`cpuid+5: cmpl $-0x1,%eax <0xffffffff>
libxenguest.so.3.2.0`cpuid+8: cmovl.ne %eax,%ecx
libxenguest.so.3.2.0`cpuid+0xb: movl (%rdi),%eax
libxenguest.so.3.2.0`cpuid+0xd: movl %ebx,-0x4(%rsp)
libxenguest.so.3.2.0`cpuid+0x11:cpuid
libxenguest.so.3.2.0`cpuid+0x13:movl %ebx,%r8d
libxenguest.so.3.2.0`cpuid+0x16:movl -0x4(%rsp),%ebx
libxenguest.so.3.2.0`cpuid+0x1a:movl %eax,(%rsi) <<<<<<<<<<<<<<<<< %rip
libxenguest.so.3.2.0`cpuid+0x1c:movl %r8d,0x4(%rsi)
libxenguest.so.3.2.0`cpuid+0x20:movl %ecx,0x8(%rsi)
libxenguest.so.3.2.0`cpuid+0x23:movl %edx,0xc(%rsi)
libxenguest.so.3.2.0`cpuid+0x26:ret
0x7ffffe9a5b37: nop
0x7ffffe9a5b3a: nop
0x7ffffe9a5b3d: nop
libxenguest.so.3.2.0`xc_cpuid_policy: pushq %rbp
libxenguest.so.3.2.0`xc_cpuid_policy+1: movq %rsp,%rbp
libxenguest.so.3.2.0`xc_cpuid_policy+4: movq %r12,-0x20(%rbp)
> 0x00000000fd56b860/X
mdb: failed to read data from target: no mapping for address
0xfd56b860:
> 0x00007ffffd56b860/XXXX
0x7ffffd56b860: 1 68747541 444d4163 69746e65
>
Apparently the "regs" pointer passed to the function cpuid(), file
tools/libxc/xc_cpuid_x86.c (%rsi on amd64 / x86_64) is bogus, %rsi has
lost the top 32-bits.
This is because the caller of the cpuid() function has the 64-bit pointer in
%rbx, calls cpuid(), which saves/restores the lower 32-bit of %rbx, but
destroys the upper half.
On amd64 / x86_64, the cpuid() function in tools/libxc/xc_cpuid_x86.c
must save/restore full 64bit %rbx register.
--
Configure bugmail:
http://bugzilla.xensource.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Xen-bugs mailing list
Xen-bugs@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-bugs
|
Home