QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable

QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable

[kevin.zhang]

[-- Attachment #1.1: Type: text/plain, Size: 1103 bytes --]

Hi all,

Firstly please forgive me if I put this problem in the wrong mail list. 
However, it seems that xen-users mail list cannot resolve this QXL problems. Therefore, I have to post QXL problem in devel mail list.
My problem is as follow:

I'm testing QXL for windows HVM, spice works well with stdvga. 
However, when I switch to QXL, qemu exit abnormally:
I specify vga="qxl" and videoram=128, using qemu-xen. The windows 7 boots and automatially switch resolution for me in virt-viewer.
While display and sound transfering very well, if I change display resolution, the virt-viewer will be suddenly closed and
I check the physical server, the qemu process disappear simultaneously. 
Then I switch to wheezy backport qemu 2.0 as device model, the qemu process will exit as soon as the welcome page appears and at the beginning of resolution change.
I tested and found the same bug on both xenbits xen 4.4.1 rc1 and Fantu's Xen 4.5 unstable, this problem exists in both branches.
Is it a known issue or is there any solution for this bug?
Thank you very much! 


Kevin
Best Regards,

[-- Attachment #1.2: Type: text/html, Size: 2944 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 2487 bytes --]

Il 11/07/2014 04:38, kevin.zhang@octlink.com ha scritto:
> Hi all,
> Firstly please forgive me if I put this problem in the wrong mail list.
> However, it seems that xen-users mail list cannot resolve this QXL 
> problems. Therefore, I have to post QXL problem in devel mail list.
> My problem is as follow:
> I'm testing QXL for windows HVM, spice works well with stdvga.
> However, when I switch to QXL, qemu exit abnormally:
> I specify vga="qxl" and videoram=128, using qemu-xen. The windows 7 
> boots and automatially switch resolution for me in virt-viewer.
> While display and sound transfering very well, if I change display 
> resolution, the virt-viewer will be suddenly closed and
> I check the physical server, the qemu process disappear simultaneously.
> Then I switch to wheezy backport qemu 2.0 as device model, the qemu 
> process will exit as soon as the welcome page appears and at the 
> beginning of resolution change.
> I tested and found the same bug on both xenbits xen 4.4.1 rc1 and 
> Fantu's Xen 4.5 unstable, this problem exists in both branches.
> Is it a known issue or is there any solution for this bug?
> Thank you very much!

Thanks for testing spice and qxl and report issue.
I have spice + qxl working as kvm on xen unstable except this problem:
http://lists.xen.org/archives/html/xen-devel/2014-07/msg01021.html

Please post details on your dom0 installation and domU (for example xl cfg,
spice guest tools version ecc...)
About qemu crash try to take a full backtrace with gdb and post it here.

Small help with gdb of qemu launched by xl:

Add the line below in domU's xl cfg:
device_model_override="/usr/lib/xen/bin/qemu-gdb"

vi /usr/lib/xen/bin/qemu-gdb # create the file, change the qemu path if
needed
#!/bin/sh
exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386 "$@"

# after xl create, do it fast (before timeout or xl create will fails)
target remote localhost:1234
c
bt full # when qemu stops

You should install also all needed dbg packages before, spice qemu ecc or
without package should be compiled with debug enabled (for xen and qemu
default in unstable).

The latest qemu crash with spice I saw was in 2.0-rc solved before 2.0.0
final, your qemu is at least 2.0.0 final?
http://git.qemu.org/?p=qemu.git;a=commit;h=dc491cfc14074064ed54a872b62cce6ca1330644

> Kevin
> Best Regards,
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


[-- Attachment #1.2: Type: text/html, Size: 6431 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable

[kevin.zhang]

[-- Attachment #1.1: Type: text/plain, Size: 3794 bytes --]

Hi Fabio Fantoni,
    Thank you for your help.
     If I use your method to run qemu-gdb when using xl create, xl will complain startup timeout. 
    Perhaps I did not describe my problem clearly enough, I can successfully create windows HVM, my problem happened when I change windows screen resolution.
The qemu process suddenly  exited while xl list can still list the domU information.

    I am using debian wheezy 7.5 amd 64, I am using fantu's xen 4.5 unstable and the qemu-xen-remote in his code repository,
root@debian:~# /usr/lib/xen/bin/qemu-system-i386 -version
QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice Bellard  
 And I compiled Xen from fantu's xen repository in compilation server, then use install.sh in dist dir to install xen packages in my test server.
 My compilation server has spice 0.12.4 compiled and installed.
 My test server has debian wheezy backport qemu installed with spice-server:
dpkg -l |grep spice
ii  libspice-server1:amd64             0.12.4-0nocelt2~bpo70+1   
 Then how can I obtain useful debug information after qemu exit with vm running?




Best Regards
From: Fabio Fantoni
Date: 2014-07-11 18:06
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 11/07/2014 04:38, kevin.zhang@octlink.com ha scritto:

Hi all,

Firstly please forgive me if I put this problem in the wrong mail list. 
However, it seems that xen-users mail list cannot resolve this QXL problems. Therefore, I have to post QXL problem in devel mail list.
My problem is as follow:

I'm testing QXL for windows HVM, spice works well with stdvga. 
However, when I switch to QXL, qemu exit abnormally:
I specify vga="qxl" and videoram=128, using qemu-xen. The windows 7 boots and automatially switch resolution for me in virt-viewer.
While display and sound transfering very well, if I change display resolution, the virt-viewer will be suddenly closed and
I check the physical server, the qemu process disappear simultaneously. 
Then I switch to wheezy backport qemu 2.0 as device model, the qemu process will exit as soon as the welcome page appears and at the beginning of resolution change.
I tested and found the same bug on both xenbits xen 4.4.1 rc1 and Fantu's Xen 4.5 unstable, this problem exists in both branches.
Is it a known issue or is there any solution for this bug?
Thank you very much! 

Thanks for testing spice and qxl and report issue.
I have spice + qxl working as kvm on xen unstable except this problem:
http://lists.xen.org/archives/html/xen-devel/2014-07/msg01021.html

Please post details on your dom0 installation and domU (for example xl cfg,
spice guest tools version ecc...)
About qemu crash try to take a full backtrace with gdb and post it here.

Small help with gdb of qemu launched by xl:

Add the line below in domU's xl cfg:
device_model_override="/usr/lib/xen/bin/qemu-gdb"

vi /usr/lib/xen/bin/qemu-gdb # create the file, change the qemu path if
needed
#!/bin/sh
exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386 "$@"

# after xl create, do it fast (before timeout or xl create will fails)
target remote localhost:1234
c 
bt full # when qemu stops

You should install also all needed dbg packages before, spice qemu ecc or
without package should be compiled with debug enabled (for xen and qemu
default in unstable).

The latest qemu crash with spice I saw was in 2.0-rc solved before 2.0.0
final, your qemu is at least 2.0.0 final?
http://git.qemu.org/?p=qemu.git;a=commit;h=dc491cfc14074064ed54a872b62cce6ca1330644




Kevin
Best Regards,


 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[-- Attachment #1.2: Type: text/html, Size: 11665 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable

[kevin.zhang]

[-- Attachment #1.1: Type: text/plain, Size: 5900 bytes --]

Hi Fabio Fantoni,
    
     Today, I've done another test on xenbits xen 4.5 unstable.
     This time, I directly compiled xen on my test server, and use default libspice-server-dev  and libspice-protocol-dev header files for spice option.
    
root@debian:~# apt-cache policy libspice-server-dev libspice-protocol-dev
libspice-server-dev:
  Installed: 0.11.0-1+deb7u1
  Candidate: 0.11.0-1+deb7u1
  Version table:
*** 0.11.0-1+deb7u1 0
        500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status
libspice-protocol-dev:
  Installed: 0.10.1-1
  Candidate: 0.10.1-1
  Version table:
*** 0.10.1-1 0
        500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status

     I also download qemu-2.0 source code from qemu.org, and compiled it by the way mentioned in http://wiki.xen.org/wiki/QEMU_Upstream.
     Then I create win7 hvm with qemu-xen and /usr/local/bin/qemu-system-i386 respectively.
     The result shows that:
      1 . qemu-upstream used in xen 4.5 unstable still exited when changing screen resolution,
      2.  my self-compiled qemu2.0 behave normally.
     I think maybe there's still some differences between the two qemu repository.

     I'm actively waiting for your advice and willing to do the following debug.
     vm config file is as follow:
name='Win7'
builder="hvm"
memory=2048
vcpus=2
vif=['bridge=br0']
disk=['/srv/vm_templates/1.qcow2,qcow2,hda,rw',',raw,hdb,ro,cdrom']
boot='dc'
device_model_version="qemu-xen"
#device_model_override="/usr/lib/xen/bin/qemu-gdb"
#device_model_override="/usr/local/bin/qemu-system-i386"
viridian=1
vnc=1
vnclisten="0.0.0.0"
on_crash="destroy"
vga="qxl"
spice=1
spicehost='0.0.0.0'
spiceport=6000
spicedisable_ticketing=1
spicevdagent=1
spice_clipboard_sharing=1
spiceusbredirection=4
soundhw="hda"
localtime=1
videoram=128

   




Best Regards
From: kevin.zhang@octlink.com
Date: 2014-07-14 10:26
To: Fabio Fantoni; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Hi Fabio Fantoni,
    Thank you for your help.
     If I use your method to run qemu-gdb when using xl create, xl will complain startup timeout. 
    Perhaps I did not describe my problem clearly enough, I can successfully create windows HVM, my problem happened when I change windows screen resolution.
The qemu process suddenly  exited while xl list can still list the domU information.

    I am using debian wheezy 7.5 amd 64, I am using fantu's xen 4.5 unstable and the qemu-xen-remote in his code repository,
root@debian:~# /usr/lib/xen/bin/qemu-system-i386 -version
QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice Bellard  
 And I compiled Xen from fantu's xen repository in compilation server, then use install.sh in dist dir to install xen packages in my test server.
 My compilation server has spice 0.12.4 compiled and installed.
 My test server has debian wheezy backport qemu installed with spice-server:
dpkg -l |grep spice
ii  libspice-server1:amd64             0.12.4-0nocelt2~bpo70+1   
 Then how can I obtain useful debug information after qemu exit with vm running?




Best Regards
From: Fabio Fantoni
Date: 2014-07-11 18:06
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 11/07/2014 04:38, kevin.zhang@octlink.com ha scritto:

Hi all,

Firstly please forgive me if I put this problem in the wrong mail list. 
However, it seems that xen-users mail list cannot resolve this QXL problems. Therefore, I have to post QXL problem in devel mail list.
My problem is as follow:

I'm testing QXL for windows HVM, spice works well with stdvga. 
However, when I switch to QXL, qemu exit abnormally:
I specify vga="qxl" and videoram=128, using qemu-xen. The windows 7 boots and automatially switch resolution for me in virt-viewer.
While display and sound transfering very well, if I change display resolution, the virt-viewer will be suddenly closed and
I check the physical server, the qemu process disappear simultaneously. 
Then I switch to wheezy backport qemu 2.0 as device model, the qemu process will exit as soon as the welcome page appears and at the beginning of resolution change.
I tested and found the same bug on both xenbits xen 4.4.1 rc1 and Fantu's Xen 4.5 unstable, this problem exists in both branches.
Is it a known issue or is there any solution for this bug?
Thank you very much! 

Thanks for testing spice and qxl and report issue.
I have spice + qxl working as kvm on xen unstable except this problem:
http://lists.xen.org/archives/html/xen-devel/2014-07/msg01021.html

Please post details on your dom0 installation and domU (for example xl cfg,
spice guest tools version ecc...)
About qemu crash try to take a full backtrace with gdb and post it here.

Small help with gdb of qemu launched by xl:

Add the line below in domU's xl cfg:
device_model_override="/usr/lib/xen/bin/qemu-gdb"

vi /usr/lib/xen/bin/qemu-gdb # create the file, change the qemu path if
needed
#!/bin/sh
exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386 "$@"

# after xl create, do it fast (before timeout or xl create will fails)
target remote localhost:1234
c 
bt full # when qemu stops

You should install also all needed dbg packages before, spice qemu ecc or
without package should be compiled with debug enabled (for xen and qemu
default in unstable).

The latest qemu crash with spice I saw was in 2.0-rc solved before 2.0.0
final, your qemu is at least 2.0.0 final?
http://git.qemu.org/?p=qemu.git;a=commit;h=dc491cfc14074064ed54a872b62cce6ca1330644




Kevin
Best Regards,


 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[-- Attachment #1.2: Type: text/html, Size: 20853 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 7657 bytes --]

Il 14/07/2014 07:29, kevin.zhang@octlink.com ha scritto:
> Hi Fabio Fantoni,
>      Today, I've done another test on xenbits xen 4.5 unstable.
>      This time, I directly compiled xen on my test server, and use 
> default libspice-server-dev  and libspice-protocol-dev header files 
> for spice option.
>
>         root@debian:~# apt-cache policy libspice-server-dev
>         libspice-protocol-dev
>         libspice-server-dev:
>           Installed: 0.11.0-1+deb7u1
>           Candidate: 0.11.0-1+deb7u1
>           Version table:
>         *** 0.11.0-1+deb7u1 0
>                 500 http://cdn.debian.net/debian/ wheezy/main amd64
>         Packages
>                 100 /var/lib/dpkg/status
>         libspice-protocol-dev:
>           Installed: 0.10.1-1
>           Candidate: 0.10.1-1
>           Version table:
>         *** 0.10.1-1 0
>                 500 http://cdn.debian.net/debian/ wheezy/main amd64
>         Packages
>                 100 /var/lib/dpkg/status
>
>      I also download qemu-2.0 source code from qemu.org, and compiled 
> it by the way mentioned in http://wiki.xen.org/wiki/QEMU_Upstream.
>      Then I create win7 hvm with qemu-xen and 
> /usr/local/bin/qemu-system-i386 respectively.
>      The result shows that:
>       1 . qemu-upstream used in xen 4.5 unstable still exited when 
> changing screen resolution,
>       2.  my self-compiled qemu2.0 behave normally.
>      I think maybe there's still some differences between the two qemu 
> repository.

Use spice from backports or recompile the latest from Sid, wheezy 
packages are too old for newer qemu.
xen already download and compile qemu upstream automatically if you not 
specify binary in repository.
I also use use wheezy dom0 with same xen and qemu and same domU and 
spice guest tools installed automatically resize the windows resolution 
without problem (except rare cases when I connect remote-viewer before 
windows start).
Below also reply to other mail.

>      I'm actively waiting for your advice and willing to do the 
> following debug.
>      vm config file is as follow:
>
>     name='Win7'
>     builder="hvm"
>     memory=2048
>     vcpus=2
>     vif=['bridge=br0']
>     disk=['/srv/vm_templates/1.qcow2,qcow2,hda,rw',',raw,hdb,ro,cdrom']
>     boot='dc'
>     device_model_version="qemu-xen"
>     #device_model_override="/usr/lib/xen/bin/qemu-gdb"
>     #device_model_override="/usr/local/bin/qemu-system-i386"
>     viridian=1
>     vnc=1
>     vnclisten="0.0.0.0"
>     on_crash="destroy"
>     vga="qxl"
>     spice=1
>     spicehost='0.0.0.0'
>     spiceport=6000
>     spicedisable_ticketing=1
>     spicevdagent=1
>     spice_clipboard_sharing=1
>     spiceusbredirection=4
>     soundhw="hda"
>     localtime=1
>     videoram=128
>

videoram=128 is not needed with qxl as already the default.
Try to disable vnc when you use spice, even if I used with also vnc many 
times without problem time ago.

> ------------------------------------------------------------------------
> Best Regards
>
> *From:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>
> *Date:* 2014-07-14 10:26
> *To:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>; xen-devel 
> <mailto:xen-devel@lists.xen.org>
> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
> Hi Fabio Fantoni,
>     Thank you for your help.
>      If I use your method to run qemu-gdb when using xl create, xl 
> will complain startup timeout.

I know, I already posted the solution but I try to explain better.

# after xl create with (qemu gdb), do it fast after xl create when 
arrive on qemu process launch (before timeout or xl create will fails)
target remote localhost:1234 # prepare this command in other ssh to the 
xen dom0 and enter on xl create when arrive on qemu launch
c # press immediatly
bt full # when qemu stops

Sorry for my bad english.

>     Perhaps I did not describe my problem clearly enough, I can 
> successfully create windows HVM, my problem happened when I change 
> windows screen resolution.
> The qemu process suddenly  exited while xl list can still list the 
> domU information.
>     I am using debian wheezy 7.5 amd 64, I am using fantu's xen 4.5 
> unstable and the qemu-xen-remote in his code repository,
>
>     root@debian:~# /usr/lib/xen/bin/qemu-system-i386 -version
>     QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice Bellard
>
>  And I compiled Xen from fantu's xen repository in compilation server, 
> then use install.sh in dist dir to install xen packages in my test server.
>  My compilation server has spice 0.12.4 compiled and installed.
>  My test server has debian wheezy backport qemu installed with 
> spice-server:
>
>     dpkg -l |grep spice
>     ii libspice-server1:amd64 0.12.4-0nocelt2~bpo70+1
>
>  Then how can I obtain useful debug information after qemu exit with 
> vm running?
> ------------------------------------------------------------------------
> Best Regards
>
> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
> *Date:* 2014-07-11 18:06
> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>; 
> xen-devel <mailto:xen-devel@lists.xen.org>
> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
> Il 11/07/2014 04:38, kevin.zhang@octlink.com ha scritto:
>> Hi all,
>> Firstly please forgive me if I put this problem in the wrong mail list.
>> However, it seems that xen-users mail list cannot resolve this QXL 
>> problems. Therefore, I have to post QXL problem in devel mail list.
>> My problem is as follow:
>> I'm testing QXL for windows HVM, spice works well with stdvga.
>> However, when I switch to QXL, qemu exit abnormally:
>> I specify vga="qxl" and videoram=128, using qemu-xen. The windows 7 
>> boots and automatially switch resolution for me in virt-viewer.
>> While display and sound transfering very well, if I change display 
>> resolution, the virt-viewer will be suddenly closed and
>> I check the physical server, the qemu process disappear simultaneously.
>> Then I switch to wheezy backport qemu 2.0 as device model, the qemu 
>> process will exit as soon as the welcome page appears and at the 
>> beginning of resolution change.
>> I tested and found the same bug on both xenbits xen 4.4.1 rc1 and 
>> Fantu's Xen 4.5 unstable, this problem exists in both branches.
>> Is it a known issue or is there any solution for this bug?
>> Thank you very much!
>
> Thanks for testing spice and qxl and report issue.
> I have spice + qxl working as kvm on xen unstable except this problem:
> http://lists.xen.org/archives/html/xen-devel/2014-07/msg01021.html
>
> Please post details on your dom0 installation and domU (for example xl 
> cfg,
> spice guest tools version ecc...)
> About qemu crash try to take a full backtrace with gdb and post it here.
>
> Small help with gdb of qemu launched by xl:
>
> Add the line below in domU's xl cfg:
> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>
> vi /usr/lib/xen/bin/qemu-gdb # create the file, change the qemu path if
> needed
> #!/bin/sh
> exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386 "$@"
>
> # after xl create, do it fast (before timeout or xl create will fails)
> target remote localhost:1234
> c
> bt full # when qemu stops
>
> You should install also all needed dbg packages before, spice qemu ecc or
> without package should be compiled with debug enabled (for xen and qemu
> default in unstable).
>
> The latest qemu crash with spice I saw was in 2.0-rc solved before 2.0.0
> final, your qemu is at least 2.0.0 final?
> http://git.qemu.org/?p=qemu.git;a=commit;h=dc491cfc14074064ed54a872b62cce6ca1330644
>
>> Kevin
>> Best Regards,
>>
>>


[-- Attachment #1.2: Type: text/html, Size: 34442 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

回复: Re: QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable

[kevin.zhang]

[-- Attachment #1.1: Type: text/plain, Size: 7459 bytes --]

Hi Fabio Fantoni,
     
      Thank you for your reply.
      It is really weird. 
      I compiled both qemu binary ( qemu-upstream in xen and qemu-2.0 from qemu.org website) in the same environment,  the binary in xen has the problem while 
the other one works well.
      I will check whether wheezy backport has libspice-server-dev and libspice-protocol-dev and try again. 




Best Regards
From: Fabio Fantoni
Date: 2014-07-14 15:59
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 14/07/2014 07:29, kevin.zhang@octlink.com ha scritto:

Hi Fabio Fantoni,
    
     Today, I've done another test on xenbits xen 4.5 unstable.
     This time, I directly compiled xen on my test server, and use default libspice-server-dev  and libspice-protocol-dev header files for spice option.
    
root@debian:~# apt-cache policy libspice-server-dev libspice-protocol-dev
libspice-server-dev:
  Installed: 0.11.0-1+deb7u1
  Candidate: 0.11.0-1+deb7u1
  Version table:
*** 0.11.0-1+deb7u1 0
        500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status
libspice-protocol-dev:
  Installed: 0.10.1-1
  Candidate: 0.10.1-1
  Version table:
*** 0.10.1-1 0
        500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status

     I also download qemu-2.0 source code from qemu.org, and compiled it by the way mentioned in http://wiki.xen.org/wiki/QEMU_Upstream.
     Then I create win7 hvm with qemu-xen and /usr/local/bin/qemu-system-i386 respectively.
     The result shows that:
      1 . qemu-upstream used in xen 4.5 unstable still exited when changing screen resolution,
      2.  my self-compiled qemu2.0 behave normally.
     I think maybe there's still some differences between the two qemu repository.

Use spice from backports or recompile the latest from Sid, wheezy packages are too old for newer qemu.
xen already download and compile qemu upstream automatically if you not specify binary in repository.
I also use use wheezy dom0 with same xen and qemu and same domU and spice guest tools installed automatically resize the windows resolution without problem (except rare cases when I connect remote-viewer before windows start).
Below also reply to other mail.



     I'm actively waiting for your advice and willing to do the following debug.
     vm config file is as follow:
name='Win7'
builder="hvm"
memory=2048
vcpus=2
vif=['bridge=br0']
disk=['/srv/vm_templates/1.qcow2,qcow2,hda,rw',',raw,hdb,ro,cdrom']
boot='dc'
device_model_version="qemu-xen"
#device_model_override="/usr/lib/xen/bin/qemu-gdb"
#device_model_override="/usr/local/bin/qemu-system-i386"
viridian=1
vnc=1
vnclisten="0.0.0.0"
on_crash="destroy"
vga="qxl"
spice=1
spicehost='0.0.0.0'
spiceport=6000
spicedisable_ticketing=1
spicevdagent=1
spice_clipboard_sharing=1
spiceusbredirection=4
soundhw="hda"
localtime=1
videoram=128

videoram=128 is not needed with qxl as already the default.
Try to disable vnc when you use spice, even if I used with also vnc many times without problem time ago.



   




Best Regards
From: kevin.zhang@octlink.com
Date: 2014-07-14 10:26
To: Fabio Fantoni; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Hi Fabio Fantoni,
    Thank you for your help.
     If I use your method to run qemu-gdb when using xl create, xl will complain startup timeout. 

I know, I already posted the solution but I try to explain better.

# after xl create with (qemu gdb), do it fast after xl create when arrive on qemu process launch (before timeout or xl create will fails)
target remote localhost:1234 # prepare this command in other ssh to the xen dom0 and enter on xl create when arrive on qemu launch
c # press immediatly
bt full # when qemu stops

Sorry for my bad english.


    Perhaps I did not describe my problem clearly enough, I can successfully create windows HVM, my problem happened when I change windows screen resolution.
The qemu process suddenly  exited while xl list can still list the domU information.

    I am using debian wheezy 7.5 amd 64, I am using fantu's xen 4.5 unstable and the qemu-xen-remote in his code repository,
root@debian:~# /usr/lib/xen/bin/qemu-system-i386 -version
QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice Bellard  
 And I compiled Xen from fantu's xen repository in compilation server, then use install.sh in dist dir to install xen packages in my test server.
 My compilation server has spice 0.12.4 compiled and installed.
 My test server has debian wheezy backport qemu installed with spice-server:
dpkg -l |grep spice
ii  libspice-server1:amd64             0.12.4-0nocelt2~bpo70+1   
 Then how can I obtain useful debug information after qemu exit with vm running?




Best Regards
From: Fabio Fantoni
Date: 2014-07-11 18:06
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 11/07/2014 04:38, kevin.zhang@octlink.com ha scritto:

Hi all,

Firstly please forgive me if I put this problem in the wrong mail list. 
However, it seems that xen-users mail list cannot resolve this QXL problems. Therefore, I have to post QXL problem in devel mail list.
My problem is as follow:

I'm testing QXL for windows HVM, spice works well with stdvga. 
However, when I switch to QXL, qemu exit abnormally:
I specify vga="qxl" and videoram=128, using qemu-xen. The windows 7 boots and automatially switch resolution for me in virt-viewer.
While display and sound transfering very well, if I change display resolution, the virt-viewer will be suddenly closed and
I check the physical server, the qemu process disappear simultaneously. 
Then I switch to wheezy backport qemu 2.0 as device model, the qemu process will exit as soon as the welcome page appears and at the beginning of resolution change.
I tested and found the same bug on both xenbits xen 4.4.1 rc1 and Fantu's Xen 4.5 unstable, this problem exists in both branches.
Is it a known issue or is there any solution for this bug?
Thank you very much! 

Thanks for testing spice and qxl and report issue.
I have spice + qxl working as kvm on xen unstable except this problem:
http://lists.xen.org/archives/html/xen-devel/2014-07/msg01021.html

Please post details on your dom0 installation and domU (for example xl cfg,
spice guest tools version ecc...)
About qemu crash try to take a full backtrace with gdb and post it here.

Small help with gdb of qemu launched by xl:

Add the line below in domU's xl cfg:
device_model_override="/usr/lib/xen/bin/qemu-gdb"

vi /usr/lib/xen/bin/qemu-gdb # create the file, change the qemu path if
needed
#!/bin/sh
exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386 "$@"

# after xl create, do it fast (before timeout or xl create will fails)
target remote localhost:1234
c 
bt full # when qemu stops

You should install also all needed dbg packages before, spice qemu ecc or
without package should be compiled with debug enabled (for xen and qemu
default in unstable).

The latest qemu crash with spice I saw was in 2.0-rc solved before 2.0.0
final, your qemu is at least 2.0.0 final?
http://git.qemu.org/?p=qemu.git;a=commit;h=dc491cfc14074064ed54a872b62cce6ca1330644




Kevin
Best Regards,

[-- Attachment #1.2: Type: text/html, Size: 28863 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable

[kevin.zhang]

[-- Attachment #1.1: Type: text/plain, Size: 9280 bytes --]

Hi Fabio Fantoni,
      Today I tried to use wheezy backports version of spice-server, the problem persists with qemu-xen binary, while my self compiled qemu 2.0 works well.
I think it is a problem and can be repeated.
     Then, I will summarize my compilation process here:
     Firstly install debian wheezy 7.5 amd64 and necessary build dependency. Then:
1. git clone  git://xenbits.xen.org/xen.git
2.  install backport version  libspice-server-dev libspice-protocol-dev
root@debian:~#  apt-cache policy libspice-server-dev libspice-protocol-dev
libspice-server-dev:
  Installed: 0.12.4-0nocelt2~bpo70+1
  Candidate: 0.12.4-0nocelt2~bpo70+1
  Version table:
*** 0.12.4-0nocelt2~bpo70+1 0
        100 http://cdn.debian.net/debian/ wheezy-backports/main amd64 Packages
        100 /var/lib/dpkg/status
libspice-protocol-dev:
  Installed: 0.12.6-1~bpo70+2
  Candidate: 0.12.6-1~bpo70+2
  Version table:
*** 0.12.6-1~bpo70+2 0
        100 http://cdn.debian.net/debian/ wheezy-backports/main amd64 Packages
        100 /var/lib/dpkg/status
 3. patch for QXL option
 4. ./configure --prefix=/usr 
 5. add spice and usb-redir option for qemu-xen-upstream
 6. make xen;make tools;make install-xen;make install-tools

       To compile qemu 2.0 from qemu.org:
       1. wget http://wiki.qemu-project.org/download/qemu-2.0.0.tar.bz2
       2. ./configure --enable-xen --target-list=i386-softmmu --extra-cflags="-I/usr/src/xen/tools/include -I/usr/src/xen/tools/libxc -I/usr/src/xen/tools/xenstore" \
            --enable-spice --enable-usb-redir 
       3 .make;make install






Best Regards
发件人： kevin.zhang@octlink.com
发送时间： 2014-07-14 16:49
收件人： Fabio Fantoni; xen-devel
主题： 回复: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Hi Fabio Fantoni,
     
      Thank you for your reply.
      It is really weird. 
      I compiled both qemu binary ( qemu-upstream in xen and qemu-2.0 from qemu.org website) in the same environment,  the binary in xen has the problem while 
the other one works well.
      I will check whether wheezy backport has libspice-server-dev and libspice-protocol-dev and try again. 




Best Regards
From: Fabio Fantoni
Date: 2014-07-14 15:59
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 14/07/2014 07:29, kevin.zhang@octlink.com ha scritto:

Hi Fabio Fantoni,
    
     Today, I've done another test on xenbits xen 4.5 unstable.
     This time, I directly compiled xen on my test server, and use default libspice-server-dev  and libspice-protocol-dev header files for spice option.
    
root@debian:~# apt-cache policy libspice-server-dev libspice-protocol-dev
libspice-server-dev:
  Installed: 0.11.0-1+deb7u1
  Candidate: 0.11.0-1+deb7u1
  Version table:
*** 0.11.0-1+deb7u1 0
        500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status
libspice-protocol-dev:
  Installed: 0.10.1-1
  Candidate: 0.10.1-1
  Version table:
*** 0.10.1-1 0
        500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status

     I also download qemu-2.0 source code from qemu.org, and compiled it by the way mentioned in http://wiki.xen.org/wiki/QEMU_Upstream.
     Then I create win7 hvm with qemu-xen and /usr/local/bin/qemu-system-i386 respectively.
     The result shows that:
      1 . qemu-upstream used in xen 4.5 unstable still exited when changing screen resolution,
      2.  my self-compiled qemu2.0 behave normally.
     I think maybe there's still some differences between the two qemu repository.

Use spice from backports or recompile the latest from Sid, wheezy packages are too old for newer qemu.
xen already download and compile qemu upstream automatically if you not specify binary in repository.
I also use use wheezy dom0 with same xen and qemu and same domU and spice guest tools installed automatically resize the windows resolution without problem (except rare cases when I connect remote-viewer before windows start).
Below also reply to other mail.



     I'm actively waiting for your advice and willing to do the following debug.
     vm config file is as follow:
name='Win7'
builder="hvm"
memory=2048
vcpus=2
vif=['bridge=br0']
disk=['/srv/vm_templates/1.qcow2,qcow2,hda,rw',',raw,hdb,ro,cdrom']
boot='dc'
device_model_version="qemu-xen"
#device_model_override="/usr/lib/xen/bin/qemu-gdb"
#device_model_override="/usr/local/bin/qemu-system-i386"
viridian=1
vnc=1
vnclisten="0.0.0.0"
on_crash="destroy"
vga="qxl"
spice=1
spicehost='0.0.0.0'
spiceport=6000
spicedisable_ticketing=1
spicevdagent=1
spice_clipboard_sharing=1
spiceusbredirection=4
soundhw="hda"
localtime=1
videoram=128

videoram=128 is not needed with qxl as already the default.
Try to disable vnc when you use spice, even if I used with also vnc many times without problem time ago.



   




Best Regards
From: kevin.zhang@octlink.com
Date: 2014-07-14 10:26
To: Fabio Fantoni; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Hi Fabio Fantoni,
    Thank you for your help.
     If I use your method to run qemu-gdb when using xl create, xl will complain startup timeout. 

I know, I already posted the solution but I try to explain better.

# after xl create with (qemu gdb), do it fast after xl create when arrive on qemu process launch (before timeout or xl create will fails)
target remote localhost:1234 # prepare this command in other ssh to the xen dom0 and enter on xl create when arrive on qemu launch
c # press immediatly
bt full # when qemu stops

Sorry for my bad english.


    Perhaps I did not describe my problem clearly enough, I can successfully create windows HVM, my problem happened when I change windows screen resolution.
The qemu process suddenly  exited while xl list can still list the domU information.

    I am using debian wheezy 7.5 amd 64, I am using fantu's xen 4.5 unstable and the qemu-xen-remote in his code repository,
root@debian:~# /usr/lib/xen/bin/qemu-system-i386 -version
QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice Bellard  
 And I compiled Xen from fantu's xen repository in compilation server, then use install.sh in dist dir to install xen packages in my test server.
 My compilation server has spice 0.12.4 compiled and installed.
 My test server has debian wheezy backport qemu installed with spice-server:
dpkg -l |grep spice
ii  libspice-server1:amd64             0.12.4-0nocelt2~bpo70+1   
 Then how can I obtain useful debug information after qemu exit with vm running?




Best Regards
From: Fabio Fantoni
Date: 2014-07-11 18:06
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 11/07/2014 04:38, kevin.zhang@octlink.com ha scritto:

Hi all,

Firstly please forgive me if I put this problem in the wrong mail list. 
However, it seems that xen-users mail list cannot resolve this QXL problems. Therefore, I have to post QXL problem in devel mail list.
My problem is as follow:

I'm testing QXL for windows HVM, spice works well with stdvga. 
However, when I switch to QXL, qemu exit abnormally:
I specify vga="qxl" and videoram=128, using qemu-xen. The windows 7 boots and automatially switch resolution for me in virt-viewer.
While display and sound transfering very well, if I change display resolution, the virt-viewer will be suddenly closed and
I check the physical server, the qemu process disappear simultaneously. 
Then I switch to wheezy backport qemu 2.0 as device model, the qemu process will exit as soon as the welcome page appears and at the beginning of resolution change.
I tested and found the same bug on both xenbits xen 4.4.1 rc1 and Fantu's Xen 4.5 unstable, this problem exists in both branches.
Is it a known issue or is there any solution for this bug?
Thank you very much! 

Thanks for testing spice and qxl and report issue.
I have spice + qxl working as kvm on xen unstable except this problem:
http://lists.xen.org/archives/html/xen-devel/2014-07/msg01021.html

Please post details on your dom0 installation and domU (for example xl cfg,
spice guest tools version ecc...)
About qemu crash try to take a full backtrace with gdb and post it here.

Small help with gdb of qemu launched by xl:

Add the line below in domU's xl cfg:
device_model_override="/usr/lib/xen/bin/qemu-gdb"

vi /usr/lib/xen/bin/qemu-gdb # create the file, change the qemu path if
needed
#!/bin/sh
exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386 "$@"

# after xl create, do it fast (before timeout or xl create will fails)
target remote localhost:1234
c 
bt full # when qemu stops

You should install also all needed dbg packages before, spice qemu ecc or
without package should be compiled with debug enabled (for xen and qemu
default in unstable).

The latest qemu crash with spice I saw was in 2.0-rc solved before 2.0.0
final, your qemu is at least 2.0.0 final?
http://git.qemu.org/?p=qemu.git;a=commit;h=dc491cfc14074064ed54a872b62cce6ca1330644




Kevin
Best Regards,

[-- Attachment #1.2: Type: text/html, Size: 37297 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 12420 bytes --]

Il 15/07/2014 07:53, kevin.zhang@octlink.com ha scritto:
> Hi Fabio Fantoni,
>       Today I tried to use wheezy backports version of spice-server, 
> the problem persists with qemu-xen binary, while my self compiled qemu 
> 2.0 works well.
> I think it is a problem and can be repeated.
>      Then, I will summarize my compilation process here:
>      Firstly install debian wheezy 7.5 amd64 and necessary build 
> dependency. Then:
>
>     1. git clone git://xenbits.xen.org/xen.git
>     <http://xenbits.xen.org/gitweb/?p=xen.git>
>     2.  install backport version libspice-server-dev libspice-protocol-dev
>
>         root@debian:~#  apt-cache policy libspice-server-dev
>         libspice-protocol-dev
>         libspice-server-dev:
>           Installed: 0.12.4-0nocelt2~bpo70+1
>           Candidate: 0.12.4-0nocelt2~bpo70+1
>           Version table:
>         *** 0.12.4-0nocelt2~bpo70+1 0
>                 100 http://cdn.debian.net/debian/
>         wheezy-backports/main amd64 Packages
>                 100 /var/lib/dpkg/status
>         libspice-protocol-dev:
>           Installed: 0.12.6-1~bpo70+2
>           Candidate: 0.12.6-1~bpo70+2
>           Version table:
>         *** 0.12.6-1~bpo70+2 0
>                 100 http://cdn.debian.net/debian/
>         wheezy-backports/main amd64 Packages
>                 100 /var/lib/dpkg/status
>
>      3. patch for QXL option
>      4. ./configure --prefix=/usr
>      5. add spice and usb-redir option for qemu-xen-upstream
>      6. make xen;make tools;make install-xen;make install-tools
>
>        To compile qemu 2.0 from qemu.org:
>        1. wget http://wiki.qemu-project.org/download/qemu-2.0.0.tar.bz2
>        2. ./configure --enable-xen --target-list=i386-softmmu 
> --extra-cflags="-I/usr/src/xen/tools/include 
> -I/usr/src/xen/tools/libxc -I/usr/src/xen/tools/xenstore" \
>             --enable-spice --enable-usb-redir
>        3 .make;make install

For fast unstable tests I do this (using my github rebase/m2r-*):
Install of opus, usbredir and libusbx from backports.
Rebuild and install new seabios 1.7.5-1 and spice packages (server 
0.12.5-1 and protocol 0.12.7-1) from sid that contains many fixes 
(simply and fast with git clone of debian repository and debuild).
./configure --prefix=/usr --enable-qemu-traditional=no 
--with-system-seabios=/usr/share/seabios/bios-256k.bin 
--with-extra-qemuu-configure-args="--enable-spice --enable-usb-redir"
make debball
dpkg -i of xen package in dist (contain both xen and qemu)
And if I need to test newer qemu in development I simply change the qemu 
git with mainline in Config.mk.

And for newer production servers I start prepared new xen's debian 
packages awaiting debian maintainers replies:
https://github.com/Fantu/pkg-xen/tree/wheezy-backports
Needs also qemu rebuild to use new xen 4.4 libraries (simply and fast 
with git clone of debian repository and debuild).

There is also a problem of jpeg-turbo in debian and for have better 
performances and not too many cpu waste I for now solved with:
apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E
vi /etc/apt/sources.list.d/x2go.list
# X2Go Repository (for jpeg-turbo as default and with full -dev package)
deb http://packages.x2go.org/debian wheezy heuler
deb-src http://packages.x2go.org/debian wheezy heuler
aptitude update
aptitude install x2go-keyring && aptitude update
aptitude install libjpeg8-turbo-dev

> ------------------------------------------------------------------------
> Best Regards
>
> *???:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>
> *????:* 2014-07-14 16:49
> *???:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>; xen-devel 
> <mailto:xen-devel@lists.xen.org>
> *??:* ??: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
> Hi Fabio Fantoni,
>       Thank you for your reply.
>       It is really weird.
>       I compiled both qemu binary ( qemu-upstream in xen and qemu-2.0 
> from qemu.org website) in the same environment,  the binary in xen has 
> the problem while
> the other one works well.
>       I will check whether wheezy backport has libspice-server-dev and 
> libspice-protocol-dev and try again.
> ------------------------------------------------------------------------
> Best Regards
>
> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
> *Date:* 2014-07-14 15:59
> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>; 
> xen-devel <mailto:xen-devel@lists.xen.org>
> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
> Il 14/07/2014 07:29, kevin.zhang@octlink.com ha scritto:
>> Hi Fabio Fantoni,
>>      Today, I've done another test on xenbits xen 4.5 unstable.
>>      This time, I directly compiled xen on my test server, and use 
>> default libspice-server-dev  and libspice-protocol-dev header files 
>> for spice option.
>>
>>         root@debian:~# apt-cache policy libspice-server-dev
>>         libspice-protocol-dev
>>         libspice-server-dev:
>>           Installed: 0.11.0-1+deb7u1
>>           Candidate: 0.11.0-1+deb7u1
>>           Version table:
>>         *** 0.11.0-1+deb7u1 0
>>                 500 http://cdn.debian.net/debian/ wheezy/main amd64
>>         Packages
>>                 100 /var/lib/dpkg/status
>>         libspice-protocol-dev:
>>           Installed: 0.10.1-1
>>           Candidate: 0.10.1-1
>>           Version table:
>>         *** 0.10.1-1 0
>>                 500 http://cdn.debian.net/debian/ wheezy/main amd64
>>         Packages
>>                 100 /var/lib/dpkg/status
>>
>>      I also download qemu-2.0 source code from qemu.org, and compiled 
>> it by the way mentioned in http://wiki.xen.org/wiki/QEMU_Upstream.
>>      Then I create win7 hvm with qemu-xen and 
>> /usr/local/bin/qemu-system-i386 respectively.
>>      The result shows that:
>>       1 . qemu-upstream used in xen 4.5 unstable still exited when 
>> changing screen resolution,
>>       2.  my self-compiled qemu2.0 behave normally.
>>      I think maybe there's still some differences between the two 
>> qemu repository.
>
> Use spice from backports or recompile the latest from Sid, wheezy 
> packages are too old for newer qemu.
> xen already download and compile qemu upstream automatically if you 
> not specify binary in repository.
> I also use use wheezy dom0 with same xen and qemu and same domU and 
> spice guest tools installed automatically resize the windows 
> resolution without problem (except rare cases when I connect 
> remote-viewer before windows start).
> Below also reply to other mail.
>
>>      I'm actively waiting for your advice and willing to do the 
>> following debug.
>>      vm config file is as follow:
>>
>>     name='Win7'
>>     builder="hvm"
>>     memory=2048
>>     vcpus=2
>>     vif=['bridge=br0']
>>     disk=['/srv/vm_templates/1.qcow2,qcow2,hda,rw',',raw,hdb,ro,cdrom']
>>     boot='dc'
>>     device_model_version="qemu-xen"
>>     #device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>     #device_model_override="/usr/local/bin/qemu-system-i386"
>>     viridian=1
>>     vnc=1
>>     vnclisten="0.0.0.0"
>>     on_crash="destroy"
>>     vga="qxl"
>>     spice=1
>>     spicehost='0.0.0.0'
>>     spiceport=6000
>>     spicedisable_ticketing=1
>>     spicevdagent=1
>>     spice_clipboard_sharing=1
>>     spiceusbredirection=4
>>     soundhw="hda"
>>     localtime=1
>>     videoram=128
>>
>
> videoram=128 is not needed with qxl as already the default.
> Try to disable vnc when you use spice, even if I used with also vnc 
> many times without problem time ago.
>
>> ------------------------------------------------------------------------
>> Best Regards
>>
>> *From:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>
>> *Date:* 2014-07-14 10:26
>> *To:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>; xen-devel 
>> <mailto:xen-devel@lists.xen.org>
>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 
>> unstable
>> Hi Fabio Fantoni,
>>     Thank you for your help.
>>      If I use your method to run qemu-gdb when using xl create, xl 
>> will complain startup timeout.
>
> I know, I already posted the solution but I try to explain better.
>
> # after xl create with (qemu gdb), do it fast after xl create when 
> arrive on qemu process launch (before timeout or xl create will fails)
> target remote localhost:1234 # prepare this command in other ssh to 
> the xen dom0 and enter on xl create when arrive on qemu launch
> c # press immediatly
> bt full # when qemu stops
>
> Sorry for my bad english.
>
>>     Perhaps I did not describe my problem clearly enough, I can 
>> successfully create windows HVM, my problem happened when I change 
>> windows screen resolution.
>> The qemu process suddenly  exited while xl list can still list the 
>> domU information.
>>     I am using debian wheezy 7.5 amd 64, I am using fantu's xen 4.5 
>> unstable and the qemu-xen-remote in his code repository,
>>
>>     root@debian:~# /usr/lib/xen/bin/qemu-system-i386 -version
>>     QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice Bellard
>>
>>  And I compiled Xen from fantu's xen repository in compilation 
>> server, then use install.sh in dist dir to install xen packages in my 
>> test server.
>>  My compilation server has spice 0.12.4 compiled and installed.
>>  My test server has debian wheezy backport qemu installed with 
>> spice-server:
>>
>>     dpkg -l |grep spice
>>     ii libspice-server1:amd64 0.12.4-0nocelt2~bpo70+1
>>
>>  Then how can I obtain useful debug information after qemu exit with 
>> vm running?
>> ------------------------------------------------------------------------
>> Best Regards
>>
>> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
>> *Date:* 2014-07-11 18:06
>> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>; 
>> xen-devel <mailto:xen-devel@lists.xen.org>
>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 
>> unstable
>> Il 11/07/2014 04:38, kevin.zhang@octlink.com ha scritto:
>>> Hi all,
>>> Firstly please forgive me if I put this problem in the wrong mail list.
>>> However, it seems that xen-users mail list cannot resolve this QXL 
>>> problems. Therefore, I have to post QXL problem in devel mail list.
>>> My problem is as follow:
>>> I'm testing QXL for windows HVM, spice works well with stdvga.
>>> However, when I switch to QXL, qemu exit abnormally:
>>> I specify vga="qxl" and videoram=128, using qemu-xen. The windows 7 
>>> boots and automatially switch resolution for me in virt-viewer.
>>> While display and sound transfering very well, if I change display 
>>> resolution, the virt-viewer will be suddenly closed and
>>> I check the physical server, the qemu process disappear simultaneously.
>>> Then I switch to wheezy backport qemu 2.0 as device model, the qemu 
>>> process will exit as soon as the welcome page appears and at the 
>>> beginning of resolution change.
>>> I tested and found the same bug on both xenbits xen 4.4.1 rc1 and 
>>> Fantu's Xen 4.5 unstable, this problem exists in both branches.
>>> Is it a known issue or is there any solution for this bug?
>>> Thank you very much!
>>
>> Thanks for testing spice and qxl and report issue.
>> I have spice + qxl working as kvm on xen unstable except this problem:
>> http://lists.xen.org/archives/html/xen-devel/2014-07/msg01021.html
>>
>> Please post details on your dom0 installation and domU (for example 
>> xl cfg,
>> spice guest tools version ecc...)
>> About qemu crash try to take a full backtrace with gdb and post it here.
>>
>> Small help with gdb of qemu launched by xl:
>>
>> Add the line below in domU's xl cfg:
>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>
>> vi /usr/lib/xen/bin/qemu-gdb # create the file, change the qemu path if
>> needed
>> #!/bin/sh
>> exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386 "$@"
>>
>> # after xl create, do it fast (before timeout or xl create will fails)
>> target remote localhost:1234
>> c
>> bt full # when qemu stops
>>
>> You should install also all needed dbg packages before, spice qemu ecc or
>> without package should be compiled with debug enabled (for xen and qemu
>> default in unstable).
>>
>> The latest qemu crash with spice I saw was in 2.0-rc solved before 2.0.0
>> final, your qemu is at least 2.0.0 final?
>> http://git.qemu.org/?p=qemu.git;a=commit;h=dc491cfc14074064ed54a872b62cce6ca1330644
>>
>>> Kevin
>>> Best Regards,
>>>
>>>
>


[-- Attachment #1.2: Type: text/html, Size: 71257 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

回复: Re: QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable

[kevin.zhang]

[-- Attachment #1.1: Type: text/plain, Size: 11634 bytes --]

Hi Fabio Fantoni,

     Thank you for your advice for building xen unstable.
     Because I have to use debian wheezy as production distro, I've got to do the test in it.
     Today, I edit Config.mk and write:
QEMU_UPSTREAM_URL = git://git.qemu.org/qemu.git
QEMU_UPSTREAM_REVISION = master
     Then, the built qemu-xen binary works well.  Therefore, I guess that git://xenbits.xen.org/qemu-upstream-unstable.git  has some very little difference
compared to qemu.git. Maybe your environment cannot repeat  that problem either, I'd like to provide any useful information to resolve this problem.




Best Regards
From: Fabio Fantoni
Date: 2014-07-15 16:09
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 15/07/2014 07:53, kevin.zhang@octlink.com ha scritto:

Hi Fabio Fantoni,
      Today I tried to use wheezy backports version of spice-server, the problem persists with qemu-xen binary, while my self compiled qemu 2.0 works well.
I think it is a problem and can be repeated.
     Then, I will summarize my compilation process here:
     Firstly install debian wheezy 7.5 amd64 and necessary build dependency. Then:
1. git clone  git://xenbits.xen.org/xen.git
2.  install backport version  libspice-server-dev libspice-protocol-dev
root@debian:~#  apt-cache policy libspice-server-dev libspice-protocol-dev
libspice-server-dev:
  Installed: 0.12.4-0nocelt2~bpo70+1
  Candidate: 0.12.4-0nocelt2~bpo70+1
  Version table:
*** 0.12.4-0nocelt2~bpo70+1 0
        100 http://cdn.debian.net/debian/ wheezy-backports/main amd64 Packages
        100 /var/lib/dpkg/status
libspice-protocol-dev:
  Installed: 0.12.6-1~bpo70+2
  Candidate: 0.12.6-1~bpo70+2
  Version table:
*** 0.12.6-1~bpo70+2 0
        100 http://cdn.debian.net/debian/ wheezy-backports/main amd64 Packages
        100 /var/lib/dpkg/status
 3. patch for QXL option
 4. ./configure --prefix=/usr 
 5. add spice and usb-redir option for qemu-xen-upstream
 6. make xen;make tools;make install-xen;make install-tools

       To compile qemu 2.0 from qemu.org:
       1. wget http://wiki.qemu-project.org/download/qemu-2.0.0.tar.bz2
       2. ./configure --enable-xen --target-list=i386-softmmu --extra-cflags="-I/usr/src/xen/tools/include -I/usr/src/xen/tools/libxc -I/usr/src/xen/tools/xenstore" \
            --enable-spice --enable-usb-redir 
       3 .make;make install



For fast unstable tests I do this (using my github rebase/m2r-*):
Install of opus, usbredir and libusbx from backports.
Rebuild and install new seabios 1.7.5-1 and spice packages (server 0.12.5-1 and protocol 0.12.7-1) from sid that contains many fixes (simply and fast with git clone of debian repository and debuild).
./configure --prefix=/usr --enable-qemu-traditional=no --with-system-seabios=/usr/share/seabios/bios-256k.bin --with-extra-qemuu-configure-args="--enable-spice --enable-usb-redir"
make debball
dpkg -i of xen package in dist (contain both xen and qemu)
And if I need to test newer qemu in development I simply change the qemu git with mainline in Config.mk.

And for newer production servers I start prepared new xen's debian packages awaiting debian maintainers replies:
https://github.com/Fantu/pkg-xen/tree/wheezy-backports
Needs also qemu rebuild to use new xen 4.4 libraries (simply and fast with git clone of debian repository and debuild).

There is also a problem of jpeg-turbo in debian and for have better performances and not too many cpu waste I for now solved with:
apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E
vi /etc/apt/sources.list.d/x2go.list
# X2Go Repository (for jpeg-turbo as default and with full -dev package)
deb http://packages.x2go.org/debian wheezy heuler
deb-src http://packages.x2go.org/debian wheezy heuler
aptitude update
aptitude install x2go-keyring && aptitude update
aptitude install libjpeg8-turbo-dev






Best Regards
发件人： kevin.zhang@octlink.com
发送时间： 2014-07-14 16:49
收件人： Fabio Fantoni; xen-devel
主题： 回复: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Hi Fabio Fantoni,
     
      Thank you for your reply.
      It is really weird. 
      I compiled both qemu binary ( qemu-upstream in xen and qemu-2.0 from qemu.org website) in the same environment,  the binary in xen has the problem while 
the other one works well.
      I will check whether wheezy backport has libspice-server-dev and libspice-protocol-dev and try again. 




Best Regards
From: Fabio Fantoni
Date: 2014-07-14 15:59
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 14/07/2014 07:29, kevin.zhang@octlink.com ha scritto:

Hi Fabio Fantoni,
    
     Today, I've done another test on xenbits xen 4.5 unstable.
     This time, I directly compiled xen on my test server, and use default libspice-server-dev  and libspice-protocol-dev header files for spice option.
    
root@debian:~# apt-cache policy libspice-server-dev libspice-protocol-dev
libspice-server-dev:
  Installed: 0.11.0-1+deb7u1
  Candidate: 0.11.0-1+deb7u1
  Version table:
*** 0.11.0-1+deb7u1 0
        500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status
libspice-protocol-dev:
  Installed: 0.10.1-1
  Candidate: 0.10.1-1
  Version table:
*** 0.10.1-1 0
        500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status

     I also download qemu-2.0 source code from qemu.org, and compiled it by the way mentioned in http://wiki.xen.org/wiki/QEMU_Upstream.
     Then I create win7 hvm with qemu-xen and /usr/local/bin/qemu-system-i386 respectively.
     The result shows that:
      1 . qemu-upstream used in xen 4.5 unstable still exited when changing screen resolution,
      2.  my self-compiled qemu2.0 behave normally.
     I think maybe there's still some differences between the two qemu repository.

Use spice from backports or recompile the latest from Sid, wheezy packages are too old for newer qemu.
xen already download and compile qemu upstream automatically if you not specify binary in repository.
I also use use wheezy dom0 with same xen and qemu and same domU and spice guest tools installed automatically resize the windows resolution without problem (except rare cases when I connect remote-viewer before windows start).
Below also reply to other mail.



     I'm actively waiting for your advice and willing to do the following debug.
     vm config file is as follow:
name='Win7'
builder="hvm"
memory=2048
vcpus=2
vif=['bridge=br0']
disk=['/srv/vm_templates/1.qcow2,qcow2,hda,rw',',raw,hdb,ro,cdrom']
boot='dc'
device_model_version="qemu-xen"
#device_model_override="/usr/lib/xen/bin/qemu-gdb"
#device_model_override="/usr/local/bin/qemu-system-i386"
viridian=1
vnc=1
vnclisten="0.0.0.0"
on_crash="destroy"
vga="qxl"
spice=1
spicehost='0.0.0.0'
spiceport=6000
spicedisable_ticketing=1
spicevdagent=1
spice_clipboard_sharing=1
spiceusbredirection=4
soundhw="hda"
localtime=1
videoram=128

videoram=128 is not needed with qxl as already the default.
Try to disable vnc when you use spice, even if I used with also vnc many times without problem time ago.



   




Best Regards
From: kevin.zhang@octlink.com
Date: 2014-07-14 10:26
To: Fabio Fantoni; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Hi Fabio Fantoni,
    Thank you for your help.
     If I use your method to run qemu-gdb when using xl create, xl will complain startup timeout. 

I know, I already posted the solution but I try to explain better.

# after xl create with (qemu gdb), do it fast after xl create when arrive on qemu process launch (before timeout or xl create will fails)
target remote localhost:1234 # prepare this command in other ssh to the xen dom0 and enter on xl create when arrive on qemu launch
c # press immediatly
bt full # when qemu stops

Sorry for my bad english.


    Perhaps I did not describe my problem clearly enough, I can successfully create windows HVM, my problem happened when I change windows screen resolution.
The qemu process suddenly  exited while xl list can still list the domU information.

    I am using debian wheezy 7.5 amd 64, I am using fantu's xen 4.5 unstable and the qemu-xen-remote in his code repository,
root@debian:~# /usr/lib/xen/bin/qemu-system-i386 -version
QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice Bellard  
 And I compiled Xen from fantu's xen repository in compilation server, then use install.sh in dist dir to install xen packages in my test server.
 My compilation server has spice 0.12.4 compiled and installed.
 My test server has debian wheezy backport qemu installed with spice-server:
dpkg -l |grep spice
ii  libspice-server1:amd64             0.12.4-0nocelt2~bpo70+1   
 Then how can I obtain useful debug information after qemu exit with vm running?




Best Regards
From: Fabio Fantoni
Date: 2014-07-11 18:06
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 11/07/2014 04:38, kevin.zhang@octlink.com ha scritto:

Hi all,

Firstly please forgive me if I put this problem in the wrong mail list. 
However, it seems that xen-users mail list cannot resolve this QXL problems. Therefore, I have to post QXL problem in devel mail list.
My problem is as follow:

I'm testing QXL for windows HVM, spice works well with stdvga. 
However, when I switch to QXL, qemu exit abnormally:
I specify vga="qxl" and videoram=128, using qemu-xen. The windows 7 boots and automatially switch resolution for me in virt-viewer.
While display and sound transfering very well, if I change display resolution, the virt-viewer will be suddenly closed and
I check the physical server, the qemu process disappear simultaneously. 
Then I switch to wheezy backport qemu 2.0 as device model, the qemu process will exit as soon as the welcome page appears and at the beginning of resolution change.
I tested and found the same bug on both xenbits xen 4.4.1 rc1 and Fantu's Xen 4.5 unstable, this problem exists in both branches.
Is it a known issue or is there any solution for this bug?
Thank you very much! 

Thanks for testing spice and qxl and report issue.
I have spice + qxl working as kvm on xen unstable except this problem:
http://lists.xen.org/archives/html/xen-devel/2014-07/msg01021.html

Please post details on your dom0 installation and domU (for example xl cfg,
spice guest tools version ecc...)
About qemu crash try to take a full backtrace with gdb and post it here.

Small help with gdb of qemu launched by xl:

Add the line below in domU's xl cfg:
device_model_override="/usr/lib/xen/bin/qemu-gdb"

vi /usr/lib/xen/bin/qemu-gdb # create the file, change the qemu path if
needed
#!/bin/sh
exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386 "$@"

# after xl create, do it fast (before timeout or xl create will fails)
target remote localhost:1234
c 
bt full # when qemu stops

You should install also all needed dbg packages before, spice qemu ecc or
without package should be compiled with debug enabled (for xen and qemu
default in unstable).

The latest qemu crash with spice I saw was in 2.0-rc solved before 2.0.0
final, your qemu is at least 2.0.0 final?
http://git.qemu.org/?p=qemu.git;a=commit;h=dc491cfc14074064ed54a872b62cce6ca1330644




Kevin
Best Regards,

[-- Attachment #1.2: Type: text/html, Size: 46978 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: 回复: Re: QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 15035 bytes --]

Il 16/07/2014 09:04, kevin.zhang@octlink.com ha scritto:
> Hi Fabio Fantoni,
>      Thank you for your advice for building xen unstable.
>      Because I have to use debian wheezy as production distro, I've
> got to do the test in it.
>      Today, I edit Config.mk and write:
> QEMU_UPSTREAM_URL = git://git.qemu.org/qemu.git
> QEMU_UPSTREAM_REVISION = master
>      Then, the built qemu-xen binary works well.  Therefore, I guess
> that git://xenbits.xen.org/qemu-upstream-unstable.git has some very
> little difference
> compared to qemu.git. Maybe your environment cannot repeat that
> problem either, I'd like to provide any useful information to resolve
> this problem.

I also use wheezy for both production and develop/testing.
I tried now on my latest testing build, of some days ago xen from
rebase/m2r-staging branch and qemu mainline with same Config.mk before
build.
On windows 7 pro 64 bit domUs with latest spice guest tools auto and
manual resolution change works without problem.
I'm still unable to reproduce your qemu crash.

You can retry to catch and post backtrace with my latest better explain?

> I know, I already posted the solution but I try to explain better.
>
> # after xl create with (qemu gdb), do it fast after xl create when
> arrive on qemu process launch (before timeout or xl create will fails)
> target remote localhost:1234 # prepare this command in other ssh to
> the xen dom0 and enter on xl create when arrive on qemu launch
> c # press immediatly
> bt full # when qemu stops
>
> Sorry for my bad english.


> ------------------------------------------------------------------------
> Best Regards
>
> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
> *Date:* 2014-07-15 16:09
> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>;
> xen-devel <mailto:xen-devel@lists.xen.org>
> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
> Il 15/07/2014 07:53, kevin.zhang@octlink.com ha scritto:
>> Hi Fabio Fantoni,
>>       Today I tried to use wheezy backports version of spice-server,
>> the problem persists with qemu-xen binary, while my self compiled
>> qemu 2.0 works well.
>> I think it is a problem and can be repeated.
>>      Then, I will summarize my compilation process here:
>>      Firstly install debian wheezy 7.5 amd64 and necessary build
>> dependency. Then:
>>
>>     1. git clone git://xenbits.xen.org/xen.git
>>     <http://xenbits.xen.org/gitweb/?p=xen.git>
>>     2.  install backport version libspice-server-dev
>>     libspice-protocol-dev
>>
>>         root@debian:~#  apt-cache policy libspice-server-dev
>>         libspice-protocol-dev
>>         libspice-server-dev:
>>           Installed: 0.12.4-0nocelt2~bpo70+1
>>           Candidate: 0.12.4-0nocelt2~bpo70+1
>>           Version table:
>>         *** 0.12.4-0nocelt2~bpo70+1 0
>>                 100 http://cdn.debian.net/debian/
>>         wheezy-backports/main amd64 Packages
>>                 100 /var/lib/dpkg/status
>>         libspice-protocol-dev:
>>           Installed: 0.12.6-1~bpo70+2
>>           Candidate: 0.12.6-1~bpo70+2
>>           Version table:
>>         *** 0.12.6-1~bpo70+2 0
>>                 100 http://cdn.debian.net/debian/
>>         wheezy-backports/main amd64 Packages
>>                 100 /var/lib/dpkg/status
>>
>>      3. patch for QXL option
>>      4. ./configure --prefix=/usr
>>      5. add spice and usb-redir option for qemu-xen-upstream
>>      6. make xen;make tools;make install-xen;make install-tools
>>
>>        To compile qemu 2.0 from qemu.org:
>>        1. wget http://wiki.qemu-project.org/download/qemu-2.0.0.tar.bz2
>>        2. ./configure --enable-xen --target-list=i386-softmmu
>> --extra-cflags="-I/usr/src/xen/tools/include
>> -I/usr/src/xen/tools/libxc -I/usr/src/xen/tools/xenstore" \
>>             --enable-spice --enable-usb-redir
>>        3 .make;make install
>
> For fast unstable tests I do this (using my github rebase/m2r-*):
> Install of opus, usbredir and libusbx from backports.
> Rebuild and install new seabios 1.7.5-1 and spice packages (server
> 0.12.5-1 and protocol 0.12.7-1) from sid that contains many fixes
> (simply and fast with git clone of debian repository and debuild).
> ./configure --prefix=/usr --enable-qemu-traditional=no
> --with-system-seabios=/usr/share/seabios/bios-256k.bin
> --with-extra-qemuu-configure-args="--enable-spice --enable-usb-redir"
> make debball
> dpkg -i of xen package in dist (contain both xen and qemu)
> And if I need to test newer qemu in development I simply change the
> qemu git with mainline in Config.mk.
>
> And for newer production servers I start prepared new xen's debian
> packages awaiting debian maintainers replies:
> https://github.com/Fantu/pkg-xen/tree/wheezy-backports
> Needs also qemu rebuild to use new xen 4.4 libraries (simply and fast
> with git clone of debian repository and debuild).
>
> There is also a problem of jpeg-turbo in debian and for have better
> performances and not too many cpu waste I for now solved with:
> apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E
> vi /etc/apt/sources.list.d/x2go.list
> # X2Go Repository (for jpeg-turbo as default and with full -dev package)
> deb http://packages.x2go.org/debian wheezy heuler
> deb-src http://packages.x2go.org/debian wheezy heuler
> aptitude update
> aptitude install x2go-keyring && aptitude update
> aptitude install libjpeg8-turbo-dev
>
>> ------------------------------------------------------------------------
>> Best Regards
>>
>> *发件人：* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>
>> *发送时间：* 2014-07-14 16:49
>> *收件人：* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>; xen-devel
>> <mailto:xen-devel@lists.xen.org>
>> *主题：* 回复: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>> unstable
>> Hi Fabio Fantoni,
>>       Thank you for your reply.
>>       It is really weird.
>>       I compiled both qemu binary ( qemu-upstream in xen and qemu-2.0
>> from qemu.org website) in the same environment,  the binary in
>> xen has the problem while
>> the other one works well.
>>       I will check whether wheezy backport has libspice-server-dev
>> and libspice-protocol-dev and try again.
>> ------------------------------------------------------------------------
>> Best Regards
>>
>> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
>> *Date:* 2014-07-14 15:59
>> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>;
>> xen-devel <mailto:xen-devel@lists.xen.org>
>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>> unstable
>> Il 14/07/2014 07:29, kevin.zhang@octlink.com ha scritto:
>>> Hi Fabio Fantoni,
>>>      Today, I've done another test on xenbits xen 4.5 unstable.
>>>      This time, I directly compiled xen on my test server, and use
>>> default libspice-server-dev  and libspice-protocol-dev header files
>>> for spice option.
>>>
>>>         root@debian:~# apt-cache policy libspice-server-dev
>>>         libspice-protocol-dev
>>>         libspice-server-dev:
>>>           Installed: 0.11.0-1+deb7u1
>>>           Candidate: 0.11.0-1+deb7u1
>>>           Version table:
>>>         *** 0.11.0-1+deb7u1 0
>>>                 500 http://cdn.debian.net/debian/ wheezy/main amd64
>>>         Packages
>>>                 100 /var/lib/dpkg/status
>>>         libspice-protocol-dev:
>>>           Installed: 0.10.1-1
>>>           Candidate: 0.10.1-1
>>>           Version table:
>>>         *** 0.10.1-1 0
>>>                 500 http://cdn.debian.net/debian/ wheezy/main amd64
>>>         Packages
>>>                 100 /var/lib/dpkg/status
>>>
>>>      I also download qemu-2.0 source code from qemu.org, and
>>> compiled it by the way mentioned in
>>> http://wiki.xen.org/wiki/QEMU_Upstream.
>>>      Then I create win7 hvm with qemu-xen and
>>> /usr/local/bin/qemu-system-i386 respectively.
>>>      The result shows that:
>>>       1 . qemu-upstream used in xen 4.5 unstable still exited when
>>> changing screen resolution,
>>>       2.  my self-compiled qemu2.0 behave normally.
>>>      I think maybe there's still some differences between the two
>>> qemu repository.
>>
>> Use spice from backports or recompile the latest from Sid, wheezy
>> packages are too old for newer qemu.
>> xen already download and compile qemu upstream automatically if you
>> not specify binary in repository.
>> I also use use wheezy dom0 with same xen and qemu and same domU and
>> spice guest tools installed automatically resize the windows
>> resolution without problem (except rare cases when I connect
>> remote-viewer before windows start).
>> Below also reply to other mail.
>>
>>>      I'm actively waiting for your advice and willing to do the
>>> following debug.
>>>      vm config file is as follow:
>>>
>>>     name='Win7'
>>>     builder="hvm"
>>>     memory=2048
>>>     vcpus=2
>>>     vif=['bridge=br0']
>>>     disk=['/srv/vm_templates/1.qcow2,qcow2,hda,rw',',raw,hdb,ro,cdrom']
>>>     boot='dc'
>>>     device_model_version="qemu-xen"
>>>     #device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>     #device_model_override="/usr/local/bin/qemu-system-i386"
>>>     viridian=1
>>>     vnc=1
>>>     vnclisten="0.0.0.0"
>>>     on_crash="destroy"
>>>     vga="qxl"
>>>     spice=1
>>>     spicehost='0.0.0.0'
>>>     spiceport=6000
>>>     spicedisable_ticketing=1
>>>     spicevdagent=1
>>>     spice_clipboard_sharing=1
>>>     spiceusbredirection=4
>>>     soundhw="hda"
>>>     localtime=1
>>>     videoram=128
>>>
>>
>> videoram=128 is not needed with qxl as already the default.
>> Try to disable vnc when you use spice, even if I used with also vnc
>> many times without problem time ago.
>>
>>> ------------------------------------------------------------------------
>>> Best Regards
>>>
>>> *From:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>
>>> *Date:* 2014-07-14 10:26
>>> *To:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>; xen-devel
>>> <mailto:xen-devel@lists.xen.org>
>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>>> unstable
>>> Hi Fabio Fantoni,
>>>     Thank you for your help.
>>>      If I use your method to run qemu-gdb when using xl create, xl
>>> will complain startup timeout.
>>
>> I know, I already posted the solution but I try to explain better.
>>
>> # after xl create with (qemu gdb), do it fast after xl create when
>> arrive on qemu process launch (before timeout or xl create will fails)
>> target remote localhost:1234 # prepare this command in other ssh to
>> the xen dom0 and enter on xl create when arrive on qemu launch
>> c # press immediatly
>> bt full # when qemu stops
>>
>> Sorry for my bad english.
>>
>>>     Perhaps I did not describe my problem clearly enough, I can
>>> successfully create windows HVM, my problem happened when I change
>>> windows screen resolution.
>>> The qemu process suddenly  exited while xl list can still list the
>>> domU information.
>>>     I am using debian wheezy 7.5 amd 64, I am using fantu's xen 4.5
>>> unstable and the qemu-xen-remote in his code repository,
>>>
>>>     root@debian:~# /usr/lib/xen/bin/qemu-system-i386 -version
>>>     QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice
>>>     Bellard
>>>
>>>  And I compiled Xen from fantu's xen repository in compilation
>>> server, then use install.sh in dist dir to install xen packages in
>>> my test server.
>>>  My compilation server has spice 0.12.4 compiled and installed.
>>>  My test server has debian wheezy backport qemu installed with
>>> spice-server:
>>>
>>>     dpkg -l |grep spice
>>>     ii libspice-server1:amd64 0.12.4-0nocelt2~bpo70+1
>>>
>>>  Then how can I obtain useful debug information after qemu exit with
>>> vm running?
>>> ------------------------------------------------------------------------
>>> Best Regards
>>>
>>> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
>>> *Date:* 2014-07-11 18:06
>>> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>;
>>> xen-devel <mailto:xen-devel@lists.xen.org>
>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>>> unstable
>>> Il 11/07/2014 04:38, kevin.zhang@octlink.com ha scritto:
>>>> Hi all,
>>>> Firstly please forgive me if I put this problem in the wrong mail
>>>> list.
>>>> However, it seems that xen-users mail list cannot resolve this QXL
>>>> problems. Therefore, I have to post QXL problem in devel mail list.
>>>> My problem is as follow:
>>>> I'm testing QXL for windows HVM, spice works well with stdvga.
>>>> However, when I switch to QXL, qemu exit abnormally:
>>>> I specify vga="qxl" and videoram=128, using qemu-xen. The windows 7
>>>> boots and automatially switch resolution for me in virt-viewer.
>>>> While display and sound transfering very well, if I change display
>>>> resolution, the virt-viewer will be suddenly closed and
>>>> I check the physical server, the qemu process disappear
>>>> simultaneously.
>>>> Then I switch to wheezy backport qemu 2.0 as device model, the qemu
>>>> process will exit as soon as the welcome page appears and at the
>>>> beginning of resolution change.
>>>> I tested and found the same bug on both xenbits xen 4.4.1 rc1 and
>>>> Fantu's Xen 4.5 unstable, this problem exists in both branches.
>>>> Is it a known issue or is there any solution for this bug?
>>>> Thank you very much!
>>>
>>> Thanks for testing spice and qxl and report issue.
>>> I have spice + qxl working as kvm on xen unstable except this problem:
>>> http://lists.xen.org/archives/html/xen-devel/2014-07/msg01021.html
>>>
>>> Please post details on your dom0 installation and domU (for example
>>> xl cfg,
>>> spice guest tools version ecc...)
>>> About qemu crash try to take a full backtrace with gdb and post it here.
>>>
>>> Small help with gdb of qemu launched by xl:
>>>
>>> Add the line below in domU's xl cfg:
>>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>
>>> vi /usr/lib/xen/bin/qemu-gdb # create the file, change the qemu path if
>>> needed
>>> #!/bin/sh
>>> exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386 "$@"
>>>
>>> # after xl create, do it fast (before timeout or xl create will fails)
>>> target remote localhost:1234
>>> c
>>> bt full # when qemu stops
>>>
>>> You should install also all needed dbg packages before, spice qemu
>>> ecc or
>>> without package should be compiled with debug enabled (for xen and qemu
>>> default in unstable).
>>>
>>> The latest qemu crash with spice I saw was in 2.0-rc solved before 2.0.0
>>> final, your qemu is at least 2.0.0 final?
>>> http://git.qemu.org/?p=qemu.git;a=commit;h=dc491cfc14074064ed54a872b62cce6ca1330644
>>>
>>>> Kevin
>>>> Best Regards,
>>>>
>>>>
>>
>


[-- Attachment #1.2: Type: text/html, Size: 94093 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable

[kevin.zhang]

[-- Attachment #1.1: Type: text/plain, Size: 17839 bytes --]

Hi Fabio Fantoni,

     I finally got it. If that's not enough, I will provide more as u guide.
     I adjust the time to just after xl create and can get stack info as follow :
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007ffff7dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) c
Continuing.

Program received signal SIGABRT, Aborted.
0x00007ffff2e04475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt full
#0  0x00007ffff2e04475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007ffff2e076f0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x00007ffff2e3f52b in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3  0x00007ffff2e48d76 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#4  0x00007ffff2e4db1c in free () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#5  0x00007ffff3b5b44b in ?? () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
No symbol table info available.
#6  0x00007ffff3b5b399 in pixman_image_unref () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
No symbol table info available.
#7  0x000055555585283b in qemu_pixman_image_unref (image=0x555558cd1170) at ui/qemu-pixman.c:80
No locals.
#8  0x000055555587446b in vnc_dpy_switch (dcl=0x7fffe2cbc048, surface=0x5555563263c0) at ui/vnc.c:588
        vd = 0x7fffe2cbc010
        vs = 0xff000000180420
#9  0x000055555584be81 in dpy_gfx_replace_surface (con=0x5555566a2550, surface=0x5555563263c0) at ui/console.c:1404
        s = 0x555556715b90
        old_surface = 0x5555566e01e0
        dcl = 0x7fffe2cbc048
#10 0x00005555556ecd52 in qxl_render_update_area_unlocked (qxl=0x555556715bc0) at hw/display/qxl-render.c:131
        vga = 0x5555567166b0
        surface = 0x5555563263c0
        i = 0
#11 0x00005555556ed021 in qxl_render_update_area_bh (opaque=0x555556715bc0) at hw/display/qxl-render.c:183
        qxl = 0x555556715bc0
#12 0x00005555555f5330 in aio_bh_poll (ctx=0x5555562f1c30) at async.c:81
        bh = 0x5555565fb700
        bhp = 0x7ffff77bfe86
        next = 0x5555566afd00
        ret = 1
#13 0x00005555555f4f89 in aio_poll (ctx=0x5555562f1c30, blocking=false) at aio-posix.c:188
        node = 0x7ffff73269a4
        ret = 32767
---Type <return> to continue, or q <return> to quit---
        progress = false
#14 0x00005555555f5747 in aio_ctx_dispatch (source=0x5555562f1c30, callback=0, user_data=0x0) at async.c:205
        ctx = 0x5555562f1c30
        __PRETTY_FUNCTION__ = "aio_ctx_dispatch"
#15 0x00007ffff730c355 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#16 0x00005555557d41ce in glib_pollfds_poll () at main-loop.c:190
        context = 0x5555562f27c0
        pfds = 0x5555566f75c0
#17 0x00005555557d42ce in os_host_main_loop_wait (timeout=0) at main-loop.c:235
        ret = 1
        spin_counter = 1
#18 0x00005555557d43a1 in main_loop_wait (nonblocking=0) at main-loop.c:484
        ret = 21845
        timeout = 4294967295
        timeout_ns = 17515866
#19 0x000055555587fe0c in main_loop () at vl.c:2051
        nonblocking = false
        last_io = 0
#20 0x00005555558877e6 in main (argc=64, argv=0x7fffffffdfb8, envp=0x7fffffffe1c0) at vl.c:4507
        i = 64
        snapshot = 0
        linux_boot = 0
        icount_option = 0x0
        initrd_filename = 0x0
        kernel_filename = 0x0
        kernel_cmdline = 0x555555a22304 ""
        boot_order = 0x5555562ef840 "dc"
        ds = 0x555556715b90
        cyls = 0
        heads = 0
        secs = 0
        translation = 0
        hda_opts = 0x0
        opts = 0x5555562ef790
        machine_opts = 0x5555562f13f0
        olist = 0x555555e08220
---Type <return> to continue, or q <return> to quit---
        optind = 64
        optarg = 0x7fffffffe915 "if=ide,index=1,media=cdrom,cache=writeback,id=ide-832"
        loadvm = 0x0
        machine_class = 0x5555562e8540
        machine = 0x555555e0de80
        cpu_model = 0x0
        vga_model = 0x0
        qtest_chrdev = 0x0
        qtest_log = 0x0
        pid_file = 0x0
        incoming = 0x0
        show_vnc_port = 0
        defconfig = true
        userconfig = true
        log_mask = 0x0
        log_file = 0x0
        mem_trace = {malloc = 0x55555588369e <malloc_and_trace>, realloc = 0x5555558836f6 <realloc_and_trace>, 
          free = 0x55555588375d <free_and_trace>, calloc = 0, try_malloc = 0, try_realloc = 0}
        trace_events = 0x0
        trace_file = 0x0
        __func__ = "main"
        args = {machine = 0x555555e0de80, ram_size = 4160749568, boot_order = 0x5555562ef840 "dc", 
          kernel_filename = 0x0, kernel_cmdline = 0x555555a22304 "", initrd_filename = 0x0, cpu_model = 0x0}





Best Regards
发件人： Fabio Fantoni
发送时间： 2014-07-16 17:03
收件人： kevin.zhang@octlink.com; xen-devel
主题： Re:回复: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 16/07/2014 09:04, kevin.zhang@octlink.com ha scritto:

Hi Fabio Fantoni,

     Thank you for your advice for building xen unstable.
     Because I have to use debian wheezy as production distro, I've got to do the test in it.
     Today, I edit Config.mk and write:
QEMU_UPSTREAM_URL = git://git.qemu.org/qemu.git
QEMU_UPSTREAM_REVISION = master
     Then, the built qemu-xen binary works well.  Therefore, I guess that git://xenbits.xen.org/qemu-upstream-unstable.git  has some very little difference
compared to qemu.git. Maybe your environment cannot repeat  that problem either, I'd like to provide any useful information to resolve this problem.

I also use wheezy for both production and develop/testing.
I tried now on my latest testing build, of some days ago xen from rebase/m2r-staging branch and qemu mainline with same Config.mk before build.
On windows 7 pro 64 bit domUs with latest spice guest tools auto and manual resolution change works without problem.
I'm still unable to reproduce your qemu crash.

You can retry to catch and post backtrace with my latest better explain?


I know, I already posted the solution but I try to explain better.

# after xl create with (qemu gdb), do it fast after xl create when arrive on qemu process launch (before timeout or xl create will fails)
target remote localhost:1234 # prepare this command in other ssh to the xen dom0 and enter on xl create when arrive on qemu launch
c # press immediatly
bt full # when qemu stops

Sorry for my bad english.







Best Regards
From: Fabio Fantoni
Date: 2014-07-15 16:09
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 15/07/2014 07:53, kevin.zhang@octlink.com ha scritto:

Hi Fabio Fantoni,
      Today I tried to use wheezy backports version of spice-server, the problem persists with qemu-xen binary, while my self compiled qemu 2.0 works well.
I think it is a problem and can be repeated.
     Then, I will summarize my compilation process here:
     Firstly install debian wheezy 7.5 amd64 and necessary build dependency. Then:
1. git clone  git://xenbits.xen.org/xen.git
2.  install backport version  libspice-server-dev libspice-protocol-dev
root@debian:~#  apt-cache policy libspice-server-dev libspice-protocol-dev
libspice-server-dev:
  Installed: 0.12.4-0nocelt2~bpo70+1
  Candidate: 0.12.4-0nocelt2~bpo70+1
  Version table:
*** 0.12.4-0nocelt2~bpo70+1 0
        100 http://cdn.debian.net/debian/ wheezy-backports/main amd64 Packages
        100 /var/lib/dpkg/status
libspice-protocol-dev:
  Installed: 0.12.6-1~bpo70+2
  Candidate: 0.12.6-1~bpo70+2
  Version table:
*** 0.12.6-1~bpo70+2 0
        100 http://cdn.debian.net/debian/ wheezy-backports/main amd64 Packages
        100 /var/lib/dpkg/status
 3. patch for QXL option
 4. ./configure --prefix=/usr 
 5. add spice and usb-redir option for qemu-xen-upstream
 6. make xen;make tools;make install-xen;make install-tools

       To compile qemu 2.0 from qemu.org:
       1. wget http://wiki.qemu-project.org/download/qemu-2.0.0.tar.bz2
       2. ./configure --enable-xen --target-list=i386-softmmu --extra-cflags="-I/usr/src/xen/tools/include -I/usr/src/xen/tools/libxc -I/usr/src/xen/tools/xenstore" \
            --enable-spice --enable-usb-redir 
       3 .make;make install



For fast unstable tests I do this (using my github rebase/m2r-*):
Install of opus, usbredir and libusbx from backports.
Rebuild and install new seabios 1.7.5-1 and spice packages (server 0.12.5-1 and protocol 0.12.7-1) from sid that contains many fixes (simply and fast with git clone of debian repository and debuild).
./configure --prefix=/usr --enable-qemu-traditional=no --with-system-seabios=/usr/share/seabios/bios-256k.bin --with-extra-qemuu-configure-args="--enable-spice --enable-usb-redir"
make debball
dpkg -i of xen package in dist (contain both xen and qemu)
And if I need to test newer qemu in development I simply change the qemu git with mainline in Config.mk.

And for newer production servers I start prepared new xen's debian packages awaiting debian maintainers replies:
https://github.com/Fantu/pkg-xen/tree/wheezy-backports
Needs also qemu rebuild to use new xen 4.4 libraries (simply and fast with git clone of debian repository and debuild).

There is also a problem of jpeg-turbo in debian and for have better performances and not too many cpu waste I for now solved with:
apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E
vi /etc/apt/sources.list.d/x2go.list
# X2Go Repository (for jpeg-turbo as default and with full -dev package)
deb http://packages.x2go.org/debian wheezy heuler
deb-src http://packages.x2go.org/debian wheezy heuler
aptitude update
aptitude install x2go-keyring && aptitude update
aptitude install libjpeg8-turbo-dev






Best Regards
发件人： kevin.zhang@octlink.com
发送时间： 2014-07-14 16:49
收件人： Fabio Fantoni; xen-devel
主题： 回复: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Hi Fabio Fantoni,
     
      Thank you for your reply.
      It is really weird. 
      I compiled both qemu binary ( qemu-upstream in xen and qemu-2.0 from qemu.org website) in the same environment,  the binary in xen has the problem while 
the other one works well.
      I will check whether wheezy backport has libspice-server-dev and libspice-protocol-dev and try again. 




Best Regards
From: Fabio Fantoni
Date: 2014-07-14 15:59
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 14/07/2014 07:29, kevin.zhang@octlink.com ha scritto:

Hi Fabio Fantoni,
    
     Today, I've done another test on xenbits xen 4.5 unstable.
     This time, I directly compiled xen on my test server, and use default libspice-server-dev  and libspice-protocol-dev header files for spice option.
    
root@debian:~# apt-cache policy libspice-server-dev libspice-protocol-dev
libspice-server-dev:
  Installed: 0.11.0-1+deb7u1
  Candidate: 0.11.0-1+deb7u1
  Version table:
*** 0.11.0-1+deb7u1 0
        500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status
libspice-protocol-dev:
  Installed: 0.10.1-1
  Candidate: 0.10.1-1
  Version table:
*** 0.10.1-1 0
        500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status

     I also download qemu-2.0 source code from qemu.org, and compiled it by the way mentioned in http://wiki.xen.org/wiki/QEMU_Upstream.
     Then I create win7 hvm with qemu-xen and /usr/local/bin/qemu-system-i386 respectively.
     The result shows that:
      1 . qemu-upstream used in xen 4.5 unstable still exited when changing screen resolution,
      2.  my self-compiled qemu2.0 behave normally.
     I think maybe there's still some differences between the two qemu repository.

Use spice from backports or recompile the latest from Sid, wheezy packages are too old for newer qemu.
xen already download and compile qemu upstream automatically if you not specify binary in repository.
I also use use wheezy dom0 with same xen and qemu and same domU and spice guest tools installed automatically resize the windows resolution without problem (except rare cases when I connect remote-viewer before windows start).
Below also reply to other mail.



     I'm actively waiting for your advice and willing to do the following debug.
     vm config file is as follow:
name='Win7'
builder="hvm"
memory=2048
vcpus=2
vif=['bridge=br0']
disk=['/srv/vm_templates/1.qcow2,qcow2,hda,rw',',raw,hdb,ro,cdrom']
boot='dc'
device_model_version="qemu-xen"
#device_model_override="/usr/lib/xen/bin/qemu-gdb"
#device_model_override="/usr/local/bin/qemu-system-i386"
viridian=1
vnc=1
vnclisten="0.0.0.0"
on_crash="destroy"
vga="qxl"
spice=1
spicehost='0.0.0.0'
spiceport=6000
spicedisable_ticketing=1
spicevdagent=1
spice_clipboard_sharing=1
spiceusbredirection=4
soundhw="hda"
localtime=1
videoram=128

videoram=128 is not needed with qxl as already the default.
Try to disable vnc when you use spice, even if I used with also vnc many times without problem time ago.



   




Best Regards
From: kevin.zhang@octlink.com
Date: 2014-07-14 10:26
To: Fabio Fantoni; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Hi Fabio Fantoni,
    Thank you for your help.
     If I use your method to run qemu-gdb when using xl create, xl will complain startup timeout. 

I know, I already posted the solution but I try to explain better.

# after xl create with (qemu gdb), do it fast after xl create when arrive on qemu process launch (before timeout or xl create will fails)
target remote localhost:1234 # prepare this command in other ssh to the xen dom0 and enter on xl create when arrive on qemu launch
c # press immediatly
bt full # when qemu stops

Sorry for my bad english.


    Perhaps I did not describe my problem clearly enough, I can successfully create windows HVM, my problem happened when I change windows screen resolution.
The qemu process suddenly  exited while xl list can still list the domU information.

    I am using debian wheezy 7.5 amd 64, I am using fantu's xen 4.5 unstable and the qemu-xen-remote in his code repository,
root@debian:~# /usr/lib/xen/bin/qemu-system-i386 -version
QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice Bellard  
 And I compiled Xen from fantu's xen repository in compilation server, then use install.sh in dist dir to install xen packages in my test server.
 My compilation server has spice 0.12.4 compiled and installed.
 My test server has debian wheezy backport qemu installed with spice-server:
dpkg -l |grep spice
ii  libspice-server1:amd64             0.12.4-0nocelt2~bpo70+1   
 Then how can I obtain useful debug information after qemu exit with vm running?




Best Regards
From: Fabio Fantoni
Date: 2014-07-11 18:06
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 11/07/2014 04:38, kevin.zhang@octlink.com ha scritto:

Hi all,

Firstly please forgive me if I put this problem in the wrong mail list. 
However, it seems that xen-users mail list cannot resolve this QXL problems. Therefore, I have to post QXL problem in devel mail list.
My problem is as follow:

I'm testing QXL for windows HVM, spice works well with stdvga. 
However, when I switch to QXL, qemu exit abnormally:
I specify vga="qxl" and videoram=128, using qemu-xen. The windows 7 boots and automatially switch resolution for me in virt-viewer.
While display and sound transfering very well, if I change display resolution, the virt-viewer will be suddenly closed and
I check the physical server, the qemu process disappear simultaneously. 
Then I switch to wheezy backport qemu 2.0 as device model, the qemu process will exit as soon as the welcome page appears and at the beginning of resolution change.
I tested and found the same bug on both xenbits xen 4.4.1 rc1 and Fantu's Xen 4.5 unstable, this problem exists in both branches.
Is it a known issue or is there any solution for this bug?
Thank you very much! 

Thanks for testing spice and qxl and report issue.
I have spice + qxl working as kvm on xen unstable except this problem:
http://lists.xen.org/archives/html/xen-devel/2014-07/msg01021.html

Please post details on your dom0 installation and domU (for example xl cfg,
spice guest tools version ecc...)
About qemu crash try to take a full backtrace with gdb and post it here.

Small help with gdb of qemu launched by xl:

Add the line below in domU's xl cfg:
device_model_override="/usr/lib/xen/bin/qemu-gdb"

vi /usr/lib/xen/bin/qemu-gdb # create the file, change the qemu path if
needed
#!/bin/sh
exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386 "$@"

# after xl create, do it fast (before timeout or xl create will fails)
target remote localhost:1234
c 
bt full # when qemu stops

You should install also all needed dbg packages before, spice qemu ecc or
without package should be compiled with debug enabled (for xen and qemu
default in unstable).

The latest qemu crash with spice I saw was in 2.0-rc solved before 2.0.0
final, your qemu is at least 2.0.0 final?
http://git.qemu.org/?p=qemu.git;a=commit;h=dc491cfc14074064ed54a872b62cce6ca1330644




Kevin
Best Regards,

[-- Attachment #1.2: Type: text/html, Size: 64120 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 21447 bytes --]

Il 17/07/2014 03:48, kevin.zhang@octlink.com ha scritto:
> Hi Fabio Fantoni,
>      I finally got it. If that's not enough, I will provide more as u 
> guide.
>      I adjust the time to just after xl create and can get stack info 
> as follow :
>
>     (gdb) target remote localhost:1234
>     Remote debugging using localhost:1234
>     Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging
>     symbols found)...done.
>     Loaded symbols for /lib64/ld-linux-x86-64.so.2
>     0x00007ffff7dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
>     (gdb) c
>     Continuing.
>     Program received signal SIGABRT, Aborted.
>     0x00007ffff2e04475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>     (gdb) bt full
>     #0  0x00007ffff2e04475 in raise () from
>     /lib/x86_64-linux-gnu/libc.so.6
>     No symbol table info available.
>     #1  0x00007ffff2e076f0 in abort () from
>     /lib/x86_64-linux-gnu/libc.so.6
>     No symbol table info available.
>     #2  0x00007ffff2e3f52b in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>     No symbol table info available.
>     #3  0x00007ffff2e48d76 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>     No symbol table info available.
>     #4  0x00007ffff2e4db1c in free () from /lib/x86_64-linux-gnu/libc.so.6
>     No symbol table info available.
>     #5  0x00007ffff3b5b44b in ?? () from
>     /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
>     No symbol table info available.
>     #6  0x00007ffff3b5b399 in pixman_image_unref () from
>     /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
>     No symbol table info available.
>     #7  0x000055555585283b in qemu_pixman_image_unref
>     (image=0x555558cd1170) at ui/qemu-pixman.c:80
>     No locals.
>     #8  0x000055555587446b in vnc_dpy_switch (dcl=0x7fffe2cbc048,
>     surface=0x5555563263c0) at ui/vnc.c:588
>             vd = 0x7fffe2cbc010
>             vs = 0xff000000180420
>     #9  0x000055555584be81 in dpy_gfx_replace_surface
>     (con=0x5555566a2550, surface=0x5555563263c0) at ui/console.c:1404
>             s = 0x555556715b90
>             old_surface = 0x5555566e01e0
>             dcl = 0x7fffe2cbc048
>     #10 0x00005555556ecd52 in qxl_render_update_area_unlocked
>     (qxl=0x555556715bc0) at hw/display/qxl-render.c:131
>             vga = 0x5555567166b0
>             surface = 0x5555563263c0
>             i = 0
>     #11 0x00005555556ed021 in qxl_render_update_area_bh
>     (opaque=0x555556715bc0) at hw/display/qxl-render.c:183
>             qxl = 0x555556715bc0
>     #12 0x00005555555f5330 in aio_bh_poll (ctx=0x5555562f1c30) at
>     async.c:81
>             bh = 0x5555565fb700
>             bhp = 0x7ffff77bfe86
>             next = 0x5555566afd00
>             ret = 1
>     #13 0x00005555555f4f89 in aio_poll (ctx=0x5555562f1c30,
>     blocking=false) at aio-posix.c:188
>             node = 0x7ffff73269a4
>             ret = 32767
>     ---Type <return> to continue, or q <return> to quit---
>             progress = false
>     #14 0x00005555555f5747 in aio_ctx_dispatch (source=0x5555562f1c30,
>     callback=0, user_data=0x0) at async.c:205
>             ctx = 0x5555562f1c30
>             __PRETTY_FUNCTION__ = "aio_ctx_dispatch"
>     #15 0x00007ffff730c355 in g_main_context_dispatch () from
>     /lib/x86_64-linux-gnu/libglib-2.0.so.0
>     No symbol table info available.
>     #16 0x00005555557d41ce in glib_pollfds_poll () at main-loop.c:190
>             context = 0x5555562f27c0
>             pfds = 0x5555566f75c0
>     #17 0x00005555557d42ce in os_host_main_loop_wait (timeout=0) at
>     main-loop.c:235
>             ret = 1
>             spin_counter = 1
>     #18 0x00005555557d43a1 in main_loop_wait (nonblocking=0) at
>     main-loop.c:484
>             ret = 21845
>             timeout = 4294967295
>             timeout_ns = 17515866
>     #19 0x000055555587fe0c in main_loop () at vl.c:2051
>             nonblocking = false
>             last_io = 0
>     #20 0x00005555558877e6 in main (argc=64, argv=0x7fffffffdfb8,
>     envp=0x7fffffffe1c0) at vl.c:4507
>             i = 64
>             snapshot = 0
>             linux_boot = 0
>             icount_option = 0x0
>             initrd_filename = 0x0
>             kernel_filename = 0x0
>             kernel_cmdline = 0x555555a22304 ""
>             boot_order = 0x5555562ef840 "dc"
>             ds = 0x555556715b90
>             cyls = 0
>             heads = 0
>             secs = 0
>             translation = 0
>             hda_opts = 0x0
>             opts = 0x5555562ef790
>             machine_opts = 0x5555562f13f0
>             olist = 0x555555e08220
>     ---Type <return> to continue, or q <return> to quit---
>             optind = 64
>             optarg = 0x7fffffffe915
>     "if=ide,index=1,media=cdrom,cache=writeback,id=ide-832"
>             loadvm = 0x0
>             machine_class = 0x5555562e8540
>             machine = 0x555555e0de80
>             cpu_model = 0x0
>             vga_model = 0x0
>             qtest_chrdev = 0x0
>             qtest_log = 0x0
>             pid_file = 0x0
>             incoming = 0x0
>             show_vnc_port = 0
>             defconfig = true
>             userconfig = true
>             log_mask = 0x0
>             log_file = 0x0
>             mem_trace = {malloc = 0x55555588369e <malloc_and_trace>,
>     realloc = 0x5555558836f6 <realloc_and_trace>,
>               free = 0x55555588375d <free_and_trace>, calloc = 0,
>     try_malloc = 0, try_realloc = 0}
>             trace_events = 0x0
>             trace_file = 0x0
>             __func__ = "main"
>             args = {machine = 0x555555e0de80, ram_size = 4160749568,
>     boot_order = 0x5555562ef840 "dc",
>               kernel_filename = 0x0, kernel_cmdline = 0x555555a22304
>     "", initrd_filename = 0x0, cpu_model = 0x0}
>

In your test vnc is still enabled, right? Can you try disabling vnc 
(vnc=0 in domU's xl cfg)?
Install also these packages for missed symbols: libc6-dbg libpixman-1-0-dbg

Thanks for any reply.

> ------------------------------------------------------------------------
> Best Regards
>
> *???:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
> *????:* 2014-07-16 17:03
> *???:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>; 
> xen-devel <mailto:xen-devel@lists.xen.org>
> *??:* Re:??: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 
> unstable
> Il 16/07/2014 09:04, kevin.zhang@octlink.com ha scritto:
>> Hi Fabio Fantoni,
>>      Thank you for your advice for building xen unstable.
>>      Because I have to use debian wheezy as production distro, I've 
>> got to do the test in it.
>>      Today, I edit Config.mk and write:
>> QEMU_UPSTREAM_URL = git://git.qemu.org/qemu.git
>> QEMU_UPSTREAM_REVISION = master
>>      Then, the built qemu-xen binary works well. Therefore, I guess 
>> that git://xenbits.xen.org/qemu-upstream-unstable.git  has some very 
>> little difference
>> compared to qemu.git. Maybe your environment cannot repeat  that 
>> problem either, I'd like to provide any useful information to resolve 
>> this problem.
>
> I also use wheezy for both production and develop/testing.
> I tried now on my latest testing build, of some days ago xen from 
> rebase/m2r-staging branch and qemu mainline with same Config.mk before 
> build.
> On windows 7 pro 64 bit domUs with latest spice guest tools auto and 
> manual resolution change works without problem.
> I'm still unable to reproduce your qemu crash.
>
> You can retry to catch and post backtrace with my latest better explain?
>
>> I know, I already posted the solution but I try to explain better.
>>
>> # after xl create with (qemu gdb), do it fast after xl create when 
>> arrive on qemu process launch (before timeout or xl create will fails)
>> target remote localhost:1234 # prepare this command in other ssh to 
>> the xen dom0 and enter on xl create when arrive on qemu launch
>> c # press immediatly
>> bt full # when qemu stops
>>
>> Sorry for my bad english.
>
>
>> ------------------------------------------------------------------------
>> Best Regards
>>
>> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
>> *Date:* 2014-07-15 16:09
>> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>; 
>> xen-devel <mailto:xen-devel@lists.xen.org>
>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 
>> unstable
>> Il 15/07/2014 07:53, kevin.zhang@octlink.com ha scritto:
>>> Hi Fabio Fantoni,
>>>       Today I tried to use wheezy backports version of spice-server, 
>>> the problem persists with qemu-xen binary, while my self compiled 
>>> qemu 2.0 works well.
>>> I think it is a problem and can be repeated.
>>>      Then, I will summarize my compilation process here:
>>>      Firstly install debian wheezy 7.5 amd64 and necessary build 
>>> dependency. Then:
>>>
>>>     1. git clone git://xenbits.xen.org/xen.git
>>>     <http://xenbits.xen.org/gitweb/?p=xen.git>
>>>     2.  install backport version  libspice-server-dev
>>>     libspice-protocol-dev
>>>
>>>         root@debian:~# apt-cache policy libspice-server-dev
>>>         libspice-protocol-dev
>>>         libspice-server-dev:
>>>           Installed: 0.12.4-0nocelt2~bpo70+1
>>>           Candidate: 0.12.4-0nocelt2~bpo70+1
>>>           Version table:
>>>         *** 0.12.4-0nocelt2~bpo70+1 0
>>>                 100 http://cdn.debian.net/debian/
>>>         wheezy-backports/main amd64 Packages
>>>                 100 /var/lib/dpkg/status
>>>         libspice-protocol-dev:
>>>           Installed: 0.12.6-1~bpo70+2
>>>           Candidate: 0.12.6-1~bpo70+2
>>>           Version table:
>>>         *** 0.12.6-1~bpo70+2 0
>>>                 100 http://cdn.debian.net/debian/
>>>         wheezy-backports/main amd64 Packages
>>>                 100 /var/lib/dpkg/status
>>>
>>>      3. patch for QXL option
>>>      4. ./configure --prefix=/usr
>>>      5. add spice and usb-redir option for qemu-xen-upstream
>>>      6. make xen;make tools;make install-xen;make install-tools
>>>
>>>        To compile qemu 2.0 from qemu.org:
>>>        1. wget http://wiki.qemu-project.org/download/qemu-2.0.0.tar.bz2
>>>        2. ./configure --enable-xen --target-list=i386-softmmu 
>>> --extra-cflags="-I/usr/src/xen/tools/include 
>>> -I/usr/src/xen/tools/libxc -I/usr/src/xen/tools/xenstore" \
>>>             --enable-spice --enable-usb-redir
>>>        3 .make;make install
>>
>> For fast unstable tests I do this (using my github rebase/m2r-*):
>> Install of opus, usbredir and libusbx from backports.
>> Rebuild and install new seabios 1.7.5-1 and spice packages (server 
>> 0.12.5-1 and protocol 0.12.7-1) from sid that contains many fixes 
>> (simply and fast with git clone of debian repository and debuild).
>> ./configure --prefix=/usr --enable-qemu-traditional=no 
>> --with-system-seabios=/usr/share/seabios/bios-256k.bin 
>> --with-extra-qemuu-configure-args="--enable-spice --enable-usb-redir"
>> make debball
>> dpkg -i of xen package in dist (contain both xen and qemu)
>> And if I need to test newer qemu in development I simply change the 
>> qemu git with mainline in Config.mk.
>>
>> And for newer production servers I start prepared new xen's debian 
>> packages awaiting debian maintainers replies:
>> https://github.com/Fantu/pkg-xen/tree/wheezy-backports
>> Needs also qemu rebuild to use new xen 4.4 libraries (simply and fast 
>> with git clone of debian repository and debuild).
>>
>> There is also a problem of jpeg-turbo in debian and for have better 
>> performances and not too many cpu waste I for now solved with:
>> apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E
>> vi /etc/apt/sources.list.d/x2go.list
>> # X2Go Repository (for jpeg-turbo as default and with full -dev package)
>> deb http://packages.x2go.org/debian wheezy heuler
>> deb-src http://packages.x2go.org/debian wheezy heuler
>> aptitude update
>> aptitude install x2go-keyring && aptitude update
>> aptitude install libjpeg8-turbo-dev
>>
>>> ------------------------------------------------------------------------
>>> Best Regards
>>>
>>> *???:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>
>>> *????:* 2014-07-14 16:49
>>> *???:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>; xen-devel 
>>> <mailto:xen-devel@lists.xen.org>
>>> *??:* ??: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 
>>> unstable
>>> Hi Fabio Fantoni,
>>>       Thank you for your reply.
>>>       It is really weird.
>>>       I compiled both qemu binary ( qemu-upstream in xen and 
>>> qemu-2.0 from qemu.org website) in the same environment,  the binary 
>>> in xen has the problem while
>>> the other one works well.
>>>       I will check whether wheezy backport has libspice-server-dev 
>>> and libspice-protocol-dev and try again.
>>> ------------------------------------------------------------------------
>>> Best Regards
>>>
>>> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
>>> *Date:* 2014-07-14 15:59
>>> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>; 
>>> xen-devel <mailto:xen-devel@lists.xen.org>
>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 
>>> unstable
>>> Il 14/07/2014 07:29, kevin.zhang@octlink.com ha scritto:
>>>> Hi Fabio Fantoni,
>>>>      Today, I've done another test on xenbits xen 4.5 unstable.
>>>>      This time, I directly compiled xen on my test server, and use 
>>>> default libspice-server-dev  and libspice-protocol-dev header files 
>>>> for spice option.
>>>>
>>>>         root@debian:~# apt-cache policy libspice-server-dev
>>>>         libspice-protocol-dev
>>>>         libspice-server-dev:
>>>>           Installed: 0.11.0-1+deb7u1
>>>>           Candidate: 0.11.0-1+deb7u1
>>>>           Version table:
>>>>         *** 0.11.0-1+deb7u1 0
>>>>                 500 http://cdn.debian.net/debian/ wheezy/main amd64
>>>>         Packages
>>>>                 100 /var/lib/dpkg/status
>>>>         libspice-protocol-dev:
>>>>           Installed: 0.10.1-1
>>>>           Candidate: 0.10.1-1
>>>>           Version table:
>>>>         *** 0.10.1-1 0
>>>>                 500 http://cdn.debian.net/debian/ wheezy/main amd64
>>>>         Packages
>>>>                 100 /var/lib/dpkg/status
>>>>
>>>>      I also download qemu-2.0 source code from qemu.org, and 
>>>> compiled it by the way mentioned in 
>>>> http://wiki.xen.org/wiki/QEMU_Upstream.
>>>>      Then I create win7 hvm with qemu-xen and 
>>>> /usr/local/bin/qemu-system-i386 respectively.
>>>>      The result shows that:
>>>>       1 . qemu-upstream used in xen 4.5 unstable still exited when 
>>>> changing screen resolution,
>>>>       2.  my self-compiled qemu2.0 behave normally.
>>>>      I think maybe there's still some differences between the two 
>>>> qemu repository.
>>>
>>> Use spice from backports or recompile the latest from Sid, wheezy 
>>> packages are too old for newer qemu.
>>> xen already download and compile qemu upstream automatically if you 
>>> not specify binary in repository.
>>> I also use use wheezy dom0 with same xen and qemu and same domU and 
>>> spice guest tools installed automatically resize the windows 
>>> resolution without problem (except rare cases when I connect 
>>> remote-viewer before windows start).
>>> Below also reply to other mail.
>>>
>>>>      I'm actively waiting for your advice and willing to do the 
>>>> following debug.
>>>>      vm config file is as follow:
>>>>
>>>>     name='Win7'
>>>>     builder="hvm"
>>>>     memory=2048
>>>>     vcpus=2
>>>>     vif=['bridge=br0']
>>>>     disk=['/srv/vm_templates/1.qcow2,qcow2,hda,rw',',raw,hdb,ro,cdrom']
>>>>     boot='dc'
>>>>     device_model_version="qemu-xen"
>>>>     #device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>>     #device_model_override="/usr/local/bin/qemu-system-i386"
>>>>     viridian=1
>>>>     vnc=1
>>>>     vnclisten="0.0.0.0"
>>>>     on_crash="destroy"
>>>>     vga="qxl"
>>>>     spice=1
>>>>     spicehost='0.0.0.0'
>>>>     spiceport=6000
>>>>     spicedisable_ticketing=1
>>>>     spicevdagent=1
>>>>     spice_clipboard_sharing=1
>>>>     spiceusbredirection=4
>>>>     soundhw="hda"
>>>>     localtime=1
>>>>     videoram=128
>>>>
>>>
>>> videoram=128 is not needed with qxl as already the default.
>>> Try to disable vnc when you use spice, even if I used with also vnc 
>>> many times without problem time ago.
>>>
>>>> ------------------------------------------------------------------------
>>>> Best Regards
>>>>
>>>> *From:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>
>>>> *Date:* 2014-07-14 10:26
>>>> *To:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>; xen-devel 
>>>> <mailto:xen-devel@lists.xen.org>
>>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 
>>>> unstable
>>>> Hi Fabio Fantoni,
>>>>     Thank you for your help.
>>>>      If I use your method to run qemu-gdb when using xl create, xl 
>>>> will complain startup timeout.
>>>
>>> I know, I already posted the solution but I try to explain better.
>>>
>>> # after xl create with (qemu gdb), do it fast after xl create when 
>>> arrive on qemu process launch (before timeout or xl create will fails)
>>> target remote localhost:1234 # prepare this command in other ssh to 
>>> the xen dom0 and enter on xl create when arrive on qemu launch
>>> c # press immediatly
>>> bt full # when qemu stops
>>>
>>> Sorry for my bad english.
>>>
>>>>     Perhaps I did not describe my problem clearly enough, I can 
>>>> successfully create windows HVM, my problem happened when I change 
>>>> windows screen resolution.
>>>> The qemu process suddenly  exited while xl list can still list the 
>>>> domU information.
>>>>     I am using debian wheezy 7.5 amd 64, I am using fantu's xen 4.5 
>>>> unstable and the qemu-xen-remote in his code repository,
>>>>
>>>>     root@debian:~# /usr/lib/xen/bin/qemu-system-i386 -version
>>>>     QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice
>>>>     Bellard
>>>>
>>>>  And I compiled Xen from fantu's xen repository in compilation 
>>>> server, then use install.sh in dist dir to install xen packages in 
>>>> my test server.
>>>>  My compilation server has spice 0.12.4 compiled and installed.
>>>>  My test server has debian wheezy backport qemu installed with 
>>>> spice-server:
>>>>
>>>>     dpkg -l |grep spice
>>>>     ii libspice-server1:amd64 0.12.4-0nocelt2~bpo70+1
>>>>
>>>>  Then how can I obtain useful debug information after qemu exit 
>>>> with vm running?
>>>> ------------------------------------------------------------------------
>>>> Best Regards
>>>>
>>>> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
>>>> *Date:* 2014-07-11 18:06
>>>> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>; 
>>>> xen-devel <mailto:xen-devel@lists.xen.org>
>>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 
>>>> unstable
>>>> Il 11/07/2014 04:38, kevin.zhang@octlink.com ha scritto:
>>>>> Hi all,
>>>>> Firstly please forgive me if I put this problem in the wrong mail 
>>>>> list.
>>>>> However, it seems that xen-users mail list cannot resolve this QXL 
>>>>> problems. Therefore, I have to post QXL problem in devel mail list.
>>>>> My problem is as follow:
>>>>> I'm testing QXL for windows HVM, spice works well with stdvga.
>>>>> However, when I switch to QXL, qemu exit abnormally:
>>>>> I specify vga="qxl" and videoram=128, using qemu-xen. The windows 
>>>>> 7 boots and automatially switch resolution for me in virt-viewer.
>>>>> While display and sound transfering very well, if I change display 
>>>>> resolution, the virt-viewer will be suddenly closed and
>>>>> I check the physical server, the qemu process disappear 
>>>>> simultaneously.
>>>>> Then I switch to wheezy backport qemu 2.0 as device model, the 
>>>>> qemu process will exit as soon as the welcome page appears and at 
>>>>> the beginning of resolution change.
>>>>> I tested and found the same bug on both xenbits xen 4.4.1 rc1 and 
>>>>> Fantu's Xen 4.5 unstable, this problem exists in both branches.
>>>>> Is it a known issue or is there any solution for this bug?
>>>>> Thank you very much!
>>>>
>>>> Thanks for testing spice and qxl and report issue.
>>>> I have spice + qxl working as kvm on xen unstable except this problem:
>>>> http://lists.xen.org/archives/html/xen-devel/2014-07/msg01021.html
>>>>
>>>> Please post details on your dom0 installation and domU (for example 
>>>> xl cfg,
>>>> spice guest tools version ecc...)
>>>> About qemu crash try to take a full backtrace with gdb and post it 
>>>> here.
>>>>
>>>> Small help with gdb of qemu launched by xl:
>>>>
>>>> Add the line below in domU's xl cfg:
>>>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>>
>>>> vi /usr/lib/xen/bin/qemu-gdb # create the file, change the qemu path if
>>>> needed
>>>> #!/bin/sh
>>>> exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386 "$@"
>>>>
>>>> # after xl create, do it fast (before timeout or xl create will fails)
>>>> target remote localhost:1234
>>>> c
>>>> bt full # when qemu stops
>>>>
>>>> You should install also all needed dbg packages before, spice qemu 
>>>> ecc or
>>>> without package should be compiled with debug enabled (for xen and qemu
>>>> default in unstable).
>>>>
>>>> The latest qemu crash with spice I saw was in 2.0-rc solved before 
>>>> 2.0.0
>>>> final, your qemu is at least 2.0.0 final?
>>>> http://git.qemu.org/?p=qemu.git;a=commit;h=dc491cfc14074064ed54a872b62cce6ca1330644
>>>>
>>>>> Kevin
>>>>> Best Regards,
>>>>>
>>>>>
>>>
>>
>


[-- Attachment #1.2: Type: text/html, Size: 130766 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable

[kevin.zhang]

[-- Attachment #1.1: Type: text/plain, Size: 24512 bytes --]

Hi Fabio Fantoni,

     I closed vnc options and can reproduce the problem, stack info is as follow:
(gdb)  target remote localhost:1234
Remote debugging using localhost:1234
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007ffff7dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) c
Continuing.

Program received signal SIGABRT, Aborted.
0x00007ffff2e04475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt full
#0  0x00007ffff2e04475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
        pid = <optimized out>
        selftid = <optimized out>
#1  0x00007ffff2e076f0 in *__GI_abort () at abort.c:92
        act = {__sigaction_handler = {sa_handler = 0x7fffffffce58, sa_sigaction = 0x7fffffffce58}, sa_mask = {__val = {
              140737488342592, 140737488348103, 33, 140737269326962, 1, 140737269331337, 3, 140737488342587, 5, 
              140737269327027, 1, 140737269336037, 3, 140737488342596, 12, 140737269336041}}, sa_flags = 2, 
          sa_restorer = 0x7ffff2f207e9}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007ffff2e3f52b in __libc_message (do_abort=<optimized out>, fmt=<optimized out>)
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
        ap = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7fffffffd7c0, reg_save_area = 0x7fffffffd6d0}}
        ap_copy = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7fffffffd7c0, reg_save_area = 0x7fffffffd6d0}}
        fd = 2
        on_2 = <optimized out>
        list = <optimized out>
        nlist = 0
        cp = <optimized out>
        written = false
#3  0x00007ffff2e48d76 in malloc_printerr (action=3, str=0x7ffff2f22908 "double free or corruption (!prev)", 
    ptr=<optimized out>) at malloc.c:6312
        buf = "00007fffd4c390e0"
        cp = 0x0
#4  0x00007ffff2e4db1c in *__GI___libc_free (mem=<optimized out>) at malloc.c:3738
        ar_ptr = 0x7fffd4000020
        p = 0x6
#5  0x00007ffff3b5b44b in _pixman_image_fini (image=image@entry=0x7fffd4879820) at ../../pixman/pixman-image.c:173
        common = 0x7fffd4879820
        __PRETTY_FUNCTION__ = "_pixman_image_fini"
#6  0x00007ffff3b5b399 in pixman_image_unref (image=0x7fffd4879820) at ../../pixman/pixman-image.c:211
No locals.
#7  0x000055555585283b in qemu_pixman_image_unref (image=0x7fffd4879820) at ui/qemu-pixman.c:80
No locals.
#8  0x000055555587446b in vnc_dpy_switch (dcl=0x7fffe2c99048, surface=0x7fffd40b7c10) at ui/vnc.c:588
        vd = 0x7fffe2c99010
        vs = 0xff000000180420
#9  0x000055555584be81 in dpy_gfx_replace_surface (con=0x5555566a90a0, surface=0x7fffd40b7c10) at ui/console.c:1404
---Type <return> to continue, or q <return> to quit---

        s = 0x5555565f64b0
        old_surface = 0x7fffd487a040
        dcl = 0x7fffe2c99048
#10 0x00005555556ecd52 in qxl_render_update_area_unlocked (qxl=0x5555566dba20) at hw/display/qxl-render.c:131
        vga = 0x5555566dc510
        surface = 0x7fffd40b7c10
        i = 0
#11 0x00005555556ed021 in qxl_render_update_area_bh (opaque=0x5555566dba20) at hw/display/qxl-render.c:183
        qxl = 0x5555566dba20
#12 0x00005555555f5330 in aio_bh_poll (ctx=0x5555562f1c20) at async.c:81
        bh = 0x5555566a4770
        bhp = 0x7ffff77bfe86
        next = 0x5555566a3c00
        ret = 1
#13 0x00005555555f4f89 in aio_poll (ctx=0x5555562f1c20, blocking=false) at aio-posix.c:188
        node = 0x7ffff73269a4
        ret = 32767
        progress = false
#14 0x00005555555f5747 in aio_ctx_dispatch (source=0x5555562f1c20, callback=0, user_data=0x0) at async.c:205
        ctx = 0x5555562f1c20
        __PRETTY_FUNCTION__ = "aio_ctx_dispatch"
#15 0x00007ffff730c355 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#16 0x00005555557d41ce in glib_pollfds_poll () at main-loop.c:190
        context = 0x5555562f27c0
        pfds = 0x5555566da480
#17 0x00005555557d42ce in os_host_main_loop_wait (timeout=0) at main-loop.c:235
        ret = 2
        spin_counter = 1
#18 0x00005555557d43a1 in main_loop_wait (nonblocking=0) at main-loop.c:484
        ret = 21845
        timeout = 4294967295
        timeout_ns = 29767176
#19 0x000055555587fe0c in main_loop () at vl.c:2051
        nonblocking = false
        last_io = 1
#20 0x00005555558877e6 in main (argc=64, argv=0x7fffffffdfd8, envp=0x7fffffffe1e0) at vl.c:4507
---Type <return> to continue, or q <return> to quit---
        i = 64
        snapshot = 0
        linux_boot = 0
        icount_option = 0x0
        initrd_filename = 0x0
        kernel_filename = 0x0
        kernel_cmdline = 0x555555a22304 ""
        boot_order = 0x5555562ef840 "dc"
        ds = 0x5555565f64b0
        cyls = 0
        heads = 0
        secs = 0
        translation = 0
        hda_opts = 0x0
        opts = 0x5555562ef790
        machine_opts = 0x5555562f13f0
        olist = 0x555555e08220
        optind = 64
        optarg = 0x7fffffffe92d "if=ide,index=1,media=cdrom,cache=writeback,id=ide-832"
        loadvm = 0x0
        machine_class = 0x5555562e8540
        machine = 0x555555e0de80
        cpu_model = 0x0
        vga_model = 0x0
        qtest_chrdev = 0x0
        qtest_log = 0x0
        pid_file = 0x0
        incoming = 0x0
        show_vnc_port = 0
        defconfig = true
        userconfig = true
        log_mask = 0x0
        log_file = 0x0
        mem_trace = {malloc = 0x55555588369e <malloc_and_trace>, realloc = 0x5555558836f6 <realloc_and_trace>, 
          free = 0x55555588375d <free_and_trace>, calloc = 0, try_malloc = 0, try_realloc = 0}
        trace_events = 0x0
        trace_file = 0x0
---Type <return> to continue, or q <return> to quit---
        __func__ = "main"
        args = {machine = 0x555555e0de80, ram_size = 4160749568, boot_order = 0x5555562ef840 "dc", 
          kernel_filename = 0x0, kernel_cmdline = 0x555555a22304 "", initrd_filename = 0x0, cpu_model = 0x0}



Best Regards
From: Fabio Fantoni
Date: 2014-07-17 16:52
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 17/07/2014 03:48, kevin.zhang@octlink.com ha scritto:

Hi Fabio Fantoni,

     I finally got it. If that's not enough, I will provide more as u guide.
     I adjust the time to just after xl create and can get stack info as follow :
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007ffff7dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) c
Continuing.

Program received signal SIGABRT, Aborted.
0x00007ffff2e04475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt full
#0  0x00007ffff2e04475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007ffff2e076f0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x00007ffff2e3f52b in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3  0x00007ffff2e48d76 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#4  0x00007ffff2e4db1c in free () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#5  0x00007ffff3b5b44b in ?? () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
No symbol table info available.
#6  0x00007ffff3b5b399 in pixman_image_unref () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
No symbol table info available.
#7  0x000055555585283b in qemu_pixman_image_unref (image=0x555558cd1170) at ui/qemu-pixman.c:80
No locals.
#8  0x000055555587446b in vnc_dpy_switch (dcl=0x7fffe2cbc048, surface=0x5555563263c0) at ui/vnc.c:588
        vd = 0x7fffe2cbc010
        vs = 0xff000000180420
#9  0x000055555584be81 in dpy_gfx_replace_surface (con=0x5555566a2550, surface=0x5555563263c0) at ui/console.c:1404
        s = 0x555556715b90
        old_surface = 0x5555566e01e0
        dcl = 0x7fffe2cbc048
#10 0x00005555556ecd52 in qxl_render_update_area_unlocked (qxl=0x555556715bc0) at hw/display/qxl-render.c:131
        vga = 0x5555567166b0
        surface = 0x5555563263c0
        i = 0
#11 0x00005555556ed021 in qxl_render_update_area_bh (opaque=0x555556715bc0) at hw/display/qxl-render.c:183
        qxl = 0x555556715bc0
#12 0x00005555555f5330 in aio_bh_poll (ctx=0x5555562f1c30) at async.c:81
        bh = 0x5555565fb700
        bhp = 0x7ffff77bfe86
        next = 0x5555566afd00
        ret = 1
#13 0x00005555555f4f89 in aio_poll (ctx=0x5555562f1c30, blocking=false) at aio-posix.c:188
        node = 0x7ffff73269a4
        ret = 32767
---Type <return> to continue, or q <return> to quit---
        progress = false
#14 0x00005555555f5747 in aio_ctx_dispatch (source=0x5555562f1c30, callback=0, user_data=0x0) at async.c:205
        ctx = 0x5555562f1c30
        __PRETTY_FUNCTION__ = "aio_ctx_dispatch"
#15 0x00007ffff730c355 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#16 0x00005555557d41ce in glib_pollfds_poll () at main-loop.c:190
        context = 0x5555562f27c0
        pfds = 0x5555566f75c0
#17 0x00005555557d42ce in os_host_main_loop_wait (timeout=0) at main-loop.c:235
        ret = 1
        spin_counter = 1
#18 0x00005555557d43a1 in main_loop_wait (nonblocking=0) at main-loop.c:484
        ret = 21845
        timeout = 4294967295
        timeout_ns = 17515866
#19 0x000055555587fe0c in main_loop () at vl.c:2051
        nonblocking = false
        last_io = 0
#20 0x00005555558877e6 in main (argc=64, argv=0x7fffffffdfb8, envp=0x7fffffffe1c0) at vl.c:4507
        i = 64
        snapshot = 0
        linux_boot = 0
        icount_option = 0x0
        initrd_filename = 0x0
        kernel_filename = 0x0
        kernel_cmdline = 0x555555a22304 ""
        boot_order = 0x5555562ef840 "dc"
        ds = 0x555556715b90
        cyls = 0
        heads = 0
        secs = 0
        translation = 0
        hda_opts = 0x0
        opts = 0x5555562ef790
        machine_opts = 0x5555562f13f0
        olist = 0x555555e08220
---Type <return> to continue, or q <return> to quit---
        optind = 64
        optarg = 0x7fffffffe915 "if=ide,index=1,media=cdrom,cache=writeback,id=ide-832"
        loadvm = 0x0
        machine_class = 0x5555562e8540
        machine = 0x555555e0de80
        cpu_model = 0x0
        vga_model = 0x0
        qtest_chrdev = 0x0
        qtest_log = 0x0
        pid_file = 0x0
        incoming = 0x0
        show_vnc_port = 0
        defconfig = true
        userconfig = true
        log_mask = 0x0
        log_file = 0x0
        mem_trace = {malloc = 0x55555588369e <malloc_and_trace>, realloc = 0x5555558836f6 <realloc_and_trace>, 
          free = 0x55555588375d <free_and_trace>, calloc = 0, try_malloc = 0, try_realloc = 0}
        trace_events = 0x0
        trace_file = 0x0
        __func__ = "main"
        args = {machine = 0x555555e0de80, ram_size = 4160749568, boot_order = 0x5555562ef840 "dc", 
          kernel_filename = 0x0, kernel_cmdline = 0x555555a22304 "", initrd_filename = 0x0, cpu_model = 0x0}

In your test vnc is still enabled, right? Can you try disabling vnc (vnc=0 in domU's xl cfg)?
Install also these packages for missed symbols: libc6-dbg libpixman-1-0-dbg

Thanks for any reply.







Best Regards
发件人： Fabio Fantoni
发送时间： 2014-07-16 17:03
收件人： kevin.zhang@octlink.com; xen-devel
主题： Re:回复: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 16/07/2014 09:04, kevin.zhang@octlink.com ha scritto:

Hi Fabio Fantoni,

     Thank you for your advice for building xen unstable.
     Because I have to use debian wheezy as production distro, I've got to do the test in it.
     Today, I edit Config.mk and write:
QEMU_UPSTREAM_URL = git://git.qemu.org/qemu.git
QEMU_UPSTREAM_REVISION = master
     Then, the built qemu-xen binary works well.  Therefore, I guess that git://xenbits.xen.org/qemu-upstream-unstable.git  has some very little difference
compared to qemu.git. Maybe your environment cannot repeat  that problem either, I'd like to provide any useful information to resolve this problem.

I also use wheezy for both production and develop/testing.
I tried now on my latest testing build, of some days ago xen from rebase/m2r-staging branch and qemu mainline with same Config.mk before build.
On windows 7 pro 64 bit domUs with latest spice guest tools auto and manual resolution change works without problem.
I'm still unable to reproduce your qemu crash.

You can retry to catch and post backtrace with my latest better explain?


I know, I already posted the solution but I try to explain better.

# after xl create with (qemu gdb), do it fast after xl create when arrive on qemu process launch (before timeout or xl create will fails)
target remote localhost:1234 # prepare this command in other ssh to the xen dom0 and enter on xl create when arrive on qemu launch
c # press immediatly
bt full # when qemu stops

Sorry for my bad english.







Best Regards
From: Fabio Fantoni
Date: 2014-07-15 16:09
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 15/07/2014 07:53, kevin.zhang@octlink.com ha scritto:

Hi Fabio Fantoni,
      Today I tried to use wheezy backports version of spice-server, the problem persists with qemu-xen binary, while my self compiled qemu 2.0 works well.
I think it is a problem and can be repeated.
     Then, I will summarize my compilation process here:
     Firstly install debian wheezy 7.5 amd64 and necessary build dependency. Then:
1. git clone  git://xenbits.xen.org/xen.git
2.  install backport version  libspice-server-dev libspice-protocol-dev
root@debian:~#  apt-cache policy libspice-server-dev libspice-protocol-dev
libspice-server-dev:
  Installed: 0.12.4-0nocelt2~bpo70+1
  Candidate: 0.12.4-0nocelt2~bpo70+1
  Version table:
*** 0.12.4-0nocelt2~bpo70+1 0
        100 http://cdn.debian.net/debian/ wheezy-backports/main amd64 Packages
        100 /var/lib/dpkg/status
libspice-protocol-dev:
  Installed: 0.12.6-1~bpo70+2
  Candidate: 0.12.6-1~bpo70+2
  Version table:
*** 0.12.6-1~bpo70+2 0
        100 http://cdn.debian.net/debian/ wheezy-backports/main amd64 Packages
        100 /var/lib/dpkg/status
 3. patch for QXL option
 4. ./configure --prefix=/usr 
 5. add spice and usb-redir option for qemu-xen-upstream
 6. make xen;make tools;make install-xen;make install-tools

       To compile qemu 2.0 from qemu.org:
       1. wget http://wiki.qemu-project.org/download/qemu-2.0.0.tar.bz2
       2. ./configure --enable-xen --target-list=i386-softmmu --extra-cflags="-I/usr/src/xen/tools/include -I/usr/src/xen/tools/libxc -I/usr/src/xen/tools/xenstore" \
            --enable-spice --enable-usb-redir 
       3 .make;make install



For fast unstable tests I do this (using my github rebase/m2r-*):
Install of opus, usbredir and libusbx from backports.
Rebuild and install new seabios 1.7.5-1 and spice packages (server 0.12.5-1 and protocol 0.12.7-1) from sid that contains many fixes (simply and fast with git clone of debian repository and debuild).
./configure --prefix=/usr --enable-qemu-traditional=no --with-system-seabios=/usr/share/seabios/bios-256k.bin --with-extra-qemuu-configure-args="--enable-spice --enable-usb-redir"
make debball
dpkg -i of xen package in dist (contain both xen and qemu)
And if I need to test newer qemu in development I simply change the qemu git with mainline in Config.mk.

And for newer production servers I start prepared new xen's debian packages awaiting debian maintainers replies:
https://github.com/Fantu/pkg-xen/tree/wheezy-backports
Needs also qemu rebuild to use new xen 4.4 libraries (simply and fast with git clone of debian repository and debuild).

There is also a problem of jpeg-turbo in debian and for have better performances and not too many cpu waste I for now solved with:
apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E
vi /etc/apt/sources.list.d/x2go.list
# X2Go Repository (for jpeg-turbo as default and with full -dev package)
deb http://packages.x2go.org/debian wheezy heuler
deb-src http://packages.x2go.org/debian wheezy heuler
aptitude update
aptitude install x2go-keyring && aptitude update
aptitude install libjpeg8-turbo-dev






Best Regards
发件人： kevin.zhang@octlink.com
发送时间： 2014-07-14 16:49
收件人： Fabio Fantoni; xen-devel
主题： 回复: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Hi Fabio Fantoni,
     
      Thank you for your reply.
      It is really weird. 
      I compiled both qemu binary ( qemu-upstream in xen and qemu-2.0 from qemu.org website) in the same environment,  the binary in xen has the problem while 
the other one works well.
      I will check whether wheezy backport has libspice-server-dev and libspice-protocol-dev and try again. 




Best Regards
From: Fabio Fantoni
Date: 2014-07-14 15:59
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 14/07/2014 07:29, kevin.zhang@octlink.com ha scritto:

Hi Fabio Fantoni,
    
     Today, I've done another test on xenbits xen 4.5 unstable.
     This time, I directly compiled xen on my test server, and use default libspice-server-dev  and libspice-protocol-dev header files for spice option.
    
root@debian:~# apt-cache policy libspice-server-dev libspice-protocol-dev
libspice-server-dev:
  Installed: 0.11.0-1+deb7u1
  Candidate: 0.11.0-1+deb7u1
  Version table:
*** 0.11.0-1+deb7u1 0
        500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status
libspice-protocol-dev:
  Installed: 0.10.1-1
  Candidate: 0.10.1-1
  Version table:
*** 0.10.1-1 0
        500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status

     I also download qemu-2.0 source code from qemu.org, and compiled it by the way mentioned in http://wiki.xen.org/wiki/QEMU_Upstream.
     Then I create win7 hvm with qemu-xen and /usr/local/bin/qemu-system-i386 respectively.
     The result shows that:
      1 . qemu-upstream used in xen 4.5 unstable still exited when changing screen resolution,
      2.  my self-compiled qemu2.0 behave normally.
     I think maybe there's still some differences between the two qemu repository.

Use spice from backports or recompile the latest from Sid, wheezy packages are too old for newer qemu.
xen already download and compile qemu upstream automatically if you not specify binary in repository.
I also use use wheezy dom0 with same xen and qemu and same domU and spice guest tools installed automatically resize the windows resolution without problem (except rare cases when I connect remote-viewer before windows start).
Below also reply to other mail.



     I'm actively waiting for your advice and willing to do the following debug.
     vm config file is as follow:
name='Win7'
builder="hvm"
memory=2048
vcpus=2
vif=['bridge=br0']
disk=['/srv/vm_templates/1.qcow2,qcow2,hda,rw',',raw,hdb,ro,cdrom']
boot='dc'
device_model_version="qemu-xen"
#device_model_override="/usr/lib/xen/bin/qemu-gdb"
#device_model_override="/usr/local/bin/qemu-system-i386"
viridian=1
vnc=1
vnclisten="0.0.0.0"
on_crash="destroy"
vga="qxl"
spice=1
spicehost='0.0.0.0'
spiceport=6000
spicedisable_ticketing=1
spicevdagent=1
spice_clipboard_sharing=1
spiceusbredirection=4
soundhw="hda"
localtime=1
videoram=128

videoram=128 is not needed with qxl as already the default.
Try to disable vnc when you use spice, even if I used with also vnc many times without problem time ago.



   




Best Regards
From: kevin.zhang@octlink.com
Date: 2014-07-14 10:26
To: Fabio Fantoni; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Hi Fabio Fantoni,
    Thank you for your help.
     If I use your method to run qemu-gdb when using xl create, xl will complain startup timeout. 

I know, I already posted the solution but I try to explain better.

# after xl create with (qemu gdb), do it fast after xl create when arrive on qemu process launch (before timeout or xl create will fails)
target remote localhost:1234 # prepare this command in other ssh to the xen dom0 and enter on xl create when arrive on qemu launch
c # press immediatly
bt full # when qemu stops

Sorry for my bad english.


    Perhaps I did not describe my problem clearly enough, I can successfully create windows HVM, my problem happened when I change windows screen resolution.
The qemu process suddenly  exited while xl list can still list the domU information.

    I am using debian wheezy 7.5 amd 64, I am using fantu's xen 4.5 unstable and the qemu-xen-remote in his code repository,
root@debian:~# /usr/lib/xen/bin/qemu-system-i386 -version
QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice Bellard  
 And I compiled Xen from fantu's xen repository in compilation server, then use install.sh in dist dir to install xen packages in my test server.
 My compilation server has spice 0.12.4 compiled and installed.
 My test server has debian wheezy backport qemu installed with spice-server:
dpkg -l |grep spice
ii  libspice-server1:amd64             0.12.4-0nocelt2~bpo70+1   
 Then how can I obtain useful debug information after qemu exit with vm running?




Best Regards
From: Fabio Fantoni
Date: 2014-07-11 18:06
To: kevin.zhang@octlink.com; xen-devel
Subject: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
Il 11/07/2014 04:38, kevin.zhang@octlink.com ha scritto:

Hi all,

Firstly please forgive me if I put this problem in the wrong mail list. 
However, it seems that xen-users mail list cannot resolve this QXL problems. Therefore, I have to post QXL problem in devel mail list.
My problem is as follow:

I'm testing QXL for windows HVM, spice works well with stdvga. 
However, when I switch to QXL, qemu exit abnormally:
I specify vga="qxl" and videoram=128, using qemu-xen. The windows 7 boots and automatially switch resolution for me in virt-viewer.
While display and sound transfering very well, if I change display resolution, the virt-viewer will be suddenly closed and
I check the physical server, the qemu process disappear simultaneously. 
Then I switch to wheezy backport qemu 2.0 as device model, the qemu process will exit as soon as the welcome page appears and at the beginning of resolution change.
I tested and found the same bug on both xenbits xen 4.4.1 rc1 and Fantu's Xen 4.5 unstable, this problem exists in both branches.
Is it a known issue or is there any solution for this bug?
Thank you very much! 

Thanks for testing spice and qxl and report issue.
I have spice + qxl working as kvm on xen unstable except this problem:
http://lists.xen.org/archives/html/xen-devel/2014-07/msg01021.html

Please post details on your dom0 installation and domU (for example xl cfg,
spice guest tools version ecc...)
About qemu crash try to take a full backtrace with gdb and post it here.

Small help with gdb of qemu launched by xl:

Add the line below in domU's xl cfg:
device_model_override="/usr/lib/xen/bin/qemu-gdb"

vi /usr/lib/xen/bin/qemu-gdb # create the file, change the qemu path if
needed
#!/bin/sh
exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386 "$@"

# after xl create, do it fast (before timeout or xl create will fails)
target remote localhost:1234
c 
bt full # when qemu stops

You should install also all needed dbg packages before, spice qemu ecc or
without package should be compiled with debug enabled (for xen and qemu
default in unstable).

The latest qemu crash with spice I saw was in 2.0-rc solved before 2.0.0
final, your qemu is at least 2.0.0 final?
http://git.qemu.org/?p=qemu.git;a=commit;h=dc491cfc14074064ed54a872b62cce6ca1330644




Kevin
Best Regards,

[-- Attachment #1.2: Type: text/html, Size: 88858 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

qemu crash on windows 7 resolution change on spice

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 30772 bytes --]

Il 18/07/2014 04:01, kevin.zhang@octlink.com ha scritto:
> Hi Fabio Fantoni,
>      I closed vnc options and can reproduce the problem, stack info is
> as follow:
>
>         (gdb)  target remote localhost:1234
>         Remote debugging using localhost:1234
>         Reading symbols from /lib64/ld-linux-x86-64.so.2...(no
>         debugging symbols found)...done.
>         Loaded symbols for /lib64/ld-linux-x86-64.so.2
>         0x00007ffff7dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
>         (gdb) c
>         Continuing.
>         Program received signal SIGABRT, Aborted.
>         0x00007ffff2e04475 in *__GI_raise (sig=<optimized out>) at
>         ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>         64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or
>         directory.
>         (gdb) bt full
>         #0 0x00007ffff2e04475 in *__GI_raise (sig=<optimized out>) at
>         ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>                 pid = <optimized out>
>                 selftid = <optimized out>
>         #1 0x00007ffff2e076f0 in *__GI_abort () at abort.c:92
>                 act = {__sigaction_handler = {sa_handler =
>         0x7fffffffce58, sa_sigaction = 0x7fffffffce58}, sa_mask =
>         {__val = {
>         140737488342592, 140737488348103, 33, 140737269326962, 1,
>         140737269331337, 3, 140737488342587, 5,
>         140737269327027, 1, 140737269336037, 3, 140737488342596, 12,
>         140737269336041}}, sa_flags = 2,
>         sa_restorer = 0x7ffff2f207e9}
>                 sigs = {__val = {32, 0 <repeats 15 times>}}
>         #2 0x00007ffff2e3f52b in __libc_message (do_abort=<optimized
>         out>, fmt=<optimized out>)
>             at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
>                 ap = {{gp_offset = 40, fp_offset = 48,
>         overflow_arg_area = 0x7fffffffd7c0, reg_save_area =
>         0x7fffffffd6d0}}
>                 ap_copy = {{gp_offset = 16, fp_offset = 48,
>         overflow_arg_area = 0x7fffffffd7c0, reg_save_area =
>         0x7fffffffd6d0}}
>                 fd = 2
>                 on_2 = <optimized out>
>                 list = <optimized out>
>                 nlist = 0
>                 cp = <optimized out>
>                 written = false
>         #3 0x00007ffff2e48d76 in malloc_printerr (action=3,
>         str=0x7ffff2f22908 "double free or corruption (!prev)",
>         ptr=<optimized out>) at malloc.c:6312
>                 buf = "00007fffd4c390e0"
>                 cp = 0x0
>         #4 0x00007ffff2e4db1c in *__GI___libc_free (mem=<optimized
>         out>) at malloc.c:3738
>                 ar_ptr = 0x7fffd4000020
>                 p = 0x6
>         #5 0x00007ffff3b5b44b in _pixman_image_fini
>         (image=image@entry=0x7fffd4879820) at
>         ../../pixman/pixman-image.c:173
>                 common = 0x7fffd4879820
>         __PRETTY_FUNCTION__ = "_pixman_image_fini"
>         #6 0x00007ffff3b5b399 in pixman_image_unref
>         (image=0x7fffd4879820) at ../../pixman/pixman-image.c:211
>         No locals.
>         #7 0x000055555585283b in qemu_pixman_image_unref
>         (image=0x7fffd4879820) at ui/qemu-pixman.c:80
>         No locals.
>         #8 0x000055555587446b in vnc_dpy_switch (dcl=0x7fffe2c99048,
>         surface=0x7fffd40b7c10) at ui/vnc.c:588
>                 vd = 0x7fffe2c99010
>                 vs = 0xff000000180420
>         #9 0x000055555584be81 in dpy_gfx_replace_surface
>         (con=0x5555566a90a0, surface=0x7fffd40b7c10) at ui/console.c:1404
>         ---Type <return> to continue, or q <return> to quit---
>                 s = 0x5555565f64b0
>         old_surface = 0x7fffd487a040
>                 dcl = 0x7fffe2c99048
>         #10 0x00005555556ecd52 in qxl_render_update_area_unlocked
>         (qxl=0x5555566dba20) at hw/display/qxl-render.c:131
>                 vga = 0x5555566dc510
>                 surface = 0x7fffd40b7c10
>                 i = 0
>         #11 0x00005555556ed021 in qxl_render_update_area_bh
>         (opaque=0x5555566dba20) at hw/display/qxl-render.c:183
>                 qxl = 0x5555566dba20
>         #12 0x00005555555f5330 in aio_bh_poll (ctx=0x5555562f1c20) at
>         async.c:81
>                 bh = 0x5555566a4770
>                 bhp = 0x7ffff77bfe86
>                 next = 0x5555566a3c00
>                 ret = 1
>         #13 0x00005555555f4f89 in aio_poll (ctx=0x5555562f1c20,
>         blocking=false) at aio-posix.c:188
>                 node = 0x7ffff73269a4
>                 ret = 32767
>                 progress = false
>         #14 0x00005555555f5747 in aio_ctx_dispatch
>         (source=0x5555562f1c20, callback=0, user_data=0x0) at async.c:205
>                 ctx = 0x5555562f1c20
>         __PRETTY_FUNCTION__ = "aio_ctx_dispatch"
>         #15 0x00007ffff730c355 in g_main_context_dispatch () from
>         /lib/x86_64-linux-gnu/libglib-2.0.so.0
>         No symbol table info available.
>         #16 0x00005555557d41ce in glib_pollfds_poll () at main-loop.c:190
>                 context = 0x5555562f27c0
>                 pfds = 0x5555566da480
>         #17 0x00005555557d42ce in os_host_main_loop_wait (timeout=0)
>         at main-loop.c:235
>                 ret = 2
>         spin_counter = 1
>         #18 0x00005555557d43a1 in main_loop_wait (nonblocking=0) at
>         main-loop.c:484
>                 ret = 21845
>                 timeout = 4294967295
>         timeout_ns = 29767176
>         #19 0x000055555587fe0c in main_loop () at vl.c:2051
>         nonblocking = false
>                 last_io = 1
>         #20 0x00005555558877e6 in main (argc=64, argv=0x7fffffffdfd8,
>         envp=0x7fffffffe1e0) at vl.c:4507
>         ---Type <return> to continue, or q <return> to quit---
>                 i = 64
>                 snapshot = 0
>         linux_boot = 0
>         icount_option = 0x0
>         initrd_filename = 0x0
>         kernel_filename = 0x0
>         kernel_cmdline = 0x555555a22304 ""
>         boot_order = 0x5555562ef840 "dc"
>                 ds = 0x5555565f64b0
>                 cyls = 0
>                 heads = 0
>                 secs = 0
>         translation = 0
>                 hda_opts = 0x0
>                 opts = 0x5555562ef790
>         machine_opts = 0x5555562f13f0
>                 olist = 0x555555e08220
>                 optind = 64
>                 optarg = 0x7fffffffe92d
>         "if=ide,index=1,media=cdrom,cache=writeback,id=ide-832"
>                 loadvm = 0x0
>         machine_class = 0x5555562e8540
>                 machine = 0x555555e0de80
>         cpu_model = 0x0
>         vga_model = 0x0
>         qtest_chrdev = 0x0
>         qtest_log = 0x0
>                 pid_file = 0x0
>                 incoming = 0x0
>         show_vnc_port = 0
>         defconfig = true
>         userconfig = true
>                 log_mask = 0x0
>                 log_file = 0x0
>         mem_trace = {malloc = 0x55555588369e <malloc_and_trace>,
>         realloc = 0x5555558836f6 <realloc_and_trace>,
>                   free = 0x55555588375d <free_and_trace>, calloc = 0,
>         try_malloc = 0, try_realloc = 0}
>         trace_events = 0x0
>         trace_file = 0x0
>         ---Type <return> to continue, or q <return> to quit---
>                 __func__ = "main"
>                 args = {machine = 0x555555e0de80, ram_size =
>         4160749568, boot_order = 0x5555562ef840 "dc",
>         kernel_filename = 0x0, kernel_cmdline = 0x555555a22304 "",
>         initrd_filename = 0x0, cpu_model = 0x0}
>

Thanks for the full backtrace.
I added qemu-devel and spice-devel as cc.
Can someone take a look at this backtrace of qemu crash on windows 7
resolution change when connect with spice and help to solve it please?
Some other details are in previous mails below.

Thanks for any reply.

> ------------------------------------------------------------------------
> Best Regards
>
> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
> *Date:* 2014-07-17 16:52
> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>;
> xen-devel <mailto:xen-devel@lists.xen.org>
> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
> Il 17/07/2014 03:48, kevin.zhang@octlink.com ha scritto:
>> Hi Fabio Fantoni,
>>      I finally got it. If that's not enough, I will provide more as u
>> guide.
>>      I adjust the time to just after xl create and can get stack info
>> as follow :
>>
>>     (gdb) target remote localhost:1234
>>     Remote debugging using localhost:1234
>>     Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging
>>     symbols found)...done.
>>     Loaded symbols for /lib64/ld-linux-x86-64.so.2
>>     0x00007ffff7dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
>>     (gdb) c
>>     Continuing.
>>     Program received signal SIGABRT, Aborted.
>>     0x00007ffff2e04475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>>     (gdb) bt full
>>     #0  0x00007ffff2e04475 in raise () from
>>     /lib/x86_64-linux-gnu/libc.so.6
>>     No symbol table info available.
>>     #1  0x00007ffff2e076f0 in abort () from
>>     /lib/x86_64-linux-gnu/libc.so.6
>>     No symbol table info available.
>>     #2  0x00007ffff2e3f52b in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>     No symbol table info available.
>>     #3  0x00007ffff2e48d76 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>     No symbol table info available.
>>     #4  0x00007ffff2e4db1c in free () from
>>     /lib/x86_64-linux-gnu/libc.so.6
>>     No symbol table info available.
>>     #5  0x00007ffff3b5b44b in ?? () from
>>     /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
>>     No symbol table info available.
>>     #6  0x00007ffff3b5b399 in pixman_image_unref () from
>>     /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
>>     No symbol table info available.
>>     #7  0x000055555585283b in qemu_pixman_image_unref
>>     (image=0x555558cd1170) at ui/qemu-pixman.c:80
>>     No locals.
>>     #8  0x000055555587446b in vnc_dpy_switch (dcl=0x7fffe2cbc048,
>>     surface=0x5555563263c0) at ui/vnc.c:588
>>             vd = 0x7fffe2cbc010
>>             vs = 0xff000000180420
>>     #9  0x000055555584be81 in dpy_gfx_replace_surface
>>     (con=0x5555566a2550, surface=0x5555563263c0) at ui/console.c:1404
>>             s = 0x555556715b90
>>             old_surface = 0x5555566e01e0
>>             dcl = 0x7fffe2cbc048
>>     #10 0x00005555556ecd52 in qxl_render_update_area_unlocked
>>     (qxl=0x555556715bc0) at hw/display/qxl-render.c:131
>>             vga = 0x5555567166b0
>>             surface = 0x5555563263c0
>>             i = 0
>>     #11 0x00005555556ed021 in qxl_render_update_area_bh
>>     (opaque=0x555556715bc0) at hw/display/qxl-render.c:183
>>             qxl = 0x555556715bc0
>>     #12 0x00005555555f5330 in aio_bh_poll (ctx=0x5555562f1c30) at
>>     async.c:81
>>             bh = 0x5555565fb700
>>             bhp = 0x7ffff77bfe86
>>             next = 0x5555566afd00
>>             ret = 1
>>     #13 0x00005555555f4f89 in aio_poll (ctx=0x5555562f1c30,
>>     blocking=false) at aio-posix.c:188
>>             node = 0x7ffff73269a4
>>             ret = 32767
>>     ---Type <return> to continue, or q <return> to quit---
>>             progress = false
>>     #14 0x00005555555f5747 in aio_ctx_dispatch
>>     (source=0x5555562f1c30, callback=0, user_data=0x0) at async.c:205
>>             ctx = 0x5555562f1c30
>>             __PRETTY_FUNCTION__ = "aio_ctx_dispatch"
>>     #15 0x00007ffff730c355 in g_main_context_dispatch () from
>>     /lib/x86_64-linux-gnu/libglib-2.0.so.0
>>     No symbol table info available.
>>     #16 0x00005555557d41ce in glib_pollfds_poll () at main-loop.c:190
>>             context = 0x5555562f27c0
>>             pfds = 0x5555566f75c0
>>     #17 0x00005555557d42ce in os_host_main_loop_wait (timeout=0) at
>>     main-loop.c:235
>>             ret = 1
>>             spin_counter = 1
>>     #18 0x00005555557d43a1 in main_loop_wait (nonblocking=0) at
>>     main-loop.c:484
>>             ret = 21845
>>             timeout = 4294967295
>>             timeout_ns = 17515866
>>     #19 0x000055555587fe0c in main_loop () at vl.c:2051
>>             nonblocking = false
>>             last_io = 0
>>     #20 0x00005555558877e6 in main (argc=64, argv=0x7fffffffdfb8,
>>     envp=0x7fffffffe1c0) at vl.c:4507
>>             i = 64
>>             snapshot = 0
>>             linux_boot = 0
>>             icount_option = 0x0
>>             initrd_filename = 0x0
>>             kernel_filename = 0x0
>>             kernel_cmdline = 0x555555a22304 ""
>>             boot_order = 0x5555562ef840 "dc"
>>             ds = 0x555556715b90
>>             cyls = 0
>>             heads = 0
>>             secs = 0
>>             translation = 0
>>             hda_opts = 0x0
>>             opts = 0x5555562ef790
>>             machine_opts = 0x5555562f13f0
>>             olist = 0x555555e08220
>>     ---Type <return> to continue, or q <return> to quit---
>>             optind = 64
>>             optarg = 0x7fffffffe915
>>     "if=ide,index=1,media=cdrom,cache=writeback,id=ide-832"
>>             loadvm = 0x0
>>             machine_class = 0x5555562e8540
>>             machine = 0x555555e0de80
>>             cpu_model = 0x0
>>             vga_model = 0x0
>>             qtest_chrdev = 0x0
>>             qtest_log = 0x0
>>             pid_file = 0x0
>>             incoming = 0x0
>>             show_vnc_port = 0
>>             defconfig = true
>>             userconfig = true
>>             log_mask = 0x0
>>             log_file = 0x0
>>             mem_trace = {malloc = 0x55555588369e <malloc_and_trace>,
>>     realloc = 0x5555558836f6 <realloc_and_trace>,
>>               free = 0x55555588375d <free_and_trace>, calloc = 0,
>>     try_malloc = 0, try_realloc = 0}
>>             trace_events = 0x0
>>             trace_file = 0x0
>>             __func__ = "main"
>>             args = {machine = 0x555555e0de80, ram_size = 4160749568,
>>     boot_order = 0x5555562ef840 "dc",
>>               kernel_filename = 0x0, kernel_cmdline = 0x555555a22304
>>     "", initrd_filename = 0x0, cpu_model = 0x0}
>>
>
> In your test vnc is still enabled, right? Can you try disabling vnc
> (vnc=0 in domU's xl cfg)?
> Install also these packages for missed symbols: libc6-dbg
> libpixman-1-0-dbg
>
> Thanks for any reply.
>
>> ------------------------------------------------------------------------
>> Best Regards
>>
>> *发件人：* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
>> *发送时间：* 2014-07-16 17:03
>> *收件人：* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>;
>> xen-devel <mailto:xen-devel@lists.xen.org>
>> *主题：* Re:回复: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen
>> 4.5 unstable
>> Il 16/07/2014 09:04, kevin.zhang@octlink.com ha scritto:
>>> Hi Fabio Fantoni,
>>>      Thank you for your advice for building xen unstable.
>>>      Because I have to use debian wheezy as production distro, I've
>>> got to do the test in it.
>>>      Today, I edit Config.mk and write:
>>> QEMU_UPSTREAM_URL = git://git.qemu.org/qemu.git
>>> QEMU_UPSTREAM_REVISION = master
>>>      Then, the built qemu-xen binary works well. Therefore, I guess
>>> that git://xenbits.xen.org/qemu-upstream-unstable.git has some very
>>> little difference
>>> compared to qemu.git. Maybe your environment cannot repeat  that
>>> problem either, I'd like to provide any useful information to
>>> resolve this problem.
>>
>> I also use wheezy for both production and develop/testing.
>> I tried now on my latest testing build, of some days ago xen from
>> rebase/m2r-staging branch and qemu mainline with same Config.mk
>> before build.
>> On windows 7 pro 64 bit domUs with latest spice guest tools auto and
>> manual resolution change works without problem.
>> I'm still unable to reproduce your qemu crash.
>>
>> You can retry to catch and post backtrace with my latest better explain?
>>
>>> I know, I already posted the solution but I try to explain better.
>>>
>>> # after xl create with (qemu gdb), do it fast after xl create when
>>> arrive on qemu process launch (before timeout or xl create will fails)
>>> target remote localhost:1234 # prepare this command in other ssh to
>>> the xen dom0 and enter on xl create when arrive on qemu launch
>>> c # press immediatly
>>> bt full # when qemu stops
>>>
>>> Sorry for my bad english.
>>
>>
>>> ------------------------------------------------------------------------
>>> Best Regards
>>>
>>> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
>>> *Date:* 2014-07-15 16:09
>>> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>;
>>> xen-devel <mailto:xen-devel@lists.xen.org>
>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>>> unstable
>>> Il 15/07/2014 07:53, kevin.zhang@octlink.com ha scritto:
>>>> Hi Fabio Fantoni,
>>>>       Today I tried to use wheezy backports version of
>>>> spice-server, the problem persists with qemu-xen binary, while my
>>>> self compiled qemu 2.0 works well.
>>>> I think it is a problem and can be repeated.
>>>>      Then, I will summarize my compilation process here:
>>>>      Firstly install debian wheezy 7.5 amd64 and necessary build
>>>> dependency. Then:
>>>>
>>>>     1. git clone git://xenbits.xen.org/xen.git
>>>>     <http://xenbits.xen.org/gitweb/?p=xen.git>
>>>>     2.  install backport version  libspice-server-dev
>>>>     libspice-protocol-dev
>>>>
>>>>         root@debian:~# apt-cache policy libspice-server-dev
>>>>         libspice-protocol-dev
>>>>         libspice-server-dev:
>>>>           Installed: 0.12.4-0nocelt2~bpo70+1
>>>>           Candidate: 0.12.4-0nocelt2~bpo70+1
>>>>           Version table:
>>>>         *** 0.12.4-0nocelt2~bpo70+1 0
>>>>                 100 http://cdn.debian.net/debian/
>>>>         wheezy-backports/main amd64 Packages
>>>>                 100 /var/lib/dpkg/status
>>>>         libspice-protocol-dev:
>>>>           Installed: 0.12.6-1~bpo70+2
>>>>           Candidate: 0.12.6-1~bpo70+2
>>>>           Version table:
>>>>         *** 0.12.6-1~bpo70+2 0
>>>>                 100 http://cdn.debian.net/debian/
>>>>         wheezy-backports/main amd64 Packages
>>>>                 100 /var/lib/dpkg/status
>>>>
>>>>      3. patch for QXL option
>>>>      4. ./configure --prefix=/usr
>>>>      5. add spice and usb-redir option for qemu-xen-upstream
>>>>      6. make xen;make tools;make install-xen;make install-tools
>>>>
>>>>        To compile qemu 2.0 from qemu.org:
>>>>        1. wget http://wiki.qemu-project.org/download/qemu-2.0.0.tar.bz2
>>>>        2. ./configure --enable-xen --target-list=i386-softmmu
>>>> --extra-cflags="-I/usr/src/xen/tools/include
>>>> -I/usr/src/xen/tools/libxc -I/usr/src/xen/tools/xenstore" \
>>>>  --enable-spice --enable-usb-redir
>>>>        3 .make;make install
>>>
>>> For fast unstable tests I do this (using my github rebase/m2r-*):
>>> Install of opus, usbredir and libusbx from backports.
>>> Rebuild and install new seabios 1.7.5-1 and spice packages (server
>>> 0.12.5-1 and protocol 0.12.7-1) from sid that contains many fixes
>>> (simply and fast with git clone of debian repository and debuild).
>>> ./configure --prefix=/usr --enable-qemu-traditional=no
>>> --with-system-seabios=/usr/share/seabios/bios-256k.bin
>>> --with-extra-qemuu-configure-args="--enable-spice --enable-usb-redir"
>>> make debball
>>> dpkg -i of xen package in dist (contain both xen and qemu)
>>> And if I need to test newer qemu in development I simply change the
>>> qemu git with mainline in Config.mk.
>>>
>>> And for newer production servers I start prepared new xen's debian
>>> packages awaiting debian maintainers replies:
>>> https://github.com/Fantu/pkg-xen/tree/wheezy-backports
>>> Needs also qemu rebuild to use new xen 4.4 libraries (simply and
>>> fast with git clone of debian repository and debuild).
>>>
>>> There is also a problem of jpeg-turbo in debian and for have better
>>> performances and not too many cpu waste I for now solved with:
>>> apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E
>>> vi /etc/apt/sources.list.d/x2go.list
>>> # X2Go Repository (for jpeg-turbo as default and with full -dev package)
>>> deb http://packages.x2go.org/debian wheezy heuler
>>> deb-src http://packages.x2go.org/debian wheezy heuler
>>> aptitude update
>>> aptitude install x2go-keyring && aptitude update
>>> aptitude install libjpeg8-turbo-dev
>>>
>>>> ------------------------------------------------------------------------
>>>> Best Regards
>>>>
>>>> *发件人：* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>
>>>> *发送时间：* 2014-07-14 16:49
>>>> *收件人：* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>; xen-devel
>>>> <mailto:xen-devel@lists.xen.org>
>>>> *主题：* 回复: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen
>>>> 4.5 unstable
>>>> Hi Fabio Fantoni,
>>>>       Thank you for your reply.
>>>>       It is really weird.
>>>>       I compiled both qemu binary ( qemu-upstream in xen and
>>>> qemu-2.0 from qemu.org website) in the same environment,
>>>> the binary in xen has the problem while
>>>> the other one works well.
>>>>       I will check whether wheezy backport has libspice-server-dev
>>>> and libspice-protocol-dev and try again.
>>>> ------------------------------------------------------------------------
>>>> Best Regards
>>>>
>>>> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
>>>> *Date:* 2014-07-14 15:59
>>>> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>;
>>>> xen-devel <mailto:xen-devel@lists.xen.org>
>>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>>>> unstable
>>>> Il 14/07/2014 07:29, kevin.zhang@octlink.com ha scritto:
>>>>> Hi Fabio Fantoni,
>>>>>      Today, I've done another test on xenbits xen 4.5 unstable.
>>>>>      This time, I directly compiled xen on my test server, and use
>>>>> default libspice-server-dev  and libspice-protocol-dev header
>>>>> files for spice option.
>>>>>
>>>>>         root@debian:~# apt-cache policy libspice-server-dev
>>>>>         libspice-protocol-dev
>>>>>         libspice-server-dev:
>>>>>         Installed: 0.11.0-1+deb7u1
>>>>>         Candidate: 0.11.0-1+deb7u1
>>>>>         Version table:
>>>>>         *** 0.11.0-1+deb7u1 0
>>>>>         500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
>>>>>         100 /var/lib/dpkg/status
>>>>>         libspice-protocol-dev:
>>>>>         Installed: 0.10.1-1
>>>>>         Candidate: 0.10.1-1
>>>>>         Version table:
>>>>>         *** 0.10.1-1 0
>>>>>         500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
>>>>>         100 /var/lib/dpkg/status
>>>>>
>>>>>      I also download qemu-2.0 source code from qemu.org, and
>>>>> compiled it by the way mentioned in
>>>>> http://wiki.xen.org/wiki/QEMU_Upstream.
>>>>>      Then I create win7 hvm with qemu-xen and
>>>>> /usr/local/bin/qemu-system-i386 respectively.
>>>>>      The result shows that:
>>>>>       1 . qemu-upstream used in xen 4.5 unstable still exited when
>>>>> changing screen resolution,
>>>>>       2.  my self-compiled qemu2.0 behave normally.
>>>>>      I think maybe there's still some differences between the two
>>>>> qemu repository.
>>>>
>>>> Use spice from backports or recompile the latest from Sid, wheezy
>>>> packages are too old for newer qemu.
>>>> xen already download and compile qemu upstream automatically if you
>>>> not specify binary in repository.
>>>> I also use use wheezy dom0 with same xen and qemu and same domU and
>>>> spice guest tools installed automatically resize the windows
>>>> resolution without problem (except rare cases when I connect
>>>> remote-viewer before windows start).
>>>> Below also reply to other mail.
>>>>
>>>>>      I'm actively waiting for your advice and willing to do the
>>>>> following debug.
>>>>>      vm config file is as follow:
>>>>>
>>>>>     name='Win7'
>>>>>     builder="hvm"
>>>>>     memory=2048
>>>>>     vcpus=2
>>>>>     vif=['bridge=br0']
>>>>>     disk=['/srv/vm_templates/1.qcow2,qcow2,hda,rw',',raw,hdb,ro,cdrom']
>>>>>     boot='dc'
>>>>>     device_model_version="qemu-xen"
>>>>>     #device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>>>     #device_model_override="/usr/local/bin/qemu-system-i386"
>>>>>     viridian=1
>>>>>     vnc=1
>>>>>     vnclisten="0.0.0.0"
>>>>>     on_crash="destroy"
>>>>>     vga="qxl"
>>>>>     spice=1
>>>>>     spicehost='0.0.0.0'
>>>>>     spiceport=6000
>>>>>     spicedisable_ticketing=1
>>>>>     spicevdagent=1
>>>>>     spice_clipboard_sharing=1
>>>>>     spiceusbredirection=4
>>>>>     soundhw="hda"
>>>>>     localtime=1
>>>>>     videoram=128
>>>>>
>>>>
>>>> videoram=128 is not needed with qxl as already the default.
>>>> Try to disable vnc when you use spice, even if I used with also vnc
>>>> many times without problem time ago.
>>>>
>>>>> ------------------------------------------------------------------------
>>>>> Best Regards
>>>>>
>>>>> *From:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>
>>>>> *Date:* 2014-07-14 10:26
>>>>> *To:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>; xen-devel
>>>>> <mailto:xen-devel@lists.xen.org>
>>>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>>>>> unstable
>>>>> Hi Fabio Fantoni,
>>>>>     Thank you for your help.
>>>>>      If I use your method to run qemu-gdb when using xl create, xl
>>>>> will complain startup timeout.
>>>>
>>>> I know, I already posted the solution but I try to explain better.
>>>>
>>>> # after xl create with (qemu gdb), do it fast after xl create when
>>>> arrive on qemu process launch (before timeout or xl create will fails)
>>>> target remote localhost:1234 # prepare this command in other ssh to
>>>> the xen dom0 and enter on xl create when arrive on qemu launch
>>>> c # press immediatly
>>>> bt full # when qemu stops
>>>>
>>>> Sorry for my bad english.
>>>>
>>>>>     Perhaps I did not describe my problem clearly enough, I can
>>>>> successfully create windows HVM, my problem happened when I change
>>>>> windows screen resolution.
>>>>> The qemu process suddenly  exited while xl list can still list the
>>>>> domU information.
>>>>>     I am using debian wheezy 7.5 amd 64, I am using fantu's xen
>>>>> 4.5 unstable and the qemu-xen-remote in his code repository,
>>>>>
>>>>>     root@debian:~# /usr/lib/xen/bin/qemu-system-i386 -version
>>>>>     QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice
>>>>>     Bellard
>>>>>
>>>>>  And I compiled Xen from fantu's xen repository in compilation
>>>>> server, then use install.sh in dist dir to install xen packages in
>>>>> my test server.
>>>>>  My compilation server has spice 0.12.4 compiled and installed.
>>>>>  My test server has debian wheezy backport qemu installed with
>>>>> spice-server:
>>>>>
>>>>>     dpkg -l |grep spice
>>>>>     ii libspice-server1:amd64 0.12.4-0nocelt2~bpo70+1
>>>>>
>>>>>  Then how can I obtain useful debug information after qemu exit
>>>>> with vm running?
>>>>> ------------------------------------------------------------------------
>>>>> Best Regards
>>>>>
>>>>> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
>>>>> *Date:* 2014-07-11 18:06
>>>>> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>;
>>>>> xen-devel <mailto:xen-devel@lists.xen.org>
>>>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>>>>> unstable
>>>>> Il 11/07/2014 04:38, kevin.zhang@octlink.com ha scritto:
>>>>>> Hi all,
>>>>>> Firstly please forgive me if I put this problem in the wrong mail
>>>>>> list.
>>>>>> However, it seems that xen-users mail list cannot resolve this
>>>>>> QXL problems. Therefore, I have to post QXL problem in devel mail
>>>>>> list.
>>>>>> My problem is as follow:
>>>>>> I'm testing QXL for windows HVM, spice works well with stdvga.
>>>>>> However, when I switch to QXL, qemu exit abnormally:
>>>>>> I specify vga="qxl" and videoram=128, using qemu-xen. The windows
>>>>>> 7 boots and automatially switch resolution for me in virt-viewer.
>>>>>> While display and sound transfering very well, if I change
>>>>>> display resolution, the virt-viewer will be suddenly closed and
>>>>>> I check the physical server, the qemu process disappear
>>>>>> simultaneously.
>>>>>> Then I switch to wheezy backport qemu 2.0 as device model, the
>>>>>> qemu process will exit as soon as the welcome page appears and at
>>>>>> the beginning of resolution change.
>>>>>> I tested and found the same bug on both xenbits xen 4.4.1 rc1 and
>>>>>> Fantu's Xen 4.5 unstable, this problem exists in both branches.
>>>>>> Is it a known issue or is there any solution for this bug?
>>>>>> Thank you very much!
>>>>>
>>>>> Thanks for testing spice and qxl and report issue.
>>>>> I have spice + qxl working as kvm on xen unstable except this problem:
>>>>> http://lists.xen.org/archives/html/xen-devel/2014-07/msg01021.html
>>>>>
>>>>> Please post details on your dom0 installation and domU (for
>>>>> example xl cfg,
>>>>> spice guest tools version ecc...)
>>>>> About qemu crash try to take a full backtrace with gdb and post it
>>>>> here.
>>>>>
>>>>> Small help with gdb of qemu launched by xl:
>>>>>
>>>>> Add the line below in domU's xl cfg:
>>>>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>>>
>>>>> vi /usr/lib/xen/bin/qemu-gdb # create the file, change the qemu
>>>>> path if
>>>>> needed
>>>>> #!/bin/sh
>>>>> exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386 "$@"
>>>>>
>>>>> # after xl create, do it fast (before timeout or xl create will fails)
>>>>> target remote localhost:1234
>>>>> c
>>>>> bt full # when qemu stops
>>>>>
>>>>> You should install also all needed dbg packages before, spice qemu
>>>>> ecc or
>>>>> without package should be compiled with debug enabled (for xen and
>>>>> qemu
>>>>> default in unstable).
>>>>>
>>>>> The latest qemu crash with spice I saw was in 2.0-rc solved before
>>>>> 2.0.0
>>>>> final, your qemu is at least 2.0.0 final?
>>>>> http://git.qemu.org/?p=qemu.git;a=commit;h=dc491cfc14074064ed54a872b62cce6ca1330644
>>>>>
>>>>>> Kevin
>>>>>> Best Regards,
>>>>>>
>>>>>>
>>>>
>>>
>>
>


[-- Attachment #1.2: Type: text/html, Size: 171349 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: qemu crash on windows 7 resolution change on spice

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 31744 bytes --]

Il 18/07/2014 09:55, Fabio Fantoni ha scritto:
> Il 18/07/2014 04:01, kevin.zhang@octlink.com ha scritto:
>> Hi Fabio Fantoni,
>>      I closed vnc options and can reproduce the problem, stack info
>> is as follow:
>>
>>         (gdb)  target remote localhost:1234
>>         Remote debugging using localhost:1234
>>         Reading symbols from /lib64/ld-linux-x86-64.so.2...(no
>>         debugging symbols found)...done.
>>         Loaded symbols for /lib64/ld-linux-x86-64.so.2
>>         0x00007ffff7dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
>>         (gdb) c
>>         Continuing.
>>         Program received signal SIGABRT, Aborted.
>>         0x00007ffff2e04475 in *__GI_raise (sig=<optimized out>) at
>>         ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>>         64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or
>>         directory.
>>         (gdb) bt full
>>         #0 0x00007ffff2e04475 in *__GI_raise (sig=<optimized out>) at
>>         ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>>                 pid = <optimized out>
>>         selftid = <optimized out>
>>         #1 0x00007ffff2e076f0 in *__GI_abort () at abort.c:92
>>                 act = {__sigaction_handler = {sa_handler =
>>         0x7fffffffce58, sa_sigaction = 0x7fffffffce58}, sa_mask =
>>         {__val = {
>>         140737488342592, 140737488348103, 33, 140737269326962, 1,
>>         140737269331337, 3, 140737488342587, 5,
>>         140737269327027, 1, 140737269336037, 3, 140737488342596, 12,
>>         140737269336041}}, sa_flags = 2,
>>         sa_restorer = 0x7ffff2f207e9}
>>                 sigs = {__val = {32, 0 <repeats 15 times>}}
>>         #2 0x00007ffff2e3f52b in __libc_message (do_abort=<optimized
>>         out>, fmt=<optimized out>)
>>             at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
>>                 ap = {{gp_offset = 40, fp_offset = 48,
>>         overflow_arg_area = 0x7fffffffd7c0, reg_save_area =
>>         0x7fffffffd6d0}}
>>         ap_copy = {{gp_offset = 16, fp_offset = 48, overflow_arg_area
>>         = 0x7fffffffd7c0, reg_save_area = 0x7fffffffd6d0}}
>>                 fd = 2
>>                 on_2 = <optimized out>
>>                 list = <optimized out>
>>                 nlist = 0
>>                 cp = <optimized out>
>>         written = false
>>         #3 0x00007ffff2e48d76 in malloc_printerr (action=3,
>>         str=0x7ffff2f22908 "double free or corruption (!prev)",
>>         ptr=<optimized out>) at malloc.c:6312
>>                 buf = "00007fffd4c390e0"
>>                 cp = 0x0
>>         #4 0x00007ffff2e4db1c in *__GI___libc_free (mem=<optimized
>>         out>) at malloc.c:3738
>>                 ar_ptr = 0x7fffd4000020
>>                 p = 0x6
>>         #5 0x00007ffff3b5b44b in _pixman_image_fini
>>         (image=image@entry=0x7fffd4879820) at
>>         ../../pixman/pixman-image.c:173
>>                 common = 0x7fffd4879820
>>         __PRETTY_FUNCTION__ = "_pixman_image_fini"
>>         #6 0x00007ffff3b5b399 in pixman_image_unref
>>         (image=0x7fffd4879820) at ../../pixman/pixman-image.c:211
>>         No locals.
>>         #7 0x000055555585283b in qemu_pixman_image_unref
>>         (image=0x7fffd4879820) at ui/qemu-pixman.c:80
>>         No locals.
>>         #8 0x000055555587446b in vnc_dpy_switch (dcl=0x7fffe2c99048,
>>         surface=0x7fffd40b7c10) at ui/vnc.c:588
>>                 vd = 0x7fffe2c99010
>>                 vs = 0xff000000180420
>>         #9 0x000055555584be81 in dpy_gfx_replace_surface
>>         (con=0x5555566a90a0, surface=0x7fffd40b7c10) at ui/console.c:1404
>>         ---Type <return> to continue, or q <return> to quit---
>>                 s = 0x5555565f64b0
>>         old_surface = 0x7fffd487a040
>>                 dcl = 0x7fffe2c99048
>>         #10 0x00005555556ecd52 in qxl_render_update_area_unlocked
>>         (qxl=0x5555566dba20) at hw/display/qxl-render.c:131
>>                 vga = 0x5555566dc510
>>         surface = 0x7fffd40b7c10
>>                 i = 0
>>         #11 0x00005555556ed021 in qxl_render_update_area_bh
>>         (opaque=0x5555566dba20) at hw/display/qxl-render.c:183
>>                 qxl = 0x5555566dba20
>>         #12 0x00005555555f5330 in aio_bh_poll (ctx=0x5555562f1c20) at
>>         async.c:81
>>                 bh = 0x5555566a4770
>>                 bhp = 0x7ffff77bfe86
>>                 next = 0x5555566a3c00
>>                 ret = 1
>>         #13 0x00005555555f4f89 in aio_poll (ctx=0x5555562f1c20,
>>         blocking=false) at aio-posix.c:188
>>                 node = 0x7ffff73269a4
>>                 ret = 32767
>>         progress = false
>>         #14 0x00005555555f5747 in aio_ctx_dispatch
>>         (source=0x5555562f1c20, callback=0, user_data=0x0) at async.c:205
>>                 ctx = 0x5555562f1c20
>>         __PRETTY_FUNCTION__ = "aio_ctx_dispatch"
>>         #15 0x00007ffff730c355 in g_main_context_dispatch () from
>>         /lib/x86_64-linux-gnu/libglib-2.0.so.0
>>         No symbol table info available.
>>         #16 0x00005555557d41ce in glib_pollfds_poll () at main-loop.c:190
>>         context = 0x5555562f27c0
>>                 pfds = 0x5555566da480
>>         #17 0x00005555557d42ce in os_host_main_loop_wait (timeout=0)
>>         at main-loop.c:235
>>                 ret = 2
>>         spin_counter = 1
>>         #18 0x00005555557d43a1 in main_loop_wait (nonblocking=0) at
>>         main-loop.c:484
>>                 ret = 21845
>>         timeout = 4294967295
>>         timeout_ns = 29767176
>>         #19 0x000055555587fe0c in main_loop () at vl.c:2051
>>         nonblocking = false
>>         last_io = 1
>>         #20 0x00005555558877e6 in main (argc=64, argv=0x7fffffffdfd8,
>>         envp=0x7fffffffe1e0) at vl.c:4507
>>         ---Type <return> to continue, or q <return> to quit---
>>                 i = 64
>>         snapshot = 0
>>         linux_boot = 0
>>         icount_option = 0x0
>>         initrd_filename = 0x0
>>         kernel_filename = 0x0
>>         kernel_cmdline = 0x555555a22304 ""
>>         boot_order = 0x5555562ef840 "dc"
>>                 ds = 0x5555565f64b0
>>                 cyls = 0
>>                 heads = 0
>>                 secs = 0
>>         translation = 0
>>         hda_opts = 0x0
>>                 opts = 0x5555562ef790
>>         machine_opts = 0x5555562f13f0
>>                 olist = 0x555555e08220
>>                 optind = 64
>>                 optarg = 0x7fffffffe92d
>>         "if=ide,index=1,media=cdrom,cache=writeback,id=ide-832"
>>                 loadvm = 0x0
>>         machine_class = 0x5555562e8540
>>         machine = 0x555555e0de80
>>         cpu_model = 0x0
>>         vga_model = 0x0
>>         qtest_chrdev = 0x0
>>         qtest_log = 0x0
>>         pid_file = 0x0
>>         incoming = 0x0
>>         show_vnc_port = 0
>>         defconfig = true
>>         userconfig = true
>>         log_mask = 0x0
>>         log_file = 0x0
>>         mem_trace = {malloc = 0x55555588369e <malloc_and_trace>,
>>         realloc = 0x5555558836f6 <realloc_and_trace>,
>>                   free = 0x55555588375d <free_and_trace>, calloc = 0,
>>         try_malloc = 0, try_realloc = 0}
>>         trace_events = 0x0
>>         trace_file = 0x0
>>         ---Type <return> to continue, or q <return> to quit---
>>         __func__ = "main"
>>                 args = {machine = 0x555555e0de80, ram_size =
>>         4160749568, boot_order = 0x5555562ef840 "dc",
>>         kernel_filename = 0x0, kernel_cmdline = 0x555555a22304 "",
>>         initrd_filename = 0x0, cpu_model = 0x0}
>>
>
> Thanks for the full backtrace.
> I added qemu-devel and spice-devel as cc.
> Can someone take a look at this backtrace of qemu crash on windows 7
> resolution change when connect with spice and help to solve it please?
> Some other details are in previous mails below.
>
> Thanks for any reply.

