[Xen-bugs] [Bug 1258] New: xen 3.3 unstable: xend segfaults on amd64 when starting a hvm domain

[bugzilla-daemon@xxxxxxxxxxxxxxxxxxx]

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