Migration issue with hot-added dimm #1

xdel · 2013-04-05T16:52:19Z

Seems that after dimm hot-add migration is impossible:

Initial configuration follows

  <qemu:commandline>
    <qemu:arg value='-device'/>
    <qemu:arg value='dimm,id=dimm0,size=256M,node=0,populated=on,bus=membus.0'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='dimm,id=dimm1,size=256M,node=0,populated=off,bus=membus.0'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='dimm,id=dimm2,size=256M,node=0,populated=off,bus=membus.0'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='dimm,id=dimm3,size=256M,node=0,populated=off,bus=membus.0'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='dimm,id=dimm4,size=256M,node=0,populated=off,bus=membus.0'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='dimm,id=dimm5,size=256M,node=0,populated=off,bus=membus.0'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='dimm,id=dimm6,size=256M,node=0,populated=off,bus=membus.0'/>
  </qemu:commandline>

and migration works just fine. After executing

qemu-monitor-command --hmp vm010-000-001-005 device_add dimm,id=dimm1,populated=on,bus=membus.0

migration doesn`t work anymore:

Unknown ramblock "dimm1", cannot accept migration
qemu: warning: error while loading state for instance 0x0 of device 'ram'
load of migration failed

This happens on memhpv4 4a80517

The text was updated successfully, but these errors were encountered:

vliaskov · 2013-04-08T09:56:27Z

thanks for testing. This issue is known and there was a patch in memhp-v3 to solve it. But it's a bit of a hack and was removed temporarily from v4.

Please try to apply commit 55833af (HEAD of memhp-v4-fixes branch called "fix live-migration when "populated=on" is missing") and let me know if it fixes the problem for you.

vliaskov · 2013-04-08T10:01:55Z

Note 55833af may not apply cleanly to memhpv4 (memhp-v4-fixes has a slightly different header file because it updated "piix_pci and pc_piix: refactor " slightly). But it should be easy to solve. Or you could checkout memhp-v4-fixes

xdel · 2013-04-08T15:48:38Z

Unfortunately this fix does not help me, problem still persists with same error message.

xdel · 2013-04-10T11:43:59Z

By the way, piix_pci.h still missing from the current tree, which prevents proper testing by most of people, can you please add it?

vliaskov · 2013-04-10T12:03:10Z

ok, the header file was added with a separate commit on memhpv-4 HEAD.

I haven't fixed the migration issue yet, I 'll update when I have something.I assume the dimm configuration (command line) you are using on source and destination side is the same.

$ ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 -drive if=none,id=drive0,cache=none,aio=native,format=raw,file=/root/Image/centos-6.4.raw -device virtio-blk-pci,drive=drive0,scsi=off,x-data-plane=on,config-wce=on # make dataplane fail to initialize qemu-system-x86_64: -device virtio-blk-pci,drive=drive0,scsi=off,x-data-plane=on,config-wce=on: device is incompatible with x-data-plane, use config-wce=off *** glibc detected *** /root/usr/bin/qemu-system-x86_64: free(): invalid pointer: 0x00007f001fef12f8 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x7d776)[0x7f00153a5776] /root/usr/bin/qemu-system-x86_64(+0x2c34ec)[0x7f001cf5b4ec] /root/usr/bin/qemu-system-x86_64(+0x342f9a)[0x7f001cfdaf9a] /root/usr/bin/qemu-system-x86_64(+0x33694e)[0x7f001cfce94e] .................... (gdb) bt #0 0x00007f3bf3a12015 in raise () from /lib64/libc.so.6 #1 0x00007f3bf3a1348b in abort () from /lib64/libc.so.6 #2 0x00007f3bf3a51a4e in __libc_message () from /lib64/libc.so.6 #3 0x00007f3bf3a57776 in malloc_printerr () from /lib64/libc.so.6 #4 0x00007f3bfb60d4ec in free_and_trace (mem=0x7f3bfe0129f8) at vl.c:2786 #5 0x00007f3bfb68cf9a in virtio_cleanup (vdev=0x7f3bfe0129f8) at /root/Develop/QEMU/qemu/hw/virtio.c:900 #6 0x00007f3bfb68094e in virtio_blk_device_init (vdev=0x7f3bfe0129f8) at /root/Develop/QEMU/qemu/hw/virtio-blk.c:666 #7 0x00007f3bfb68dadf in virtio_device_init (qdev=0x7f3bfe0129f8) at /root/Develop/QEMU/qemu/hw/virtio.c:1092 #8 0x00007f3bfb50da46 in device_realize (dev=0x7f3bfe0129f8, err=0x7fff479c9258) at hw/qdev.c:176 ............................. In virtio_blk_device_init(), the memory which vdev point to is a static member of "struct VirtIOBlkPCI", not heap memory, and it does not get freed. So we shoule use virtio_common_cleanup() to clean this VirtIODevice rather than virtio_cleanup(), which attempts to free the vdev. This error was introduced by commit 05ff686 recently. Signed-off-by: Dunrong Huang <[email protected]> Signed-off-by: Kevin Wolf <[email protected]>

Use of a flash memory device for the BIOS was added in series "[PATCH v10 0/8] PC system flash support", commit 4732dca..1b89faf, v1.1. Flash vs. ROM is a guest-visible difference. Thus, flash use had to be suppressed for machine types pc-1.0 and older. This was accomplished by adding a dummy device "pc-sysfw" with property "rom_only": * Non-zero rom_only means "use ROM". Default for pc-1.0 and older. * Zero rom_only means "maybe use flash". Default for newer machines. Not only is the dummy device ugly, it was also retroactively added to the older machine types! Fortunately, it's not guest-visible (thus no immediate guest ABI breakage), and has no vmstate (thus no immediate migration breakage). Breakage occurs only if the user unwisely enables flash by setting rom_only to zero. Patch review FAIL #1. Why "maybe use flash"? Flash didn't (and still doesn't) work with KVM. Therefore, rom_only=0 really means "use flash, except when KVM is enabled, use ROM". This is a Bad Idea, because it makes enabling/ disabling KVM guest-visible. Patch review FAIL #2. Aside: it also precludes migrating between KVM on and off, but that's not possible for other reasons anyway. Fix as follows: 1. Change the meaning of rom_only=0 to mean "use flash, no ifs, buts, or maybes" for pc-i440fx-1.5 and pc-q35-1.5. Don't change anything for older machines (to remain bug-compatible). 2. Change the default value from 0 to 1 for these machines. Necessary, because 0 doesn't work with KVM. Once it does, we can flip the default back to 0. 3. Don't revert the retroactive addition of device "pc-sysfw" to older machine types. Seems not worth the trouble. 4. Add a TODO comment asking for device "pc-sysfw" to be dropped once flash works with KVM. Net effect is that you get a BIOS ROM again even when KVM is disabled, just like for machines predating the introduction of flash. To get flash instead, use "--global pc-sysfw.rom_only=0". Signed-off-by: Markus Armbruster <[email protected]> Message-id: [email protected] Signed-off-by: Anthony Liguori <[email protected]>

When qemu dies unexpectedly, for example in response to an explicit abort() call, or (more importantly) when an external signal is delivered to it that results in a coredump, sometimes it is useful to extract the guest vmcore from the qemu process' memory image. The guest vmcore might help understand an emulation problem in qemu, or help debug the guest. This script reimplements (and cuts many features of) the qmp_dump_guest_memory() command in gdb/Python, https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html working off the saved memory image of the qemu process. The docstring in the patch (serving as gdb help text) describes the limitations relative to the QMP command. Dependencies of qmp_dump_guest_memory() have been reimplemented as needed. I sought to follow the general structure, sticking to original function names where possible. However, keeping it simple prevailed in some places. The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4 (2.6.32-358.el6.x86_64) guest: - The script printed > guest RAM blocks: > target_start target_end host_addr message count > ---------------- ---------------- ---------------- ------- ----- > 0000000000000000 00000000000a0000 00007f95d0000000 added 1 > 00000000000a0000 00000000000b0000 00007f960ac00000 added 2 > 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3 > 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3 > 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3 > 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3 > 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3 > 0000000000100000 0000000030000000 00007f95d0100000 joined 3 > 00000000fc000000 00000000fc800000 00007f960ac00000 added 4 > 00000000fffe0000 0000000100000000 00007f9618800000 added 5 > dumping range at 00007f95d0000000 for length 00000000000a0000 > dumping range at 00007f960ac00000 for length 0000000000010000 > dumping range at 00007f95d00c0000 for length 000000002ff40000 > dumping range at 00007f960ac00000 for length 0000000000800000 > dumping range at 00007f9618800000 for length 0000000000020000 - The vmcore was checked with "readelf", comparing the results against a vmcore written by qmp_dump_guest_memory(): > --- theirs 2013-09-12 17:38:59.797289404 +0200 > +++ mine 2013-09-12 17:39:03.820289404 +0200 > @@ -27,16 +27,16 @@ > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000 > - 0x0000000000000ca0 0x0000000000000ca0 0 > - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000 > + 0x000000000000001c 0x000000000000001c 0 > + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000 > 0x00000000000a0000 0x00000000000a0000 0 > - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000 > + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000 > 0x0000000000010000 0x0000000000010000 0 > - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000 > + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000 > 0x000000002ff40000 0x000000002ff40000 0 > - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000 > + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000 > 0x0000000000800000 0x0000000000800000 0 > - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000 > + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000 > 0x0000000000020000 0x0000000000020000 0 > > There is no dynamic section in this file. > @@ -47,13 +47,6 @@ > > No version information found in this file. > > -Notes at offset 0x00000190 with length 0x00000ca0: > +Notes at offset 0x00000190 with length 0x0000001c: > Owner Data size Description > - CORE 0x00000150 NT_PRSTATUS (prstatus structure) > - CORE 0x00000150 NT_PRSTATUS (prstatus structure) > - CORE 0x00000150 NT_PRSTATUS (prstatus structure) > - CORE 0x00000150 NT_PRSTATUS (prstatus structure) > - QEMU 0x000001b0 Unknown note type: (0x00000000) > - QEMU 0x000001b0 Unknown note type: (0x00000000) > - QEMU 0x000001b0 Unknown note type: (0x00000000) > - QEMU 0x000001b0 Unknown note type: (0x00000000) > + NONE 0x00000005 Unknown note type: (0x00000000) - The vmcore was checked with "crash" too, again comparing the results against a vmcore written by qmp_dump_guest_memory(): > --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200 > +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200 > @@ -22,11 +22,11 @@ > This GDB was configured as "x86_64-unknown-linux-gnu"... > > KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux > - DUMPFILE: /home/lacos/tmp/guest.vmcore > + DUMPFILE: /home/lacos/tmp/example.dump > CPUS: 4 > - DATE: Thu Sep 12 17:16:11 2013 > - UPTIME: 00:01:09 > -LOAD AVERAGE: 0.07, 0.03, 0.00 > + DATE: Thu Sep 12 17:17:41 2013 > + UPTIME: 00:00:38 > +LOAD AVERAGE: 0.18, 0.05, 0.01 > TASKS: 130 > NODENAME: localhost.localdomain > RELEASE: 2.6.32-358.el6.x86_64 > @@ -38,12 +38,12 @@ > COMMAND: "swapper" > TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000] > CPU: 0 > - STATE: TASK_RUNNING (PANIC) > + STATE: TASK_RUNNING (ACTIVE) > + WARNING: panic task not found > > crash> bt > PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper" > - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d > - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6 > + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6 > crash> task ffffffff81a8d020 > PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper" > struct task_struct { > @@ -75,7 +75,7 @@ > prev = 0xffffffff81a8d080 > }, > on_rq = 0, > - exec_start = 8618466836, > + exec_start = 7469214014, > sum_exec_runtime = 0, > vruntime = 0, > prev_sum_exec_runtime = 0, > @@ -149,7 +149,7 @@ > }, > tasks = { > next = 0xffff88002d621948, > - prev = 0xffff880029618f28 > + prev = 0xffff880023b74488 > }, > pushable_tasks = { > prio = 140, > @@ -165,7 +165,7 @@ > } > }, > mm = 0x0, > - active_mm = 0xffff88002929b780, > + active_mm = 0xffff8800297eb980, > exit_state = 0, > exit_code = 0, > exit_signal = 0, > @@ -177,7 +177,7 @@ > sched_reset_on_fork = 0, > pid = 0, > tgid = 0, > - stack_canary = 2483693585637059287, > + stack_canary = 7266362296181431986, > real_parent = 0xffffffff81a8d020, > parent = 0xffffffff81a8d020, > children = { > @@ -224,14 +224,14 @@ > set_child_tid = 0x0, > clear_child_tid = 0x0, > utime = 0, > - stime = 3, > + stime = 2, > utimescaled = 0, > - stimescaled = 3, > + stimescaled = 2, > gtime = 0, > prev_utime = 0, > prev_stime = 0, > nvcsw = 0, > - nivcsw = 1000, > + nivcsw = 1764, > start_time = { > tv_sec = 0, > tv_nsec = 0 - <name_dropping>I asked for Dave Anderson's help with verifying the extracted vmcore, and his comments make me think I should post this.</name_dropping> Signed-off-by: Laszlo Ersek <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>

The trace-events "disable" keyword turns an event into a nop at compile-time. This is important for high-frequency events that can impact performance. The "disable" keyword is currently broken in the simple trace backend. This patch fixes the problem as follows: Trace events are identified by their TraceEventID number. When events are disabled there are two options for assigning TraceEventID numbers: 1. Skip disabled events and don't assign them a number. 2. Assign numbers for all events regardless of the disabled keyword. The simple trace backend and its binary file format uses approach #1. The tracetool infrastructure has been using approach #2 for a while. The result is that the numbers used in simple trace files do not correspond with TraceEventIDs. In trace/simple.c we assumed that they are identical and therefore emitted bogus numbers. This patch fixes the bug by using TraceEventID for trace_event_id() while sticking to approach #1 for simple trace file numbers. This preserves simple trace file format compatibility. Signed-off-by: Stefan Hajnoczi <[email protected]>

There are currently three types of object_property_add_link() callers: 1. The link property may be set at any time. 2. The link property of a DeviceState instance may only be set before realize. 3. The link property may never be set, it is read-only. Something similar can already be achieved with object_property_add_str()'s set() argument. Follow its example and add a check() argument to object_property_add_link(). Also provide default check() functions for case #1 and #2. Case #3 is covered by passing a NULL function pointer. Cc: Peter Crosthwaite <[email protected]> Cc: Alexander Graf <[email protected]> Cc: Anthony Liguori <[email protected]> Cc: "Michael S. Tsirkin" <[email protected]> Signed-off-by: Stefan Hajnoczi <[email protected]> Reviewed-by: Paolo Bonzini <[email protected]> [AF: Tweaked documentation comment] Signed-off-by: Andreas Färber <[email protected]>

The docs for glfs_init suggest that the function sets errno on every failure. In fact it doesn't. As other functions such as qemu_gluster_open() in the gluster block code report their errors based on this fact we need to make sure that errno is set on each failure. This fixes a crash of qemu-img/qemu when a gluster brick isn't accessible from given host while the server serving the volume description is. Thread 1 (Thread 0x7ffff7fba740 (LWP 203880)): #0 0x00007ffff77673f8 in glfs_lseek () from /usr/lib64/libgfapi.so.0 #1 0x0000555555574a68 in qemu_gluster_getlength () #2 0x0000555555565742 in refresh_total_sectors () #3 0x000055555556914f in bdrv_open_common () #4 0x000055555556e8e8 in bdrv_open () #5 0x000055555556f02f in bdrv_open_image () #6 0x000055555556e5f6 in bdrv_open () #7 0x00005555555c5775 in bdrv_new_open () #8 0x00005555555c5b91 in img_info () #9 0x00007ffff62c9c05 in __libc_start_main () from /lib64/libc.so.6 #10 0x00005555555648ad in _start () Signed-off-by: Stefan Hajnoczi <[email protected]>

If libusb_get_device_list() fails, the uninitialized local variable libusb_device would be passed to libusb_free_device_list(), that will cause a crash, like: (gdb) bt #0 0x00007fbbb4bafc10 in pthread_mutex_lock () from /lib64/libpthread.so.0 #1 0x00007fbbb233e653 in libusb_unref_device (dev=0x6275682d627375) at core.c:902 #2 0x00007fbbb233e739 in libusb_free_device_list (list=0x7fbbb6e8436e, unref_devices=<optimized out>) at core.c:653 #3 0x00007fbbb6cd80a4 in usb_host_auto_check (unused=unused@entry=0x0) at hw/usb/host-libusb.c:1446 #4 0x00007fbbb6cd8525 in usb_host_initfn (udev=0x7fbbbd3c5670) at hw/usb/host-libusb.c:912 #5 0x00007fbbb6cc123b in usb_device_init (dev=0x7fbbbd3c5670) at hw/usb/bus.c:106 ... So initialize libusb_device at the begin time. Signed-off-by: Jincheng Miao <[email protected]> Reviewed-by: Gonglei <[email protected]> Signed-off-by: Gerd Hoffmann <[email protected]>

VirtIOBlockReq is freed later by virtio_blk_free_request() in hw/block/virtio-blk.c. Remove this extraneous g_slice_free(). This patch fixes the following segfault: 0x00005555556373af in virtio_blk_rw_complete (opaque=0x5555565ff5e0, ret=0) at hw/block/virtio-blk.c:99 99 bdrv_acct_done(req->dev->bs, &req->acct); (gdb) print req $1 = (VirtIOBlockReq *) 0x5555565ff5e0 (gdb) print req->dev $2 = (VirtIOBlock *) 0x0 (gdb) bt #0 0x00005555556373af in virtio_blk_rw_complete (opaque=0x5555565ff5e0, ret=0) at hw/block/virtio-blk.c:99 #1 0x0000555555840ebe in bdrv_co_em_bh (opaque=0x5555566152d0) at block.c:4675 #2 0x000055555583de77 in aio_bh_poll (ctx=ctx@entry=0x5555563a8150) at async.c:81 #3 0x000055555584b7a7 in aio_poll (ctx=0x5555563a8150, blocking=blocking@entry=true) at aio-posix.c:188 #4 0x00005555556e520e in iothread_run (opaque=0x5555563a7fd8) at iothread.c:41 #5 0x00007ffff42ba124 in start_thread () from /usr/lib/libpthread.so.0 #6 0x00007ffff16d14bd in clone () from /usr/lib/libc.so.6 Reported-by: Max Reitz <[email protected]> Cc: Fam Zheng <[email protected]> Signed-off-by: Stefan Hajnoczi <[email protected]> Tested-by: Christian Borntraeger <[email protected]> Signed-off-by: Kevin Wolf <[email protected]>

Xorg server hangs when using xfig and typing a text with space: #0 qxl_wait_for_io_command (qxl=<value optimized out>) at qxl_io.c:47 #1 0x00007f826a49a299 in qxl_download_box (surface=0x221d030, x1=231, y1=259, x2=<value optimized out>, y2=<value optimized out>) at qxl_surface.c:143 while (!(ram_header->int_pending & QXL_INTERRUPT_IO_CMD)) usleep (1); The QXL driver is calling QXL_IO_UPDATE_AREA with an empty area. This is a guest bug. The call is async and no ack is sent back on guest bug, so the X server will hang. The driver should be improved to avoid this situation and also to abort on QXL_INTERRUPT_ERROR. This will be a different patch series for the driver. However, it is simple enough to keep qemu running on empty areas update, which is what this patch provides. https://bugzilla.redhat.com/show_bug.cgi?id=1151363 Signed-off-by: Gerd Hoffmann <[email protected]>

It seems "name" is not mandatory, and the following command line (based on one generated by current libvirt) will crash qemu at start: qemu-system-x86_64 \ -device virtio-serial-pci \ -device virtserialport,name=foo \ -device virtconsole Program received signal SIGSEGV, Segmentation fault. __strcmp_ssse3 () at ../sysdeps/x86_64/strcmp.S:210 210 movlpd (%rsi), %xmm2 Missing separate debuginfos, use: debuginfo-install python-libs-2.7.5-13.fc20.x86_64 (gdb) bt #0 __strcmp_ssse3 () at ../sysdeps/x86_64/strcmp.S:210 #1 0x000055555566bdc6 in find_port_by_name (name=0x0) at /home/elmarco/src/qemu/hw/char/virtio-serial-bus.c:67 Signed-off-by: Marc-André Lureau <[email protected]> Reviewed-by: Amos Kong <[email protected]> Signed-off-by: Amit Shah <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Migration issue with hot-added dimm #1

Migration issue with hot-added dimm #1

xdel commented Apr 5, 2013

vliaskov commented Apr 8, 2013

vliaskov commented Apr 8, 2013

xdel commented Apr 8, 2013

xdel commented Apr 10, 2013

vliaskov commented Apr 10, 2013

Migration issue with hot-added dimm #1

Migration issue with hot-added dimm #1

Comments

xdel commented Apr 5, 2013

vliaskov commented Apr 8, 2013

vliaskov commented Apr 8, 2013

xdel commented Apr 8, 2013

xdel commented Apr 10, 2013

vliaskov commented Apr 10, 2013