@Kevin, can you post the output of xl -vvv create please?
Looking backtrace seems still using something about vnc and is strange
if you disabled it from domU's xl cfg:
> #8  0x000055555587446b in vnc_dpy_switch (dcl=0x7fffe2c99048,
> surface=0x7fffd40b7c10) at ui/vnc.c:588
Thanks for any reply.



>
>> ------------------------------------------------------------------------
>> Best Regards
>>
>> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
>> *Date:* 2014-07-17 16:52
>> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>;
>> xen-devel <mailto:xen-devel@lists.xen.org>
>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>> unstable
>> Il 17/07/2014 03:48, kevin.zhang@octlink.com ha scritto:
>>> Hi Fabio Fantoni,
>>>      I finally got it. If that's not enough, I will provide more as
>>> u guide.
>>>      I adjust the time to just after xl create and can get stack
>>> info as follow :
>>>
>>>     (gdb) target remote localhost:1234
>>>     Remote debugging using localhost:1234
>>>     Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging
>>>     symbols found)...done.
>>>     Loaded symbols for /lib64/ld-linux-x86-64.so.2
>>>     0x00007ffff7dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
>>>     (gdb) c
>>>     Continuing.
>>>     Program received signal SIGABRT, Aborted.
>>>     0x00007ffff2e04475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>>>     (gdb) bt full
>>>     #0  0x00007ffff2e04475 in raise () from
>>>     /lib/x86_64-linux-gnu/libc.so.6
>>>     No symbol table info available.
>>>     #1  0x00007ffff2e076f0 in abort () from
>>>     /lib/x86_64-linux-gnu/libc.so.6
>>>     No symbol table info available.
>>>     #2  0x00007ffff2e3f52b in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>>     No symbol table info available.
>>>     #3  0x00007ffff2e48d76 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>>     No symbol table info available.
>>>     #4  0x00007ffff2e4db1c in free () from
>>>     /lib/x86_64-linux-gnu/libc.so.6
>>>     No symbol table info available.
>>>     #5  0x00007ffff3b5b44b in ?? () from
>>>     /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
>>>     No symbol table info available.
>>>     #6  0x00007ffff3b5b399 in pixman_image_unref () from
>>>     /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
>>>     No symbol table info available.
>>>     #7  0x000055555585283b in qemu_pixman_image_unref
>>>     (image=0x555558cd1170) at ui/qemu-pixman.c:80
>>>     No locals.
>>>     #8  0x000055555587446b in vnc_dpy_switch (dcl=0x7fffe2cbc048,
>>>     surface=0x5555563263c0) at ui/vnc.c:588
>>>             vd = 0x7fffe2cbc010
>>>             vs = 0xff000000180420
>>>     #9  0x000055555584be81 in dpy_gfx_replace_surface
>>>     (con=0x5555566a2550, surface=0x5555563263c0) at ui/console.c:1404
>>>             s = 0x555556715b90
>>>             old_surface = 0x5555566e01e0
>>>             dcl = 0x7fffe2cbc048
>>>     #10 0x00005555556ecd52 in qxl_render_update_area_unlocked
>>>     (qxl=0x555556715bc0) at hw/display/qxl-render.c:131
>>>             vga = 0x5555567166b0
>>>             surface = 0x5555563263c0
>>>             i = 0
>>>     #11 0x00005555556ed021 in qxl_render_update_area_bh
>>>     (opaque=0x555556715bc0) at hw/display/qxl-render.c:183
>>>             qxl = 0x555556715bc0
>>>     #12 0x00005555555f5330 in aio_bh_poll (ctx=0x5555562f1c30) at
>>>     async.c:81
>>>             bh = 0x5555565fb700
>>>             bhp = 0x7ffff77bfe86
>>>             next = 0x5555566afd00
>>>             ret = 1
>>>     #13 0x00005555555f4f89 in aio_poll (ctx=0x5555562f1c30,
>>>     blocking=false) at aio-posix.c:188
>>>             node = 0x7ffff73269a4
>>>             ret = 32767
>>>     ---Type <return> to continue, or q <return> to quit---
>>>             progress = false
>>>     #14 0x00005555555f5747 in aio_ctx_dispatch
>>>     (source=0x5555562f1c30, callback=0, user_data=0x0) at async.c:205
>>>             ctx = 0x5555562f1c30
>>>             __PRETTY_FUNCTION__ = "aio_ctx_dispatch"
>>>     #15 0x00007ffff730c355 in g_main_context_dispatch () from
>>>     /lib/x86_64-linux-gnu/libglib-2.0.so.0
>>>     No symbol table info available.
>>>     #16 0x00005555557d41ce in glib_pollfds_poll () at main-loop.c:190
>>>             context = 0x5555562f27c0
>>>             pfds = 0x5555566f75c0
>>>     #17 0x00005555557d42ce in os_host_main_loop_wait (timeout=0) at
>>>     main-loop.c:235
>>>             ret = 1
>>>             spin_counter = 1
>>>     #18 0x00005555557d43a1 in main_loop_wait (nonblocking=0) at
>>>     main-loop.c:484
>>>             ret = 21845
>>>             timeout = 4294967295
>>>             timeout_ns = 17515866
>>>     #19 0x000055555587fe0c in main_loop () at vl.c:2051
>>>             nonblocking = false
>>>             last_io = 0
>>>     #20 0x00005555558877e6 in main (argc=64, argv=0x7fffffffdfb8,
>>>     envp=0x7fffffffe1c0) at vl.c:4507
>>>             i = 64
>>>             snapshot = 0
>>>             linux_boot = 0
>>>             icount_option = 0x0
>>>             initrd_filename = 0x0
>>>             kernel_filename = 0x0
>>>             kernel_cmdline = 0x555555a22304 ""
>>>             boot_order = 0x5555562ef840 "dc"
>>>             ds = 0x555556715b90
>>>             cyls = 0
>>>             heads = 0
>>>             secs = 0
>>>             translation = 0
>>>             hda_opts = 0x0
>>>             opts = 0x5555562ef790
>>>             machine_opts = 0x5555562f13f0
>>>             olist = 0x555555e08220
>>>     ---Type <return> to continue, or q <return> to quit---
>>>             optind = 64
>>>             optarg = 0x7fffffffe915
>>>     "if=ide,index=1,media=cdrom,cache=writeback,id=ide-832"
>>>             loadvm = 0x0
>>>             machine_class = 0x5555562e8540
>>>             machine = 0x555555e0de80
>>>             cpu_model = 0x0
>>>             vga_model = 0x0
>>>             qtest_chrdev = 0x0
>>>             qtest_log = 0x0
>>>             pid_file = 0x0
>>>             incoming = 0x0
>>>             show_vnc_port = 0
>>>             defconfig = true
>>>             userconfig = true
>>>             log_mask = 0x0
>>>             log_file = 0x0
>>>             mem_trace = {malloc = 0x55555588369e <malloc_and_trace>,
>>>     realloc = 0x5555558836f6 <realloc_and_trace>,
>>>               free = 0x55555588375d <free_and_trace>, calloc = 0,
>>>     try_malloc = 0, try_realloc = 0}
>>>             trace_events = 0x0
>>>             trace_file = 0x0
>>>             __func__ = "main"
>>>             args = {machine = 0x555555e0de80, ram_size = 4160749568,
>>>     boot_order = 0x5555562ef840 "dc",
>>>               kernel_filename = 0x0, kernel_cmdline = 0x555555a22304
>>>     "", initrd_filename = 0x0, cpu_model = 0x0}
>>>
>>
>> In your test vnc is still enabled, right? Can you try disabling vnc
>> (vnc=0 in domU's xl cfg)?
>> Install also these packages for missed symbols: libc6-dbg
>> libpixman-1-0-dbg
>>
>> Thanks for any reply.
>>
>>> ------------------------------------------------------------------------
>>> Best Regards
>>>
>>> *发件人：* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
>>> *发送时间：* 2014-07-16 17:03
>>> *收件人：* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>;
>>> xen-devel <mailto:xen-devel@lists.xen.org>
>>> *主题：* Re:回复: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen
>>> 4.5 unstable
>>> Il 16/07/2014 09:04, kevin.zhang@octlink.com ha scritto:
>>>> Hi Fabio Fantoni,
>>>>      Thank you for your advice for building xen unstable.
>>>>      Because I have to use debian wheezy as production distro, I've
>>>> got to do the test in it.
>>>>      Today, I edit Config.mk and write:
>>>> QEMU_UPSTREAM_URL = git://git.qemu.org/qemu.git
>>>> QEMU_UPSTREAM_REVISION = master
>>>>      Then, the built qemu-xen binary works well.  Therefore, I
>>>> guess that git://xenbits.xen.org/qemu-upstream-unstable.git has
>>>> some very little difference
>>>> compared to qemu.git. Maybe your environment cannot repeat  that
>>>> problem either, I'd like to provide any useful information to
>>>> resolve this problem.
>>>
>>> I also use wheezy for both production and develop/testing.
>>> I tried now on my latest testing build, of some days ago xen from
>>> rebase/m2r-staging branch and qemu mainline with same Config.mk
>>> before build.
>>> On windows 7 pro 64 bit domUs with latest spice guest tools auto and
>>> manual resolution change works without problem.
>>> I'm still unable to reproduce your qemu crash.
>>>
>>> You can retry to catch and post backtrace with my latest better explain?
>>>
>>>> I know, I already posted the solution but I try to explain better.
>>>>
>>>> # after xl create with (qemu gdb), do it fast after xl create when
>>>> arrive on qemu process launch (before timeout or xl create will fails)
>>>> target remote localhost:1234 # prepare this command in other ssh to
>>>> the xen dom0 and enter on xl create when arrive on qemu launch
>>>> c # press immediatly
>>>> bt full # when qemu stops
>>>>
>>>> Sorry for my bad english.
>>>
>>>
>>>> ------------------------------------------------------------------------
>>>> Best Regards
>>>>
>>>> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
>>>> *Date:* 2014-07-15 16:09
>>>> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>;
>>>> xen-devel <mailto:xen-devel@lists.xen.org>
>>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>>>> unstable
>>>> Il 15/07/2014 07:53, kevin.zhang@octlink.com ha scritto:
>>>>> Hi Fabio Fantoni,
>>>>>       Today I tried to use wheezy backports version of
>>>>> spice-server, the problem persists with qemu-xen binary, while my
>>>>> self compiled qemu 2.0 works well.
>>>>> I think it is a problem and can be repeated.
>>>>>      Then, I will summarize my compilation process here:
>>>>>      Firstly install debian wheezy 7.5 amd64 and necessary build
>>>>> dependency. Then:
>>>>>
>>>>>     1. git clone git://xenbits.xen.org/xen.git
>>>>>     <http://xenbits.xen.org/gitweb/?p=xen.git>
>>>>>     2.  install backport version  libspice-server-dev
>>>>>     libspice-protocol-dev
>>>>>
>>>>>         root@debian:~# apt-cache policy libspice-server-dev
>>>>>         libspice-protocol-dev
>>>>>         libspice-server-dev:
>>>>>           Installed: 0.12.4-0nocelt2~bpo70+1
>>>>>           Candidate: 0.12.4-0nocelt2~bpo70+1
>>>>>           Version table:
>>>>>         *** 0.12.4-0nocelt2~bpo70+1 0
>>>>>                 100 http://cdn.debian.net/debian/
>>>>>         wheezy-backports/main amd64 Packages
>>>>>                 100 /var/lib/dpkg/status
>>>>>         libspice-protocol-dev:
>>>>>           Installed: 0.12.6-1~bpo70+2
>>>>>           Candidate: 0.12.6-1~bpo70+2
>>>>>           Version table:
>>>>>         *** 0.12.6-1~bpo70+2 0
>>>>>                 100 http://cdn.debian.net/debian/
>>>>>         wheezy-backports/main amd64 Packages
>>>>>                 100 /var/lib/dpkg/status
>>>>>
>>>>>      3. patch for QXL option
>>>>>      4. ./configure --prefix=/usr
>>>>>      5. add spice and usb-redir option for qemu-xen-upstream
>>>>>      6. make xen;make tools;make install-xen;make install-tools
>>>>>
>>>>>        To compile qemu 2.0 from qemu.org:
>>>>>        1. wget
>>>>> http://wiki.qemu-project.org/download/qemu-2.0.0.tar.bz2
>>>>>        2. ./configure --enable-xen --target-list=i386-softmmu
>>>>> --extra-cflags="-I/usr/src/xen/tools/include
>>>>> -I/usr/src/xen/tools/libxc -I/usr/src/xen/tools/xenstore" \
>>>>>  --enable-spice --enable-usb-redir
>>>>>        3 .make;make install
>>>>
>>>> For fast unstable tests I do this (using my github rebase/m2r-*):
>>>> Install of opus, usbredir and libusbx from backports.
>>>> Rebuild and install new seabios 1.7.5-1 and spice packages (server
>>>> 0.12.5-1 and protocol 0.12.7-1) from sid that contains many fixes
>>>> (simply and fast with git clone of debian repository and debuild).
>>>> ./configure --prefix=/usr --enable-qemu-traditional=no
>>>> --with-system-seabios=/usr/share/seabios/bios-256k.bin
>>>> --with-extra-qemuu-configure-args="--enable-spice --enable-usb-redir"
>>>> make debball
>>>> dpkg -i of xen package in dist (contain both xen and qemu)
>>>> And if I need to test newer qemu in development I simply change the
>>>> qemu git with mainline in Config.mk.
>>>>
>>>> And for newer production servers I start prepared new xen's debian
>>>> packages awaiting debian maintainers replies:
>>>> https://github.com/Fantu/pkg-xen/tree/wheezy-backports
>>>> Needs also qemu rebuild to use new xen 4.4 libraries (simply and
>>>> fast with git clone of debian repository and debuild).
>>>>
>>>> There is also a problem of jpeg-turbo in debian and for have better
>>>> performances and not too many cpu waste I for now solved with:
>>>> apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E
>>>> vi /etc/apt/sources.list.d/x2go.list
>>>> # X2Go Repository (for jpeg-turbo as default and with full -dev
>>>> package)
>>>> deb http://packages.x2go.org/debian wheezy heuler
>>>> deb-src http://packages.x2go.org/debian wheezy heuler
>>>> aptitude update
>>>> aptitude install x2go-keyring && aptitude update
>>>> aptitude install libjpeg8-turbo-dev
>>>>
>>>>> ------------------------------------------------------------------------
>>>>> Best Regards
>>>>>
>>>>> *发件人：* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>
>>>>> *发送时间：* 2014-07-14 16:49
>>>>> *收件人：* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>; xen-devel
>>>>> <mailto:xen-devel@lists.xen.org>
>>>>> *主题：* 回复: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen
>>>>> 4.5 unstable
>>>>> Hi Fabio Fantoni,
>>>>>       Thank you for your reply.
>>>>>       It is really weird.
>>>>>       I compiled both qemu binary ( qemu-upstream in xen and
>>>>> qemu-2.0 from qemu.org website) in the same environment,
>>>>> the binary in xen has the problem while
>>>>> the other one works well.
>>>>>       I will check whether wheezy backport has libspice-server-dev
>>>>> and libspice-protocol-dev and try again.
>>>>> ------------------------------------------------------------------------
>>>>> Best Regards
>>>>>
>>>>> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
>>>>> *Date:* 2014-07-14 15:59
>>>>> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>;
>>>>> xen-devel <mailto:xen-devel@lists.xen.org>
>>>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>>>>> unstable
>>>>> Il 14/07/2014 07:29, kevin.zhang@octlink.com ha scritto:
>>>>>> Hi Fabio Fantoni,
>>>>>>      Today, I've done another test on xenbits xen 4.5 unstable.
>>>>>>      This time, I directly compiled xen on my test server, and
>>>>>> use default libspice-server-dev  and libspice-protocol-dev header
>>>>>> files for spice option.
>>>>>>
>>>>>>         root@debian:~# apt-cache policy libspice-server-dev
>>>>>>         libspice-protocol-dev
>>>>>>         libspice-server-dev:
>>>>>>         Installed: 0.11.0-1+deb7u1
>>>>>>         Candidate: 0.11.0-1+deb7u1
>>>>>>         Version table:
>>>>>>         *** 0.11.0-1+deb7u1 0
>>>>>>         500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
>>>>>>         100 /var/lib/dpkg/status
>>>>>>         libspice-protocol-dev:
>>>>>>         Installed: 0.10.1-1
>>>>>>         Candidate: 0.10.1-1
>>>>>>         Version table:
>>>>>>         *** 0.10.1-1 0
>>>>>>         500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
>>>>>>         100 /var/lib/dpkg/status
>>>>>>
>>>>>>      I also download qemu-2.0 source code from qemu.org, and
>>>>>> compiled it by the way mentioned in
>>>>>> http://wiki.xen.org/wiki/QEMU_Upstream.
>>>>>>      Then I create win7 hvm with qemu-xen and
>>>>>> /usr/local/bin/qemu-system-i386 respectively.
>>>>>>      The result shows that:
>>>>>>       1 . qemu-upstream used in xen 4.5 unstable still exited
>>>>>> when changing screen resolution,
>>>>>>       2.  my self-compiled qemu2.0 behave normally.
>>>>>>      I think maybe there's still some differences between the two
>>>>>> qemu repository.
>>>>>
>>>>> Use spice from backports or recompile the latest from Sid, wheezy
>>>>> packages are too old for newer qemu.
>>>>> xen already download and compile qemu upstream automatically if
>>>>> you not specify binary in repository.
>>>>> I also use use wheezy dom0 with same xen and qemu and same domU
>>>>> and spice guest tools installed automatically resize the windows
>>>>> resolution without problem (except rare cases when I connect
>>>>> remote-viewer before windows start).
>>>>> Below also reply to other mail.
>>>>>
>>>>>>      I'm actively waiting for your advice and willing to do the
>>>>>> following debug.
>>>>>>      vm config file is as follow:
>>>>>>
>>>>>>     name='Win7'
>>>>>>     builder="hvm"
>>>>>>     memory=2048
>>>>>>     vcpus=2
>>>>>>     vif=['bridge=br0']
>>>>>>     disk=['/srv/vm_templates/1.qcow2,qcow2,hda,rw',',raw,hdb,ro,cdrom']
>>>>>>     boot='dc'
>>>>>>     device_model_version="qemu-xen"
>>>>>>     #device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>>>>     #device_model_override="/usr/local/bin/qemu-system-i386"
>>>>>>     viridian=1
>>>>>>     vnc=1
>>>>>>     vnclisten="0.0.0.0"
>>>>>>     on_crash="destroy"
>>>>>>     vga="qxl"
>>>>>>     spice=1
>>>>>>     spicehost='0.0.0.0'
>>>>>>     spiceport=6000
>>>>>>     spicedisable_ticketing=1
>>>>>>     spicevdagent=1
>>>>>>     spice_clipboard_sharing=1
>>>>>>     spiceusbredirection=4
>>>>>>     soundhw="hda"
>>>>>>     localtime=1
>>>>>>     videoram=128
>>>>>>
>>>>>
>>>>> videoram=128 is not needed with qxl as already the default.
>>>>> Try to disable vnc when you use spice, even if I used with also
>>>>> vnc many times without problem time ago.
>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> Best Regards
>>>>>>
>>>>>> *From:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>
>>>>>> *Date:* 2014-07-14 10:26
>>>>>> *To:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>; xen-devel
>>>>>> <mailto:xen-devel@lists.xen.org>
>>>>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>>>>>> unstable
>>>>>> Hi Fabio Fantoni,
>>>>>>     Thank you for your help.
>>>>>>      If I use your method to run qemu-gdb when using xl create,
>>>>>> xl will complain startup timeout.
>>>>>
>>>>> I know, I already posted the solution but I try to explain better.
>>>>>
>>>>> # after xl create with (qemu gdb), do it fast after xl create when
>>>>> arrive on qemu process launch (before timeout or xl create will fails)
>>>>> target remote localhost:1234 # prepare this command in other ssh
>>>>> to the xen dom0 and enter on xl create when arrive on qemu launch
>>>>> c # press immediatly
>>>>> bt full # when qemu stops
>>>>>
>>>>> Sorry for my bad english.
>>>>>
>>>>>>     Perhaps I did not describe my problem clearly enough, I can
>>>>>> successfully create windows HVM, my problem happened when I
>>>>>> change windows screen resolution.
>>>>>> The qemu process suddenly  exited while xl list can still list
>>>>>> the domU information.
>>>>>>     I am using debian wheezy 7.5 amd 64, I am using fantu's xen
>>>>>> 4.5 unstable and the qemu-xen-remote in his code repository,
>>>>>>
>>>>>>     root@debian:~# /usr/lib/xen/bin/qemu-system-i386 -version
>>>>>>     QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice
>>>>>>     Bellard
>>>>>>
>>>>>>  And I compiled Xen from fantu's xen repository in compilation
>>>>>> server, then use install.sh in dist dir to install xen packages
>>>>>> in my test server.
>>>>>>  My compilation server has spice 0.12.4 compiled and installed.
>>>>>>  My test server has debian wheezy backport qemu installed with
>>>>>> spice-server:
>>>>>>
>>>>>>     dpkg -l |grep spice
>>>>>>     ii libspice-server1:amd64 0.12.4-0nocelt2~bpo70+1
>>>>>>
>>>>>>  Then how can I obtain useful debug information after qemu exit
>>>>>> with vm running?
>>>>>> ------------------------------------------------------------------------
>>>>>> Best Regards
>>>>>>
>>>>>> *From:* Fabio Fantoni <mailto:fabio.fantoni@m2r.biz>
>>>>>> *Date:* 2014-07-11 18:06
>>>>>> *To:* kevin.zhang@octlink.com <mailto:kevin.zhang@octlink.com>;
>>>>>> xen-devel <mailto:xen-devel@lists.xen.org>
>>>>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>>>>>> unstable
>>>>>> Il 11/07/2014 04:38, kevin.zhang@octlink.com ha scritto:
>>>>>>> Hi all,
>>>>>>> Firstly please forgive me if I put this problem in the wrong
>>>>>>> mail list.
>>>>>>> However, it seems that xen-users mail list cannot resolve this
>>>>>>> QXL problems. Therefore, I have to post QXL problem in devel
>>>>>>> mail list.
>>>>>>> My problem is as follow:
>>>>>>> I'm testing QXL for windows HVM, spice works well with stdvga.
>>>>>>> However, when I switch to QXL, qemu exit abnormally:
>>>>>>> I specify vga="qxl" and videoram=128, using qemu-xen. The
>>>>>>> windows 7 boots and automatially switch resolution for me in
>>>>>>> virt-viewer.
>>>>>>> While display and sound transfering very well, if I change
>>>>>>> display resolution, the virt-viewer will be suddenly closed and
>>>>>>> I check the physical server, the qemu process disappear
>>>>>>> simultaneously.
>>>>>>> Then I switch to wheezy backport qemu 2.0 as device model, the
>>>>>>> qemu process will exit as soon as the welcome page appears and
>>>>>>> at the beginning of resolution change.
>>>>>>> I tested and found the same bug on both xenbits xen 4.4.1 rc1
>>>>>>> and Fantu's Xen 4.5 unstable, this problem exists in both branches.
>>>>>>> Is it a known issue or is there any solution for this bug?
>>>>>>> Thank you very much!
>>>>>>
>>>>>> Thanks for testing spice and qxl and report issue.
>>>>>> I have spice + qxl working as kvm on xen unstable except this
>>>>>> problem:
>>>>>> http://lists.xen.org/archives/html/xen-devel/2014-07/msg01021.html
>>>>>>
>>>>>> Please post details on your dom0 installation and domU (for
>>>>>> example xl cfg,
>>>>>> spice guest tools version ecc...)
>>>>>> About qemu crash try to take a full backtrace with gdb and post
>>>>>> it here.
>>>>>>
>>>>>> Small help with gdb of qemu launched by xl:
>>>>>>
>>>>>> Add the line below in domU's xl cfg:
>>>>>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>>>>
>>>>>> vi /usr/lib/xen/bin/qemu-gdb # create the file, change the qemu
>>>>>> path if
>>>>>> needed
>>>>>> #!/bin/sh
>>>>>> exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386 "$@"
>>>>>>
>>>>>> # after xl create, do it fast (before timeout or xl create will
>>>>>> fails)
>>>>>> target remote localhost:1234
>>>>>> c
>>>>>> bt full # when qemu stops
>>>>>>
>>>>>> You should install also all needed dbg packages before, spice
>>>>>> qemu ecc or
>>>>>> without package should be compiled with debug enabled (for xen
>>>>>> and qemu
>>>>>> default in unstable).
>>>>>>
>>>>>> The latest qemu crash with spice I saw was in 2.0-rc solved
>>>>>> before 2.0.0
>>>>>> final, your qemu is at least 2.0.0 final?
>>>>>> http://git.qemu.org/?p=qemu.git;a=commit;h=dc491cfc14074064ed54a872b62cce6ca1330644
>>>>>>
>>>>>>> Kevin
>>>>>>> Best Regards,
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>


[-- Attachment #1.2: Type: text/html, Size: 179843 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel