sync version of snapsho_blkdev (hmp) #2

mitake · 2012-09-19T10:22:22Z

No description provided.

$ ~/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 qemu#4 0x00007f3bfb60d4ec in free_and_trace (mem=0x7f3bfe0129f8) at vl.c:2786 qemu#5 0x00007f3bfb68cf9a in virtio_cleanup (vdev=0x7f3bfe0129f8) at /root/Develop/QEMU/qemu/hw/virtio.c:900 qemu#6 0x00007f3bfb68094e in virtio_blk_device_init (vdev=0x7f3bfe0129f8) at /root/Develop/QEMU/qemu/hw/virtio-blk.c:666 qemu#7 0x00007f3bfb68dadf in virtio_device_init (qdev=0x7f3bfe0129f8) at /root/Develop/QEMU/qemu/hw/virtio.c:1092 qemu#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 <huangdr@cloud-times.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>

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 <armbru@redhat.com> Message-id: 1365780303-26398-4-git-send-email-armbru@redhat.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Fix the CBAR initialisation by using the newly defined static property. CBAR is now set before realization, so the intended value is now actually used. So I have kind of tested this. I booted an ARM kernel on Highbank with the stock Highbank DTB. It doesn't boot (and I will be doing something wrong), but before this patch I got this: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at /workspaces/pcrost/public/linux2.git/arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0x180/0x198() CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.13.0-rc1-next-20131126-dirty #2 [<c0015164>] (unwind_backtrace) from [<c00118c0>] (show_stack+0x10/0x14) [<c00118c0>] (show_stack) from [<c02bd5fc>] (dump_stack+0x78/0x90) [<c02bd5fc>] (dump_stack) from [<c001f110>] (warn_slowpath_common+0x68/0x84) [<c001f110>] (warn_slowpath_common) from [<c001f1f4>] (warn_slowpath_null+0x1c/0x24) [<c001f1f4>] (warn_slowpath_null) from [<c0017c6c>] (__arm_ioremap_pfn_caller+0x180/0x198) [<c0017c6c>] (__arm_ioremap_pfn_caller) from [<c0017cd8>] (__arm_ioremap_caller+0x54/0x5c) [<c0017cd8>] (__arm_ioremap_caller) from [<c0017d10>] (__arm_ioremap+0x18/0x1c) [<c0017d10>] (__arm_ioremap) from [<c03913c0>] (highbank_init_irq+0x34/0x8c) [<c03913c0>] (highbank_init_irq) from [<c038c228>] (init_IRQ+0x28/0x2c) [<c038c228>] (init_IRQ) from [<c03899ec>] (start_kernel+0x234/0x398) [<c03899ec>] (start_kernel) from [<00008074>] (0x8074) ---[ end trace 3406ff24bd97382f ]--- Which disappears with this patch. Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: fedec366aaa512d75093635f523d1dbcb3358361.1387160489.git.peter.crosthwaite@xilinx.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

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 <stefanha@redhat.com>

As reported in http://article.gmane.org/gmane.comp.emulators.qemu/253987 Mac OSX actually requires describing all occupied slots in ACPI - even if hotplug isn't enabled. I didn't expect this so I dropped description of all non hotpluggable slots from ACPI. As a result: before commit 99fd437 (enable hotplug for pci bridges), PCI cards show up in the "device tree" of OS X (System Information). E.g., on MountainLion users have: Hardware -> PCI Cards: Card Type Driver Installed Slot *ethernet Ethernet Controller Yes PCI Slot 2 pci8086,2934 USB UHC Yes PCI Slot 29 ethernet: Type: Ethernet Controller Driver Installed: Yes MSI: No Bus: PCI Slot PCI Slot 2 Vendor ID: 0x8086 Device ID: 0x100e Subsystem Vendor ID: 0x1af4 Subsystem ID: 0x1100 Revision ID: 0x0003 Hardware -> Ethernet Cards ethernet: Type: Ethernet Controller Bus: PCI Slot PCI Slot 2 Vendor ID: 0x8086 Device ID: 0x100e Subsystem Vendor ID: 0x1af4 Subsystem ID: 0x1100 Revision ID: 0x0003 BSD name: en0 Kext name: AppleIntel8254XEthernet.kext Location: /System/Library/Extensions/... Version: 3.1.1b1 After commit 99fd437, users get: Hardware -> PCI Cards: This computer doesn't contain any PCI cards. If you installed PCI cards, make sure they're properly installed. Hardware -> Ethernet Cards ethernet: Type: Ethernet Controller Bus: PCI Vendor ID: 0x8086 Device ID: 0x100e Subsystem Vendor ID: 0x1af4 Subsystem ID: 0x1100 Revision ID: 0x0003 BSD name: en0 Kext name: AppleIntel8254XEthernet.kext Location: /System/Library/Extensions/... Version: 3.1.1b1 Ethernet still works, but it's not showing up on the PCI bus, and it no longer thinks it's plugged in to slot #2, as it used to before the change. To fix, append description for all occupied non hotpluggable PCI slots. One need to be careful when doing this: VGA devices are now described in SSDT, so we need to drop description from DSDT. And ISA devices are used in DSDT so drop them from SSDT. Reported-by: Gabriel L. Somlo <gsomlo@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Also update generated dsdt and pcihp hex dump files. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

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 <peter.crosthwaite@petalogix.com> Cc: Alexander Graf <agraf@suse.de> Cc: Anthony Liguori <aliguori@amazon.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> [AF: Tweaked documentation comment] Signed-off-by: Andreas Färber <afaerber@suse.de>

