Re: [Qemu-devel] qemu 2.2 crash on linux hvm domU (full backtrace included)
Il 14/11/2014 12:25, Fabio Fantoni ha scritto: dom0 xen-unstable from staging git with x86/hvm: Extend HVM cpuid leaf with vcpu id and x86/hvm: Add per-vcpu evtchn upcalls patches, and qemu 2.2 from spice git (spice/next commit e779fa0a715530311e6f59fc8adb0f6eca914a89): https://github.com/Fantu/Xen/commits/rebase/m2r-staging I tried with qemu tag v2.2.0-rc2 and crash still happen, here the full backtrace of latest test: Program received signal SIGSEGV, Segmentation fault. 0x55689b07 in vmport_ioport_read (opaque=0x564443a0, addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73 73 eax = env-regs[R_EAX]; (gdb) bt full #0 0x55689b07 in vmport_ioport_read (opaque=0x564443a0, addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73 s = 0x564443a0 cs = 0x0 cpu = 0x0 __func__ = vmport_ioport_read env = 0x8250 command = 0 '\000' eax = 0 #1 0x55655fc4 in memory_region_read_accessor (mr=0x5628, addr=0, value=0x7fffd8d0, size=4, shift=0, mask=4294967295) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410 tmp = 0 #2 0x556562b7 in access_with_adjusted_size (addr=0, value=0x7fffd8d0, size=4, access_size_min=4, access_size_max=4, access=0x55655f62 memory_region_read_accessor, mr=0x5628) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480 access_mask = 4294967295 access_size = 4 i = 0 #3 0x556590e9 in memory_region_dispatch_read1 (mr=0x5628, addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077 data = 0 #4 0x556591b1 in memory_region_dispatch_read (mr=0x5628, addr=0, pval=0x7fffd9a8, size=4) ---Type return to continue, or q return to quit--- at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099 No locals. #5 0x5565cbbc in io_mem_read (mr=0x5628, addr=0, pval=0x7fffd9a8, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962 No locals. #6 0x5560a1ca in address_space_rw (as=0x55eaf920, addr=22104, buf=0x7fffda50 \377\377\377\377, len=4, is_write=false) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167 l = 4 ptr = 0x55a92d87 %s/%d:\n val = 7852232130387826944 addr1 = 0 mr = 0x5628 error = false #7 0x5560a38f in address_space_read (as=0x55eaf920, addr=22104, buf=0x7fffda50 \377\377\377\377, len=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205 No locals. #8 0x5564fd4b in cpu_inl (addr=22104) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117 buf = \377\377\377\377 val = 21845 #9 0x55670c73 in do_inp (addr=22104, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684 ---Type return to continue, or q return to quit--- No locals. #10 0x55670ee0 in cpu_ioreq_pio (req=0x77ff3020) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747 i = 1 #11 0x556714b3 in handle_ioreq (state=0x563c2510, req=0x77ff3020) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853 No locals. #12 0x55671826 in cpu_handle_ioreq (opaque=0x563c2510) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931 state = 0x563c2510 req = 0x77ff3020 #13 0x5596e240 in qemu_iohandler_poll (pollfds=0x56389a30, ret=1) at iohandler.c:143 revents = 1 pioh = 0x563f7610 ioh = 0x56450a40 #14 0x5596de1c in main_loop_wait (nonblocking=0) at main-loop.c:495 ret = 1 timeout = 4294967295 timeout_ns = 3965432 #15 0x55756d3f in main_loop () at vl.c:1882 nonblocking = false last_io = 0 #16 0x5575ea49 in main (argc=62, argv=0x7fffe048, envp=0x7fffe240) at vl.c:4400 ---Type return to continue, or q return to quit--- i = 128 snapshot = 0 linux_boot = 0 initrd_filename = 0x0 kernel_filename = 0x0 kernel_cmdline = 0x55a48f86 boot_order = 0x56387460 dc ds = 0x564b2040 cyls = 0 heads = 0 secs = 0 translation = 0 hda_opts = 0x0 opts = 0x563873b0 machine_opts = 0x56389010 icount_opts = 0x0 olist = 0x55e57e80 optind = 62 optarg = 0x7fffe914 file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback loadvm = 0x0 machine_class = 0x5637d5c0 cpu_model = 0x0 vga_model = 0x0 qtest_chrdev = 0x0 ---Type return to continue, or q return to quit--- qtest_log = 0x0 pid_file = 0x0 incoming = 0x0 show_vnc_port = 0 defconfig = true userconfig = true log_mask = 0x0 log_file = 0x0
Re: [Qemu-devel] qemu 2.2 crash on linux hvm domU (full backtrace included)
I think I know what is happening here. But you are pointing at the
wrong change.
commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
Is what I am guessing at this time is the issue. I think that
xen_enabled() is
returning false in pc_machine_initfn. Where as in pc_init1 is is
returning true.
I am thinking that:
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7bb97a4..3268c29 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
.desc = Xen Fully-virtualized PC,
.init = pc_xen_hvm_init,
.max_cpus = HVM_MAX_VCPUS,
-.default_machine_opts = accel=xen,
+.default_machine_opts = accel=xen,vmport=off,
.hot_add_cpu = pc_hot_add_cpu,
};
#endif
Will fix your issue. I have not tested this yet.
-Don Slutz
On 11/19/14 09:04, Fabio Fantoni wrote:
Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
dom0 xen-unstable from staging git with x86/hvm: Extend HVM cpuid
leaf with vcpu id and x86/hvm: Add per-vcpu evtchn upcalls
patches, and qemu 2.2 from spice git (spice/next commit
e779fa0a715530311e6f59fc8adb0f6eca914a89):
https://github.com/Fantu/Xen/commits/rebase/m2r-staging
I tried with qemu tag v2.2.0-rc2 and crash still happen, here the
full backtrace of latest test:
Program received signal SIGSEGV, Segmentation fault.
0x55689b07 in vmport_ioport_read (opaque=0x564443a0, addr=0,
size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
73 eax = env-regs[R_EAX];
(gdb) bt full
#0 0x55689b07 in vmport_ioport_read (opaque=0x564443a0,
addr=0,
size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
s = 0x564443a0
cs = 0x0
cpu = 0x0
__func__ = vmport_ioport_read
env = 0x8250
command = 0 '\000'
eax = 0
#1 0x55655fc4 in memory_region_read_accessor
(mr=0x5628,
addr=0, value=0x7fffd8d0, size=4, shift=0, mask=4294967295)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
tmp = 0
#2 0x556562b7 in access_with_adjusted_size (addr=0,
value=0x7fffd8d0, size=4, access_size_min=4, access_size_max=4,
access=0x55655f62 memory_region_read_accessor,
mr=0x5628)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
access_mask = 4294967295
access_size = 4
i = 0
#3 0x556590e9 in memory_region_dispatch_read1
(mr=0x5628,
addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
data = 0
#4 0x556591b1 in memory_region_dispatch_read
(mr=0x5628,
addr=0, pval=0x7fffd9a8, size=4)
---Type return to continue, or q return to quit---
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
No locals.
#5 0x5565cbbc in io_mem_read (mr=0x5628, addr=0,
pval=0x7fffd9a8, size=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
No locals.
#6 0x5560a1ca in address_space_rw (as=0x55eaf920,
addr=22104,
buf=0x7fffda50 \377\377\377\377, len=4, is_write=false)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
l = 4
ptr = 0x55a92d87 %s/%d:\n
val = 7852232130387826944
addr1 = 0
mr = 0x5628
error = false
#7 0x5560a38f in address_space_read (as=0x55eaf920,
addr=22104,
buf=0x7fffda50 \377\377\377\377, len=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
No locals.
#8 0x5564fd4b in cpu_inl (addr=22104)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
buf = \377\377\377\377
val = 21845
#9 0x55670c73 in do_inp (addr=22104, size=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
---Type return to continue, or q return to quit---
No locals.
#10 0x55670ee0 in cpu_ioreq_pio (req=0x77ff3020)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
i = 1
#11 0x556714b3 in handle_ioreq (state=0x563c2510,
req=0x77ff3020) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
No locals.
#12 0x55671826 in cpu_handle_ioreq (opaque=0x563c2510)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
state = 0x563c2510
req = 0x77ff3020
#13 0x5596e240 in qemu_iohandler_poll
(pollfds=0x56389a30, ret=1)
at iohandler.c:143
revents = 1
pioh = 0x563f7610
ioh = 0x56450a40
#14 0x5596de1c in main_loop_wait (nonblocking=0) at
main-loop.c:495
ret = 1
timeout = 4294967295
timeout_ns = 3965432
#15 0x55756d3f in main_loop () at vl.c:1882
nonblocking = false
last_io = 0
#16 0x5575ea49 in main (argc=62, argv=0x7fffe048,
envp=0x7fffe240) at vl.c:4400
---Type return to continue, or q return to quit---
i = 128
snapshot = 0
linux_boot = 0
initrd_filename = 0x0
kernel_filename =
Re: [Qemu-devel] qemu 2.2 crash on linux hvm domU (full backtrace included)
Il 19/11/2014 15:56, Don Slutz ha scritto:
I think I know what is happening here. But you are pointing at the
wrong change.
commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
Is what I am guessing at this time is the issue. I think that
xen_enabled() is
returning false in pc_machine_initfn. Where as in pc_init1 is is
returning true.
I am thinking that:
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7bb97a4..3268c29 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
.desc = Xen Fully-virtualized PC,
.init = pc_xen_hvm_init,
.max_cpus = HVM_MAX_VCPUS,
-.default_machine_opts = accel=xen,
+.default_machine_opts = accel=xen,vmport=off,
.hot_add_cpu = pc_hot_add_cpu,
};
#endif
Will fix your issue. I have not tested this yet.
Tested now and it solves regression of linux hvm domUs with qemu 2.2,
thanks.
I think that I'm not the only with this regression and that this patch
(or a fix to the cause in vmport) should be applied before qemu 2.2 final.
-Don Slutz
On 11/19/14 09:04, Fabio Fantoni wrote:
Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
dom0 xen-unstable from staging git with x86/hvm: Extend HVM cpuid
leaf with vcpu id and x86/hvm: Add per-vcpu evtchn upcalls
patches, and qemu 2.2 from spice git (spice/next commit
e779fa0a715530311e6f59fc8adb0f6eca914a89):
https://github.com/Fantu/Xen/commits/rebase/m2r-staging
I tried with qemu tag v2.2.0-rc2 and crash still happen, here the
full backtrace of latest test:
Program received signal SIGSEGV, Segmentation fault.
0x55689b07 in vmport_ioport_read (opaque=0x564443a0,
addr=0,
size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
73 eax = env-regs[R_EAX];
(gdb) bt full
#0 0x55689b07 in vmport_ioport_read (opaque=0x564443a0,
addr=0,
size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
s = 0x564443a0
cs = 0x0
cpu = 0x0
__func__ = vmport_ioport_read
env = 0x8250
command = 0 '\000'
eax = 0
#1 0x55655fc4 in memory_region_read_accessor
(mr=0x5628,
addr=0, value=0x7fffd8d0, size=4, shift=0, mask=4294967295)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
tmp = 0
#2 0x556562b7 in access_with_adjusted_size (addr=0,
value=0x7fffd8d0, size=4, access_size_min=4, access_size_max=4,
access=0x55655f62 memory_region_read_accessor,
mr=0x5628)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
access_mask = 4294967295
access_size = 4
i = 0
#3 0x556590e9 in memory_region_dispatch_read1
(mr=0x5628,
addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
data = 0
#4 0x556591b1 in memory_region_dispatch_read
(mr=0x5628,
addr=0, pval=0x7fffd9a8, size=4)
---Type return to continue, or q return to quit---
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
No locals.
#5 0x5565cbbc in io_mem_read (mr=0x5628, addr=0,
pval=0x7fffd9a8, size=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
No locals.
#6 0x5560a1ca in address_space_rw (as=0x55eaf920,
addr=22104,
buf=0x7fffda50 \377\377\377\377, len=4, is_write=false)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
l = 4
ptr = 0x55a92d87 %s/%d:\n
val = 7852232130387826944
addr1 = 0
mr = 0x5628
error = false
#7 0x5560a38f in address_space_read (as=0x55eaf920,
addr=22104,
buf=0x7fffda50 \377\377\377\377, len=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
No locals.
#8 0x5564fd4b in cpu_inl (addr=22104)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
buf = \377\377\377\377
val = 21845
#9 0x55670c73 in do_inp (addr=22104, size=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
---Type return to continue, or q return to quit---
No locals.
#10 0x55670ee0 in cpu_ioreq_pio (req=0x77ff3020)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
i = 1
#11 0x556714b3 in handle_ioreq (state=0x563c2510,
req=0x77ff3020) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
No locals.
#12 0x55671826 in cpu_handle_ioreq (opaque=0x563c2510)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
state = 0x563c2510
req = 0x77ff3020
#13 0x5596e240 in qemu_iohandler_poll
(pollfds=0x56389a30, ret=1)
at iohandler.c:143
revents = 1
pioh = 0x563f7610
ioh = 0x56450a40
#14 0x5596de1c in main_loop_wait (nonblocking=0) at
main-loop.c:495
ret = 1
timeout = 4294967295
timeout_ns = 3965432
#15 0x55756d3f in main_loop () at vl.c:1882
nonblocking = false
Re: [Qemu-devel] qemu 2.2 crash on linux hvm domU (full backtrace included)
On Wed, 19 Nov 2014, Fabio Fantoni wrote:
Il 19/11/2014 15:56, Don Slutz ha scritto:
I think I know what is happening here. But you are pointing at the wrong
change.
commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
Is what I am guessing at this time is the issue. I think that xen_enabled()
is
returning false in pc_machine_initfn. Where as in pc_init1 is is returning
true.
I am thinking that:
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7bb97a4..3268c29 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
.desc = Xen Fully-virtualized PC,
.init = pc_xen_hvm_init,
.max_cpus = HVM_MAX_VCPUS,
-.default_machine_opts = accel=xen,
+.default_machine_opts = accel=xen,vmport=off,
.hot_add_cpu = pc_hot_add_cpu,
};
#endif
Will fix your issue. I have not tested this yet.
Tested now and it solves regression of linux hvm domUs with qemu 2.2, thanks.
I think that I'm not the only with this regression and that this patch (or a
fix to the cause in vmport) should be applied before qemu 2.2 final.
Don,
please submit a proper patch with a Signed-off-by.
Thanks!
- Stefano
-Don Slutz
On 11/19/14 09:04, Fabio Fantoni wrote:
Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
dom0 xen-unstable from staging git with x86/hvm: Extend HVM cpuid leaf
with vcpu id and x86/hvm: Add per-vcpu evtchn upcalls patches, and
qemu 2.2 from spice git (spice/next commit
e779fa0a715530311e6f59fc8adb0f6eca914a89):
https://github.com/Fantu/Xen/commits/rebase/m2r-staging
I tried with qemu tag v2.2.0-rc2 and crash still happen, here the full
backtrace of latest test:
Program received signal SIGSEGV, Segmentation fault.
0x55689b07 in vmport_ioport_read (opaque=0x564443a0, addr=0,
size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
73 eax = env-regs[R_EAX];
(gdb) bt full
#0 0x55689b07 in vmport_ioport_read (opaque=0x564443a0,
addr=0,
size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
s = 0x564443a0
cs = 0x0
cpu = 0x0
__func__ = vmport_ioport_read
env = 0x8250
command = 0 '\000'
eax = 0
#1 0x55655fc4 in memory_region_read_accessor
(mr=0x5628,
addr=0, value=0x7fffd8d0, size=4, shift=0, mask=4294967295)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
tmp = 0
#2 0x556562b7 in access_with_adjusted_size (addr=0,
value=0x7fffd8d0, size=4, access_size_min=4, access_size_max=4,
access=0x55655f62 memory_region_read_accessor,
mr=0x5628)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
access_mask = 4294967295
access_size = 4
i = 0
#3 0x556590e9 in memory_region_dispatch_read1
(mr=0x5628,
addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
data = 0
#4 0x556591b1 in memory_region_dispatch_read
(mr=0x5628,
addr=0, pval=0x7fffd9a8, size=4)
---Type return to continue, or q return to quit---
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
No locals.
#5 0x5565cbbc in io_mem_read (mr=0x5628, addr=0,
pval=0x7fffd9a8, size=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
No locals.
#6 0x5560a1ca in address_space_rw (as=0x55eaf920,
addr=22104,
buf=0x7fffda50 \377\377\377\377, len=4, is_write=false)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
l = 4
ptr = 0x55a92d87 %s/%d:\n
val = 7852232130387826944
addr1 = 0
mr = 0x5628
error = false
#7 0x5560a38f in address_space_read (as=0x55eaf920,
addr=22104,
buf=0x7fffda50 \377\377\377\377, len=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
No locals.
#8 0x5564fd4b in cpu_inl (addr=22104)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
buf = \377\377\377\377
val = 21845
#9 0x55670c73 in do_inp (addr=22104, size=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
---Type return to continue, or q return to quit---
No locals.
#10 0x55670ee0 in cpu_ioreq_pio (req=0x77ff3020)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
i = 1
#11 0x556714b3 in handle_ioreq (state=0x563c2510,
req=0x77ff3020) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
No locals.
#12 0x55671826 in cpu_handle_ioreq (opaque=0x563c2510)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
Re: [Qemu-devel] qemu 2.2 crash on linux hvm domU (full backtrace included)
I have posted the patch:
Subject: [BUGFIX][PATCH for 2.2 1/1] hw/i386/pc_piix.c: Also pass vmport=off
for xenfv machine
Date: Wed, 19 Nov 2014 12:30:57 -0500
Message-ID: 1416418257-10166-1-git-send-email-dsl...@verizon.com
Which fixes QEMU 2.2 for xenfv. However if you configure xen_platform_pci=0
you will still
have this issue. The good news is that xen-4.5 currently does not have QEMU
2.2 and so does
not have this issue.
Only people (groups like spice?) that want QEMU 2.2.0 with xen 4.5.0 (or older
xen versions)
will hit this.
I have changes to xen 4.6 which will fix the xen_platform_pci=0 case also.
In order to get xen 4.5 to fully work with QEMU 2.2.0 (both in hard freeze)
the 1st patch from Dr. David Alan Gilbert dgilb...@redhat.com
would need to be applied to xen's qemu 2.0.2 (+ changes) so that
vmport=off can be added to --machine.
And a patch (yet to be written, subset of changes I have pending for 4.6)
that adds vmport=off to QEMU args for --machine (it can be done in all cases).
-Don Slutz
On 11/19/14 10:52, Stefano Stabellini wrote:
On Wed, 19 Nov 2014, Fabio Fantoni wrote:
Il 19/11/2014 15:56, Don Slutz ha scritto:
I think I know what is happening here. But you are pointing at the wrong
change.
commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
Is what I am guessing at this time is the issue. I think that xen_enabled()
is
returning false in pc_machine_initfn. Where as in pc_init1 is is returning
true.
I am thinking that:
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7bb97a4..3268c29 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
.desc = Xen Fully-virtualized PC,
.init = pc_xen_hvm_init,
.max_cpus = HVM_MAX_VCPUS,
-.default_machine_opts = accel=xen,
+.default_machine_opts = accel=xen,vmport=off,
.hot_add_cpu = pc_hot_add_cpu,
};
#endif
Will fix your issue. I have not tested this yet.
Tested now and it solves regression of linux hvm domUs with qemu 2.2, thanks.
I think that I'm not the only with this regression and that this patch (or a
fix to the cause in vmport) should be applied before qemu 2.2 final.
Don,
please submit a proper patch with a Signed-off-by.
Thanks!
- Stefano
-Don Slutz
On 11/19/14 09:04, Fabio Fantoni wrote:
Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
dom0 xen-unstable from staging git with x86/hvm: Extend HVM cpuid leaf
with vcpu id and x86/hvm: Add per-vcpu evtchn upcalls patches, and
qemu 2.2 from spice git (spice/next commit
e779fa0a715530311e6f59fc8adb0f6eca914a89):
https://github.com/Fantu/Xen/commits/rebase/m2r-staging
I tried with qemu tag v2.2.0-rc2 and crash still happen, here the full
backtrace of latest test:
Program received signal SIGSEGV, Segmentation fault.
0x55689b07 in vmport_ioport_read (opaque=0x564443a0, addr=0,
size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
73 eax = env-regs[R_EAX];
(gdb) bt full
#0 0x55689b07 in vmport_ioport_read (opaque=0x564443a0,
addr=0,
size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
s = 0x564443a0
cs = 0x0
cpu = 0x0
__func__ = vmport_ioport_read
env = 0x8250
command = 0 '\000'
eax = 0
#1 0x55655fc4 in memory_region_read_accessor
(mr=0x5628,
addr=0, value=0x7fffd8d0, size=4, shift=0, mask=4294967295)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
tmp = 0
#2 0x556562b7 in access_with_adjusted_size (addr=0,
value=0x7fffd8d0, size=4, access_size_min=4, access_size_max=4,
access=0x55655f62 memory_region_read_accessor,
mr=0x5628)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
access_mask = 4294967295
access_size = 4
i = 0
#3 0x556590e9 in memory_region_dispatch_read1
(mr=0x5628,
addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
data = 0
#4 0x556591b1 in memory_region_dispatch_read
(mr=0x5628,
addr=0, pval=0x7fffd9a8, size=4)
---Type return to continue, or q return to quit---
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
No locals.
#5 0x5565cbbc in io_mem_read (mr=0x5628, addr=0,
pval=0x7fffd9a8, size=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
No locals.
#6 0x5560a1ca in address_space_rw (as=0x55eaf920,
addr=22104,
buf=0x7fffda50 \377\377\377\377, len=4, is_write=false)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2167
l = 4
ptr = 0x55a92d87 %s/%d:\n
val = 7852232130387826944
addr1 = 0
mr = 0x5628
error = false
#7 0x5560a38f in address_space_read (as=0x55eaf920,
addr=22104,
buf=0x7fffda50 \377\377\377\377, len=4)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2205
No locals.
Re: [Qemu-devel] qemu 2.2 crash on linux hvm domU (full backtrace included)
On Wed, 19 Nov 2014, Don Slutz wrote:
I have posted the patch:
Subject: [BUGFIX][PATCH for 2.2 1/1] hw/i386/pc_piix.c: Also pass vmport=off
for xenfv machine
Date: Wed, 19 Nov 2014 12:30:57 -0500
Message-ID: 1416418257-10166-1-git-send-email-dsl...@verizon.com
Which fixes QEMU 2.2 for xenfv. However if you configure xen_platform_pci=0
you will still
have this issue. The good news is that xen-4.5 currently does not have QEMU
2.2 and so does
not have this issue.
Only people (groups like spice?) that want QEMU 2.2.0 with xen 4.5.0 (or older
xen versions)
will hit this.
I have changes to xen 4.6 which will fix the xen_platform_pci=0 case also.
In order to get xen 4.5 to fully work with QEMU 2.2.0 (both in hard freeze)
the 1st patch from Dr. David Alan Gilbert dgilb...@redhat.com
would need to be applied to xen's qemu 2.0.2 (+ changes) so that
vmport=off can be added to --machine.
And a patch (yet to be written, subset of changes I have pending for 4.6)
that adds vmport=off to QEMU args for --machine (it can be done in all cases).
What happens if you pass vmport=off via --machine, without David Alan
Gilbert's patch in QEMU?
-Don Slutz
On 11/19/14 10:52, Stefano Stabellini wrote:
On Wed, 19 Nov 2014, Fabio Fantoni wrote:
Il 19/11/2014 15:56, Don Slutz ha scritto:
I think I know what is happening here. But you are pointing at the
wrong
change.
commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
Is what I am guessing at this time is the issue. I think that
xen_enabled()
is
returning false in pc_machine_initfn. Where as in pc_init1 is is
returning
true.
I am thinking that:
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7bb97a4..3268c29 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
.desc = Xen Fully-virtualized PC,
.init = pc_xen_hvm_init,
.max_cpus = HVM_MAX_VCPUS,
-.default_machine_opts = accel=xen,
+.default_machine_opts = accel=xen,vmport=off,
.hot_add_cpu = pc_hot_add_cpu,
};
#endif
Will fix your issue. I have not tested this yet.
Tested now and it solves regression of linux hvm domUs with qemu 2.2,
thanks.
I think that I'm not the only with this regression and that this patch (or
a
fix to the cause in vmport) should be applied before qemu 2.2 final.
Don,
please submit a proper patch with a Signed-off-by.
Thanks!
- Stefano
-Don Slutz
On 11/19/14 09:04, Fabio Fantoni wrote:
Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
dom0 xen-unstable from staging git with x86/hvm: Extend HVM cpuid
leaf
with vcpu id and x86/hvm: Add per-vcpu evtchn upcalls patches,
and
qemu 2.2 from spice git (spice/next commit
e779fa0a715530311e6f59fc8adb0f6eca914a89):
https://github.com/Fantu/Xen/commits/rebase/m2r-staging
I tried with qemu tag v2.2.0-rc2 and crash still happen, here the
full
backtrace of latest test:
Program received signal SIGSEGV, Segmentation fault.
0x55689b07 in vmport_ioport_read (opaque=0x564443a0,
addr=0,
size=4) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
73 eax = env-regs[R_EAX];
(gdb) bt full
#0 0x55689b07 in vmport_ioport_read (opaque=0x564443a0,
addr=0,
size=4) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
s = 0x564443a0
cs = 0x0
cpu = 0x0
__func__ = vmport_ioport_read
env = 0x8250
command = 0 '\000'
eax = 0
#1 0x55655fc4 in memory_region_read_accessor
(mr=0x5628,
addr=0, value=0x7fffd8d0, size=4, shift=0, mask=4294967295)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
tmp = 0
#2 0x556562b7 in access_with_adjusted_size (addr=0,
value=0x7fffd8d0, size=4, access_size_min=4,
access_size_max=4,
access=0x55655f62 memory_region_read_accessor,
mr=0x5628)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
access_mask = 4294967295
access_size = 4
i = 0
#3 0x556590e9 in memory_region_dispatch_read1
(mr=0x5628,
addr=0, size=4) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
data = 0
#4 0x556591b1 in memory_region_dispatch_read
(mr=0x5628,
addr=0, pval=0x7fffd9a8, size=4)
---Type return to continue, or q return to quit---
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
No locals.
#5 0x5565cbbc in io_mem_read (mr=0x5628,
Re: [Qemu-devel] qemu 2.2 crash on linux hvm domU (full backtrace included)
On 11/19/14 13:18, Stefano Stabellini wrote:
On Wed, 19 Nov 2014, Don Slutz wrote:
I have posted the patch:
Subject: [BUGFIX][PATCH for 2.2 1/1] hw/i386/pc_piix.c: Also pass vmport=off
for xenfv machine
Date: Wed, 19 Nov 2014 12:30:57 -0500
Message-ID: 1416418257-10166-1-git-send-email-dsl...@verizon.com
Which fixes QEMU 2.2 for xenfv. However if you configure xen_platform_pci=0
you will still
have this issue. The good news is that xen-4.5 currently does not have QEMU
2.2 and so does
not have this issue.
Only people (groups like spice?) that want QEMU 2.2.0 with xen 4.5.0 (or older
xen versions)
will hit this.
I have changes to xen 4.6 which will fix the xen_platform_pci=0 case also.
In order to get xen 4.5 to fully work with QEMU 2.2.0 (both in hard freeze)
the 1st patch from Dr. David Alan Gilbert dgilb...@redhat.com
would need to be applied to xen's qemu 2.0.2 (+ changes) so that
vmport=off can be added to --machine.
And a patch (yet to be written, subset of changes I have pending for 4.6)
that adds vmport=off to QEMU args for --machine (it can be done in all cases).
What happens if you pass vmport=off via --machine, without David Alan
Gilbert's patch in QEMU?
I am almost (99%) sure that QEMU will complain about a bad arg.
gdb says:
(gdb) r
Starting program:
/home/don/qemu/out/master/x86_64-softmmu/qemu-system-x86_64 -M pc
-machine accel=xen,vmportport=1
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
qemu-system-x86_64: -machine accel=xen,vmportport=1: Invalid parameter
'vmportport'
In which case domU will fail to start.
-Don Slutz
-Don Slutz
On 11/19/14 10:52, Stefano Stabellini wrote:
On Wed, 19 Nov 2014, Fabio Fantoni wrote:
Il 19/11/2014 15:56, Don Slutz ha scritto:
I think I know what is happening here. But you are pointing at the
wrong
change.
commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
Is what I am guessing at this time is the issue. I think that
xen_enabled()
is
returning false in pc_machine_initfn. Where as in pc_init1 is is
returning
true.
I am thinking that:
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7bb97a4..3268c29 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -914,7 +914,7 @@ static QEMUMachine xenfv_machine = {
.desc = Xen Fully-virtualized PC,
.init = pc_xen_hvm_init,
.max_cpus = HVM_MAX_VCPUS,
-.default_machine_opts = accel=xen,
+.default_machine_opts = accel=xen,vmport=off,
.hot_add_cpu = pc_hot_add_cpu,
};
#endif
Will fix your issue. I have not tested this yet.
Tested now and it solves regression of linux hvm domUs with qemu 2.2,
thanks.
I think that I'm not the only with this regression and that this patch (or
a
fix to the cause in vmport) should be applied before qemu 2.2 final.
Don,
please submit a proper patch with a Signed-off-by.
Thanks!
- Stefano
-Don Slutz
On 11/19/14 09:04, Fabio Fantoni wrote:
Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
dom0 xen-unstable from staging git with x86/hvm: Extend HVM cpuid
leaf
with vcpu id and x86/hvm: Add per-vcpu evtchn upcalls patches,
and
qemu 2.2 from spice git (spice/next commit
e779fa0a715530311e6f59fc8adb0f6eca914a89):
https://github.com/Fantu/Xen/commits/rebase/m2r-staging
I tried with qemu tag v2.2.0-rc2 and crash still happen, here the
full
backtrace of latest test:
Program received signal SIGSEGV, Segmentation fault.
0x55689b07 in vmport_ioport_read (opaque=0x564443a0,
addr=0,
size=4) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
73 eax = env-regs[R_EAX];
(gdb) bt full
#0 0x55689b07 in vmport_ioport_read (opaque=0x564443a0,
addr=0,
size=4) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
s = 0x564443a0
cs = 0x0
cpu = 0x0
__func__ = vmport_ioport_read
env = 0x8250
command = 0 '\000'
eax = 0
#1 0x55655fc4 in memory_region_read_accessor
(mr=0x5628,
addr=0, value=0x7fffd8d0, size=4, shift=0, mask=4294967295)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
tmp = 0
#2 0x556562b7 in access_with_adjusted_size (addr=0,
value=0x7fffd8d0, size=4, access_size_min=4,
access_size_max=4,
access=0x55655f62 memory_region_read_accessor,
mr=0x5628)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
access_mask = 4294967295
access_size = 4
i = 0
#3 0x556590e9 in memory_region_dispatch_read1
(mr=0x5628,
addr=0, size=4) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
data = 0
#4 0x556591b1 in memory_region_dispatch_read
(mr=0x5628,
addr=0, pval=0x7fffd9a8, size=4)
---Type return to continue, or q return to quit---
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
No locals.
#5 0x5565cbbc in io_mem_read
[Qemu-devel] qemu 2.2 crash on linux hvm domU (full backtrace included)
dom0 xen-unstable from staging git with x86/hvm: Extend HVM cpuid leaf
with vcpu id and x86/hvm: Add per-vcpu evtchn upcalls patches, and
qemu 2.2 from spice git (spice/next commit
e779fa0a715530311e6f59fc8adb0f6eca914a89):
https://github.com/Fantu/Xen/commits/rebase/m2r-staging
Qemu crash on fedora 20 lxde (with software updates of some days ago)
boot with this backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x55689607 in vmport_ioport_read (opaque=0x56440a20,
addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
73 eax = env-regs[R_EAX];
(gdb) bt full
#0 0x55689607 in vmport_ioport_read (opaque=0x56440a20,
addr=0, size=4) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/hw/misc/vmport.c:73
s = 0x56440a20
cs = 0x0
cpu = 0x0
__func__ = vmport_ioport_read
env = 0x8250
command = 0 '\000'
eax = 0
#1 0x55655b9c in memory_region_read_accessor
(mr=0x56440aa8, addr=0, value=0x7fffd8c0, size=4, shift=0,
mask=4294967295)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:410
tmp = 0
#2 0x55655e8f in access_with_adjusted_size (addr=0,
value=0x7fffd8c0, size=4, access_size_min=4, access_size_max=4,
access=0x55655b3a memory_region_read_accessor,
mr=0x56440aa8) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:480
access_mask = 4294967295
access_size = 4
i = 0
#3 0x55658cc1 in memory_region_dispatch_read1
(mr=0x56440aa8, addr=0, size=4) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1077
data = 0
#4 0x55658d89 in memory_region_dispatch_read
(mr=0x56440aa8, addr=0, pval=0x7fffd998, size=4) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1099
No locals.
#5 0x5565c794 in io_mem_read (mr=0x56440aa8, addr=0,
pval=0x7fffd998, size=4) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/memory.c:1962
No locals.
#6 0x55609fae in address_space_rw (as=0x55eae840,
addr=22104, buf=0x7fffda40 \377\377\377\377, len=4, is_write=false)
at /mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2169
l = 4
ptr = 0x0
val = 7964229952888770560
addr1 = 0
mr = 0x56440aa8
error = false
#7 0x5560a173 in address_space_read (as=0x55eae840,
addr=22104, buf=0x7fffda40 \377\377\377\377, len=4) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/exec.c:2207
No locals.
#8 0x5564fac7 in cpu_inl (addr=22104) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/ioport.c:117
buf = \377\377\377\377
val = 21845
#9 0x5567084b in do_inp (addr=22104, size=4) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:684
No locals.
#10 0x55670ab8 in cpu_ioreq_pio (req=0x77ff3000) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:747
i = 0
#11 0x5567108b in handle_ioreq (state=0x563c1590,
req=0x77ff3000) at /mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:853
---Type return to continue, or q return to quit---
No locals.
#12 0x556713fe in cpu_handle_ioreq (opaque=0x563c1590) at
/mnt/vm/xen/Xen/tools/qemu-xen-dir/xen-hvm.c:931
state = 0x563c1590
req = 0x77ff3000
#13 0x5596d874 in qemu_iohandler_poll (pollfds=0x56388a30,
ret=1) at iohandler.c:143
revents = 1
pioh = 0x563f3c90
ioh = 0x56515f80
#14 0x5596d450 in main_loop_wait (nonblocking=0) at
main-loop.c:495
ret = 1
timeout = 4294967295
timeout_ns = 3418165
#15 0x557567b7 in main_loop () at vl.c:1882
nonblocking = false
last_io = 1
#16 0x5575e4c1 in main (argc=62, argv=0x7fffe038,
envp=0x7fffe230) at vl.c:4400
i = 128
snapshot = 0
linux_boot = 0
initrd_filename = 0x0
kernel_filename = 0x0
kernel_cmdline = 0x55a485c6
boot_order = 0x563864e0 dc
ds = 0x564c71b0
cyls = 0
heads = 0
secs = 0
translation = 0
hda_opts = 0x0
opts = 0x56386430
machine_opts = 0x56388090
icount_opts = 0x0
olist = 0x55e56da0
optind = 62
optarg = 0x7fffe914
file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
loadvm = 0x0
machine_class = 0x5637c5c0
cpu_model = 0x0
vga_model = 0x0
qtest_chrdev = 0x0
---Type return to continue, or q return to quit---
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 = 0x55759e7a malloc_and_trace,
realloc = 0x55759ed2 realloc_and_trace, free = 0x55759f39
free_and_trace, calloc = 0,
try_malloc = 0, try_realloc = 0}
trace_events = 0x0
