[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 226475: scsi: give device a parent before set
From: |
GitHub |
Subject: |
[Qemu-commits] [qemu/qemu] 226475: scsi: give device a parent before setting properti... |
Date: |
Tue, 03 Mar 2015 05:30:08 -0800 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: 2264750483107c45877d29813c497b4c87f64cb6
https://github.com/qemu/qemu/commit/2264750483107c45877d29813c497b4c87f64cb6
Author: Paolo Bonzini <address@hidden>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M hw/scsi/scsi-bus.c
Log Message:
-----------
scsi: give device a parent before setting properties
This mimics what is done in qdev_device_add, and lets the device be
freed in case something goes wrong. Otherwise, object_unparent returns
immediately without freeing the device, which is on the other hand left
in the parent bus's list of children.
scsi_bus_legacy_handle_cmdline then returns an error, and the HBA is
destroyed as well with object_unparent. But the lingering device that
was not removed in scsi_bus_legacy_add_drive cannot be removed now either,
and bus_unparent gets stuck in an infinite loop trying to empty the list
of children.
The right fix of course would be to assert in bus_add_child that the
device already has a bus, and remove the "safety net" that adds the
drive to the QOM tree in device_set_realized. I am not yet sure whether
that would entail changing all callers to qdev_create (as well as
isa_create and usb_create and the corresponding _try_create versions).
Reported-by: Markus Armbruster <address@hidden>
Tested-by: Markus Armbruster <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Commit: 2e5b887cfc69991eee27be6cc0938c70a360fe45
https://github.com/qemu/qemu/commit/2e5b887cfc69991eee27be6cc0938c70a360fe45
Author: Fam Zheng <address@hidden>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M include/block/block.h
Log Message:
-----------
block: Forbid bdrv_set_aio_context outside BQL
Even if the caller has both the old and the new AioContext's, there can
be a deadlock, due to the leading bdrv_drain_all.
Suppose there are four io threads (A, B, A0, B0) with A and B owning a
BDS for each (bs_a, bs_b); Now A wants to move bs_a to iothread A0, and
B wants to move bs_b to B0, at the same time:
iothread A iothread B
--------------------------------------------------------------------------
aio_context_acquire(A0) /* OK */ aio_context_acquire(B0) /* OK */
bdrv_set_aio_context(bs_a, A0) bdrv_set_aio_context(bs_b, B0)
-> bdrv_drain_all() -> bdrv_drain_all()
-> acquire A /* OK */ -> acquire A /* blocked */
-> acquire B /* blocked */ -> acquire B
... ...
Deadlock happens because A is waiting for B, and B is waiting for A.
Signed-off-by: Fam Zheng <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Commit: 0543055967e554b5be10c3f96c077bf26dcaf181
https://github.com/qemu/qemu/commit/0543055967e554b5be10c3f96c077bf26dcaf181
Author: Fam Zheng <address@hidden>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M hw/scsi/virtio-scsi.c
Log Message:
-----------
virtio-scsi-dataplane: Call blk_set_aio_context within BQL
It's not safe to call blk_set_aio_context from outside BQL because of
the bdrv_drain_all there. Let's put it in the hotplug callback which
will be called by qdev device realization for each scsi device attached
to the bus.
Signed-off-by: Fam Zheng <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Commit: 2ed1ebcf65edf6757d8904000889ce52cc0a9d1b
https://github.com/qemu/qemu/commit/2ed1ebcf65edf6757d8904000889ce52cc0a9d1b
Author: Pavel Dovgalyuk <address@hidden>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M vl.c
Log Message:
-----------
timer: replace time() with QEMU_CLOCK_HOST
This patch replaces time() function calls with calls to
qemu_clock_get_ns(QEMU_CLOCK_HOST). It makes such requests deterministic
in record/replay mode of icount.
Reviewed-by: Paolo Bonzini <address@hidden>
Signed-off-by: Pavel Dovgalyuk <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Commit: 57fe6a6e4a050f639ac3d2f7c32b4cd3bcde3978
https://github.com/qemu/qemu/commit/57fe6a6e4a050f639ac3d2f7c32b4cd3bcde3978
Author: Gonglei <address@hidden>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M bootdevice.c
Log Message:
-----------
bootdevice: fix segment fault when booting guest with '-kernel' and '-initrd'
Reproducer:
$./qemu-system-x86_64 --enable-kvm -kernel /home/vmlinuz-2.6.32.12-0.7-default
\
-initrd /home/initrd-2.6.32.12-0.7-default -append \
"root=/dev/ram rw console=ttyS0,115200" -dtb guest.dtb -vnc :10 --monitor
stdio -smp 2
QEMU 2.2.50 monitor - type 'help' for more information
(qemu) Segmentation fault (core dumped)
Reported-by: Edivaldo de Araujo Pereira <address@hidden>
Signed-off-by: Gonglei <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Commit: 4681867544f04f752bd98f39c3055493c80ea316
https://github.com/qemu/qemu/commit/4681867544f04f752bd98f39c3055493c80ea316
Author: David Gibson <address@hidden>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M default-configs/arm-softmmu.mak
M default-configs/i386-softmmu.mak
M default-configs/x86_64-softmmu.mak
M hw/pci-bridge/Makefile.objs
Log Message:
-----------
Add specific config options for PCI-E bridges
The i82801b11, ioh3420 and xio3130 PCI Express devices are currently
included in the build unconditionally.
While they could theoretically appear on any target platform with PCI-E,
they're pretty unlikely to appear on platforms that aren't Intel derived.
Therefore, to avoid presenting unlikely-to-be-relevant devices to the user,
add config options to enable these components, and enable them by default
only on x86 and arm platforms.
(Note that this patch does include these for aarch64, via its inclusion of
arm-softmmu.mak).
Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Peter Crosthwaite <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Commit: 2296594257d11a253d12f0219eef3f1a0201c2d9
https://github.com/qemu/qemu/commit/2296594257d11a253d12f0219eef3f1a0201c2d9
Author: David Gibson <address@hidden>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M default-configs/arm-softmmu.mak
M default-configs/ppc-softmmu.mak
M default-configs/ppc64-softmmu.mak
M hw/core/Makefile.objs
Log Message:
-----------
Create specific config option for "platform-bus"
Currently the "platform-bus" device is included for all softmmu builds.
This bridge is intended for use on any platforms that require dynamic
creation of sysbus devices. However, at present it is used only for the
PPC E500 target, with plans for the ARM "virt" target in the immediate
future.
To avoid a not-very-useful entry appearing in "qemu -device ?" output on
other targets, this patch makes a specific config option for platform-bus
and enables it (for now) only on ppc configurations which include E500
and on ARM (which always includes the "virt" target).
Signed-off-by: David Gibson <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Commit: 8af738b3eecf69a795c6ff78121edbb81ab03684
https://github.com/qemu/qemu/commit/8af738b3eecf69a795c6ff78121edbb81ab03684
Author: David Gibson <address@hidden>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M default-configs/pci.mak
M hw/misc/Makefile.objs
Log Message:
-----------
Give ivshmem its own config option
Currently the ivshmem device is built whenever both PCI and KVM support are
included. This patch gives it its own config option to allow easier
customization of whether to include it. It's enabled by default in the
same circumstances as now - when both PCI and KVM are available.
Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Peter Crosthwaite <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Commit: 43ae8fb10c5f6ca78f242624c1f446e0050a9d43
https://github.com/qemu/qemu/commit/43ae8fb10c5f6ca78f242624c1f446e0050a9d43
Author: Fam Zheng <address@hidden>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M block/iscsi.c
Log Message:
-----------
iscsi: Handle write protected case in reopen
Save the write protected flag and check before reopen.
Signed-off-by: Fam Zheng <address@hidden>
Message-Id: <address@hidden>
[Fixed typo in the name of the new field. - Paolo]
Signed-off-by: Paolo Bonzini <address@hidden>
Commit: 23cab7b7a9cb365b15eee953a0dd6cdb9198ae6c
https://github.com/qemu/qemu/commit/23cab7b7a9cb365b15eee953a0dd6cdb9198ae6c
Author: Vasily Efimov <address@hidden>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Makefile
Log Message:
-----------
Makefile: fix up parallel building under MSYS+MinGW
This patch enables parallel building of QEMU in MSYS+MinGW environment.
Currently an attempt to build QEMU in parallel fails on generation of
version.lo (and version.o too).
The cause of the failure is that when listing prerequisites "Makefile"
references "config-host.h" by absolute path in some rules and by relative
path in others. Make cannot figure out that these references points to the
same file which leads to the race: the generation of "version.*" which
requires "$(BUILD_DIR)/config-host.h" is launched in parallel with the
generation of "config-host.h" needed by other "Makefile" targets.
This patch removes "$(BUILD_DIR)/" prefix from corresponding prerequisite
of "version.*". There is no other prerequisites "$(BUILD_DIR)/config-host.h"
found.
Also note that not every version of MSYS is able to build QEMU in parallel,
see: "http://sourceforge.net/p/mingw/bugs/1950/". The suggested version is
1.0.17.
Signed-off-by: Vasily Efimov <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Commit: 12ccfec9684679fc1945b5b5020487b2cb17dc06
https://github.com/qemu/qemu/commit/12ccfec9684679fc1945b5b5020487b2cb17dc06
Author: Michael S. Tsirkin <address@hidden>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Makefile
M scripts/make_device_config.sh
Log Message:
-----------
Makefile: don't silence mak file test with V=1
V=1 should show what's going on, it's not nice
to silence things unconditionally.
Signed-off-by: Michael S. Tsirkin <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Commit: a9ad5e1efcbbdf4b34bd7679613605efdb41bd04
https://github.com/qemu/qemu/commit/a9ad5e1efcbbdf4b34bd7679613605efdb41bd04
Author: Michael S. Tsirkin <address@hidden>
Date: 2015-02-27 (Fri, 27 Feb 2015)
Changed paths:
M Makefile.target
Log Message:
-----------
Makefile.target: binary depends on config-devices
relink binary whenever config-devices.mak changes:
this makes sense as we are adding/removing devices,
so binary has to be relinked to be up to date.
Signed-off-by: Michael S. Tsirkin <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Commit: f6758f7d6b8b483eb1d061937ed06da830c1ecb8
https://github.com/qemu/qemu/commit/f6758f7d6b8b483eb1d061937ed06da830c1ecb8
Author: Max Reitz <address@hidden>
Date: 2015-03-02 (Mon, 02 Mar 2015)
Changed paths:
M hw/scsi/virtio-scsi-dataplane.c
M hw/scsi/virtio-scsi.c
Log Message:
-----------
virtio-scsi: Allocate op blocker reason before blocking
s->blocker is really only used in hw/scsi/virtio-scsi.c; the only places
where it is used in hw/scsi/virtio-scsi-dataplane.c is when it is
allocated and when it is freed. That does not make a whole lot of sense
(and is actually wrong because this leads to s->blocker potentially
being NULL when blk_op_block_all() is called in virtio-scsi.c), so move
the allocation and destruction of s->blocker to the device realization
and unrealization in virtio-scsi.c, respectively.
Case in point:
$ echo -e 'eject drv\nquit' | \
x86_64-softmmu/qemu-system-x86_64 \
-monitor stdio -machine accel=qtest -display none \
-object iothread,id=thr -device virtio-scsi-pci,iothread=thr \
-drive if=none,file=test.qcow2,format=qcow2,id=drv \
-device scsi-cd,drive=drv
Without this patch:
(qemu) eject drv
[1] 10102 done
10103 segmentation fault (core dumped)
With this patch:
(qemu) eject drv
Device 'drv' is busy: block device is in use by data plane
(qemu) quit
Signed-off-by: Max Reitz <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Commit: 6b49809c597331803ea941eadda813e5bb4e8fe2
https://github.com/qemu/qemu/commit/6b49809c597331803ea941eadda813e5bb4e8fe2
Author: Paolo Bonzini <address@hidden>
Date: 2015-03-02 (Mon, 02 Mar 2015)
Changed paths:
M cpus.c
Log Message:
-----------
cpus: fix deadlock and segfault in qemu_mutex_lock_iothread
When two threads (other than the low-priority TCG VCPU thread)
are competing for the iothread lock, a deadlock can happen. This
is because iothread_requesting_mutex is set to false by the first
thread that gets the mutex, and then the VCPU thread might never
yield from the execution loop. If iothread_requesting_mutex is
changed from a bool to a counter, the deadlock is fixed.
However, there is another bug in qemu_mutex_lock_iothread that
can be triggered by the new call_rcu thread. The bug happens
if qemu_mutex_lock_iothread is called before the CPUs are
created. In that case, first_cpu is NULL and the caller
segfaults in qemu_mutex_lock_iothread. To fix this, just
do not do the kick if first_cpu is NULL.
Reported-by: Leon Alrae <address@hidden>
Reported-by: Andreas Gustafsson <address@hidden>
Tested-by: Leon Alrae <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Commit: 21618b3e55ad2c6fede0bffcaea466091811ce59
https://github.com/qemu/qemu/commit/21618b3e55ad2c6fede0bffcaea466091811ce59
Author: Paolo Bonzini <address@hidden>
Date: 2015-03-02 (Mon, 02 Mar 2015)
Changed paths:
M cpus.c
Log Message:
-----------
cpus: be more paranoid in avoiding deadlocks
For good measure, ensure that the following sequence:
thread 1 calls qemu_mutex_lock_iothread
thread 2 calls qemu_mutex_lock_iothread
VCPU thread are created
VCPU thread enters execution loop
results in the VCPU threads letting the other two threads run
and obeying iothread_requesting_mutex even if the VCPUs are
not halted. To do this, check iothread_requesting_mutex
before execution starts.
Tested-by: Leon Alrae <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Commit: 3180aadb1f00fa0f0b47bccbcae5b1d47dc5ff74
https://github.com/qemu/qemu/commit/3180aadb1f00fa0f0b47bccbcae5b1d47dc5ff74
Author: Peter Maydell <address@hidden>
Date: 2015-03-03 (Tue, 03 Mar 2015)
Changed paths:
M Makefile
M Makefile.target
M block/iscsi.c
M bootdevice.c
M cpus.c
M default-configs/arm-softmmu.mak
M default-configs/i386-softmmu.mak
M default-configs/pci.mak
M default-configs/ppc-softmmu.mak
M default-configs/ppc64-softmmu.mak
M default-configs/x86_64-softmmu.mak
M hw/core/Makefile.objs
M hw/misc/Makefile.objs
M hw/pci-bridge/Makefile.objs
M hw/scsi/scsi-bus.c
M hw/scsi/virtio-scsi-dataplane.c
M hw/scsi/virtio-scsi.c
M include/block/block.h
M scripts/make_device_config.sh
M vl.c
Log Message:
-----------
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
- more config options
- bootdevice, iscsi, virtio-scsi fixes
- build system patches for MinGW and config-devices.mak
- qemu_mutex_lock_iothread deadlock fixes
- another tiny patch from the record/replay series
# gpg: Signature made Mon Mar 2 09:59:14 2015 GMT using RSA key ID 78C7AE83
# gpg: Good signature from "Paolo Bonzini <address@hidden>"
# gpg: aka "Paolo Bonzini <address@hidden>"
# 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: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1
# Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83
* remotes/bonzini/tags/for-upstream:
cpus: be more paranoid in avoiding deadlocks
cpus: fix deadlock and segfault in qemu_mutex_lock_iothread
virtio-scsi: Allocate op blocker reason before blocking
Makefile.target: binary depends on config-devices
Makefile: don't silence mak file test with V=1
Makefile: fix up parallel building under MSYS+MinGW
iscsi: Handle write protected case in reopen
Give ivshmem its own config option
Create specific config option for "platform-bus"
Add specific config options for PCI-E bridges
bootdevice: fix segment fault when booting guest with '-kernel' and '-initrd'
timer: replace time() with QEMU_CLOCK_HOST
virtio-scsi-dataplane: Call blk_set_aio_context within BQL
block: Forbid bdrv_set_aio_context outside BQL
scsi: give device a parent before setting properties
Signed-off-by: Peter Maydell <address@hidden>
Compare: https://github.com/qemu/qemu/compare/5efde22aa781...3180aadb1f00
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] 226475: scsi: give device a parent before setting properti...,
GitHub <=