Otherwise, the index of an input device like a usb-kbd is silently accepted. (qemu) info mice Mouse #2: QEMU PS/2 Mouse * Mouse #3: QEMU HID Mouse (qemu) mouse_set 1 (qemu) info mice Mouse #2: QEMU PS/2 Mouse * Mouse #3: QEMU HID Mouse Also replace monitor_printf() call in do_mouse_set() with error_report() and adjust error message. Signed-off-by: Hani Benhabiles <hani@linux.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

A few more cleanups for .gitignore file. The final goal is to have only files in there which are generated during build. Things like .orig or .gdbinit are definitely not generated during build. Also, anchor a few more build-time directories. Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

…4-28' into staging trivial patches for 2014-04-28 # gpg: Signature made Mon 28 Apr 2014 05:56:01 BST using RSA key ID A4C3D7DB # gpg: Good signature from "Michael Tokarev <mjt@tls.msk.ru>" # gpg: aka "Michael Tokarev <mjt@corpit.ru>" # gpg: aka "Michael Tokarev <mjt@debian.org>" # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 # Subkey fingerprint: 6F67 E18E 7C91 C5B1 5514 66A7 BEE5 9D74 A4C3 D7DB * remotes/mjt/tags/trivial-patches-2014-04-28: slirp/smb: Move ncalrpc directory to tmp po: add proper Language: tags to .po files po/Makefile: fix $SRC_PATH reference init_paths: fix minor memory leak virtfs-proxy-helper: fix call to accept net/net.c: remove unnecessary semicolon Add QEMU logo (SVG file) vl: avoid closing stdout with 'writeconfig' xilinx: Fix typo in comment (Marvel -> Marvell) vl: Eliminate a superfluous local variable vl: Remove useless 'continue' gitignore: cleanups #2 tests/.gitignore: Ignore test-rfifolock move test-* from .gitignore to tests/.gitignore configure: Improve help behavior vl: convert -m to QemuOpts qemu-option: introduce qemu_find_opts_singleton misc: Use cpu_physical_memory_read and cpu_physical_memory_write Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

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 () qemu#4 0x000055555556e8e8 in bdrv_open () qemu#5 0x000055555556f02f in bdrv_open_image () qemu#6 0x000055555556e5f6 in bdrv_open () qemu#7 0x00005555555c5775 in bdrv_new_open () qemu#8 0x00005555555c5b91 in img_info () qemu#9 0x00007ffff62c9c05 in __libc_start_main () from /lib64/libc.so.6 qemu#10 0x00005555555648ad in _start () Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

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 qemu#4 0x00007fbbb6cd8525 in usb_host_initfn (udev=0x7fbbbd3c5670) at hw/usb/host-libusb.c:912 qemu#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 <jmiao@redhat.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

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 qemu#4 0x00005555556e520e in iothread_run (opaque=0x5555563a7fd8) at iothread.c:41 qemu#5 0x00007ffff42ba124 in start_thread () from /usr/lib/libpthread.so.0 qemu#6 0x00007ffff16d14bd in clone () from /usr/lib/libc.so.6 Reported-by: Max Reitz <mreitz@redhat.com> Cc: Fam Zheng <famz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

sync version of snapsho_blkdev (hmp) #2

sync version of snapsho_blkdev (hmp) #2

mitake commented Sep 19, 2012

sync version of snapsho_blkdev (hmp) #2

sync version of snapsho_blkdev (hmp) #2

Comments

mitake commented Sep 19, 2012