[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 ,
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 to continue, or q 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 to continue, or q 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 ,
realloc = 0x55759ed2 , free = 0x55759f39
, calloc = 0,
try_malloc = 0, try_realloc = 0}
trace_events = 0x0
trace_file = 0x0
default_ram_size = 134217728
maxram_size
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 ,
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 to continue, or q 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 to continue, or q 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 to continue, or q 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 to continue, or q 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 = 0x5575a402 ,
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 ,
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 to continue, or q 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 to continue, or q 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 to continue, or q to quit---
i = 128
snapshot = 0
linux_boot = 0
initrd_filename = 0x0
kernel_filename = 0x0
kernel_cmdline = 0x55a48f86
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 ,
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 to continue, or q 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 to continue, or q 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
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 ,
> > > > 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 to continue, or q 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 to continue, or q to quit---
> > > > No locals.
> > > > #10 0x55670ee0 in cpu_ioreq_pio (req=0x77ff3020)
> > > > at /mnt/vm/xen/Xen/tools/qemu-
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 "
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 ,
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 to continue, or q 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 (ad
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 "
> 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 ,
> > > > > > 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,
> > >
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 "
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 ,
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 to continue, or q 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, siz
