Commit c53659f0 ("BlockConf: Call backend functions to detect geometry
and blocksizes") causes a segmentation fault on the invalid
configuration of a scsi device without a drive.
Let's check for conf.blk before calling blkconf_blocksizes. The error
will be handled later on in scsi_realize anyway.
Reported-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
geometry: hd_geometry_guess function autodetects the drive geometry.
This patch adds a block backend call, that probes the backing device
geometry. If the inner driver method is implemented and succeeds
(currently only for DASDs), the blkconf_geometry will pass-through
the backing device geometry. Otherwise will fallback to old logic.
blocksize: This patch initializes blocksize properties to 0.
In order to set the property a blkconf_blocksizes was introduced.
If user didn't set physical or logical blocksize, it will
retrieve its value from a driver (only succeeds for DASD), otherwise
it will set default 512 value.
The blkconf_blocksizes call was added to all users of BlkConf.
Signed-off-by: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 1424087278-49393-6-git-send-email-tumanova@linux.vnet.ibm.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
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 <mreitz@redhat.com>
Message-Id: <1425057113-26940-1-git-send-email-mreitz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
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 <famz@redhat.com>
Message-Id: <1423969591-23646-3-git-send-email-famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
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 <armbru@redhat.com>
Tested-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
- RCU: fix MemoryRegion lifetime issues in PCI; document the rules;
convert of AddressSpaceDispatch and RAMList
- KVM: add kvm_exit reasons for aarch64
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAABAgAGBQJU4hugAAoJEL/70l94x66DZXEH/i72tOgvKZfAjfq2xmHXNEsr
roCfTFIIjKK7feyW6YgwT5pgex6I5umFsO+uIyI/wbu8nDl/3NYEQBT4fR2cGfli
GKeJOEu8kf+Zt8U+fbxyVQclbuU5S0Ujsg1fX4QXC4swB5fGLT2cRWJ5qd6hKBQs
GflBuLa7h4eOzcTtOPpqRIwZ8mQE0uxv/hKq9kYLKHXJN2aWsiOls8KQ2CXj2yAl
p6bMS5f0H0S/1hvQcQV9EazX7owlPIEet3AmSL1TC2sjJ8hrNGMBoFPtUys1uqjc
B3CwuGi0JtWIduFYV9vZ/Ze4G7Y2iZlqc5vDxIl94d+iFmoHymDOi3mFUZ3H8XQ=
=Lk9p
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
- vhost-scsi: add bootindex property
- RCU: fix MemoryRegion lifetime issues in PCI; document the rules;
convert of AddressSpaceDispatch and RAMList
- KVM: add kvm_exit reasons for aarch64
# gpg: Signature made Mon Feb 16 16:32:32 2015 GMT using RSA key ID 78C7AE83
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
# gpg: aka "Paolo Bonzini <pbonzini@redhat.com>"
# 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: (21 commits)
Convert ram_list to RCU
exec: convert ram_list to QLIST
cosmetic changes preparing for the following patches
exec: protect mru_block with RCU
rcu: add g_free_rcu
rcu: introduce RCU-enabled QLIST
exec: RCUify AddressSpaceDispatch
exec: make iotlb RCU-friendly
exec: introduce cpu_reload_memory_map
docs: clarify memory region lifecycle
pci: split shpc_cleanup and shpc_free
pcie: remove mmconfig memory leak and wrap mmconfig update with transaction
memory: keep the owner of the AddressSpace alive until do_address_space_destroy
rcu: run RCU callbacks under the BQL
rcu: do not let RCU callbacks pile up indefinitely
vhost-scsi: set the bootable value of channel/target/lun
vhost-scsi: add a property for booting
vhost-scsi: expose the TYPE_FW_PATH_PROVIDER interface
vhost-scsi: add bootindex property
qdev: support to get a device firmware path directly
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
monitor_handle_fd_param() is a wrapper around
monitor_handle_fd_param2() that feeds errors to qerror_report_err()
instead of returning them. qerror_report_err() is inappropriate in
many contexts. monitor_handle_fd_param() looks simpler than
monitor_handle_fd_param2(), which tempts use. Remove the temptation:
drop the wrapper and open-code the (trivial) error handling instead.
Replace the open-coded qerror_report_err() by error_report_err() in
places that already use error_report(). Turns out that's everywhere.
While there, rename monitor_handle_fd_param2() to monitor_fd_param().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
We get two error messages: one from monitor_handle_fd_param2(), and
another one from vhost_scsi_realize(). The second one gets suppressed
in QMP context.
That's because monitor_handle_fd_param() calls qerror_report_err().
Calling qerror_report_err() is always inappropriate in realize
methods, because it doesn't return the Error object. It either
reports the error to stderr or the human monitor, or it stores it in
the QMP monitor, where it makes the QMP command fail even when the
realize method ignores the error and succeeds. Fortunately,
vhost_scsi_realize() doesn't do that.
Fix by switching to monitor_handle_fd_param2().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
The vring.c code currently assumes that guest and host endianness match,
which is not true for a number of cases:
- emulating targets with a different endianness than the host
- bi-endian targets, where the correct endianness depends on the virtio
device
- upcoming support for the virtio-1 standard mandates little-endian
accesses even for big-endian targets and hosts
Make sure to use accessors that depend on the virtio device.
Note that dataplane now needs to be built per-target.
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Fam Zheng <famz@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 1422289602-17874-2-git-send-email-cornelia.huck@de.ibm.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
At present, the target is valued boot_tpgt, In addition,
channel and lun both are 0 for bootable vhost-scsi device.
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Bo Su <subo7@huawei.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In the way, we can make the bootindex property take effect.
At the meanwhile, the firmware path name of vhost-scsi is
"channel@channel/vhost-scsi@target,lun".
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
One of the annoyances of the current migration format is the fact that
it's not self-describing. In fact, it's not properly describing at all.
Some code randomly scattered throughout QEMU elaborates roughly how to
read and write a stream of bytes.
We discussed an idea during KVM Forum 2013 to add a JSON description of
the migration protocol itself to the migration stream. This patch
adds a section after the VM_END migration end marker that contains
description data on what the device sections of the stream are composed of.
This approach is backwards compatible with any QEMU version reading the
stream, because QEMU just stops reading after the VM_END marker and ignores
any data following it.
With an additional external program this allows us to decipher the
contents of any migration stream and hopefully make migration bugs easier
to track down.
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
scsi_req_cancel_complete is responsible for releasing the request, so we
shouldn't skip it in any case. This doesn't affect the only existing
caller, virtio-scsi, but is useful for other devices once they use it.
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Several places check against the feature bit number instead of against
the feature bit. Fix them.
Cc: qemu-stable@nongnu.org
Reported-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit d577646 (scsi: Introduce scsi_req_cancel_complete, 2014-09-25)
was supposed to have no semantic change, but it missed a case. When
r->aiocb has already been NULLed, but DMA was not complete and the
SCSI layer was waiting for scsi_req_continue, after the patch the
SCSI layer will not call the .cancel callback of SCSIBusInfo.
Fixes: d5776465ee
Cc: qemu-stable@nongnu.org
Reported-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Tested-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Some ancient Linux kernels read from registers 0x09 and 0x3c-3f during
boot. According to the spec these registers are for diag and debug
purposes only. If they are absend qemu aborts on read.
Signed-off-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
- valgrind/KVM support
- small i386 patches
- PCI SD host controller support
- malloc/free cleanups from Markus (x86/scsi)
- IvyBridge model
- XSAVES support for KVM
- initial patches from record/replay
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAABAgAGBQJUjw28AAoJEL/70l94x66D9kcH/RBoc4mNjrSt+MLy9Y+Fu1bu
HNhfd1n/yA0MKSHtSYwJPgkiuoxG3jHt0N69gbpZE0kdBcK+PPZZZUpTFIAU6vD/
D0O7l+2viOcl2z7SPuHIp9/O0CChsAYZkH+Zn2XbeStbe4d4f6bFzdy4vblMsirQ
BfMn/Y2Dw1uLknvrO3/QKgGhbK5Nxo/Te7lavRP+w7FgOhAdAUHOhBPfGrPWtG+0
0hVWmxoQyJtk+Ltt2oF4zUkql7czDsgyXkaO82l3TkecCvtqolCuby4lQIFJnq7E
vw0XUDwC/l/MWnXFq/rG97yopfIxkSAthT/xP/+TTJKM/oJEWDTh6I8ghQTdG90=
=ncys
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
- Migration and linuxboot fixes for 2.2 regressions
- valgrind/KVM support
- small i386 patches
- PCI SD host controller support
- malloc/free cleanups from Markus (x86/scsi)
- IvyBridge model
- XSAVES support for KVM
- initial patches from record/replay
# gpg: Signature made Mon 15 Dec 2014 16:35:08 GMT using RSA key ID 78C7AE83
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
# gpg: aka "Paolo Bonzini <pbonzini@redhat.com>"
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain 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: (47 commits)
sdhci: Support SDHCI devices on PCI
sdhci: Define SDHCI PCI ids
sdhci: Add "sysbus" to sdhci QOM types and methods
sdhci: Remove class "virtual" methods
sdhci: Set a default frequency clock
serial: only resample THR interrupt on rising edge of IER.THRI
serial: update LSR on enabling/disabling FIFOs
serial: clean up THRE/TEMT handling
serial: reset thri_pending on IER writes with THRI=0
linuxboot: fix loading old kernels
kvm/apic: fix 2.2->2.1 migration
target-i386: add Ivy Bridge CPU model
target-i386: add f16c and rdrand to Haswell and Broadwell
target-i386: add VME to all CPUs
pc: add 2.3 machine types
i386: do not cross the pages boundaries in replay mode
cpus: make icount warp behave well with respect to stop/cont
timer: introduce new QEMU_CLOCK_VIRTUAL_RT clock
cpu-exec: invalidate nocache translation if they are interrupted
icount: introduce cpu_get_icount_raw
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The QEMU block layer has a limit of INT_MAX bytes per transfer.
Expose it in the block limits VPD page for both regular transfers
and WRITE SAME.
Reported-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer,
for two reasons. One, it catches multiplication overflowing size_t.
Two, it returns T * rather than void *, which lets the compiler catch
more type errors.
This commit only touches allocations with size arguments of the form
sizeof(T).
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Reviewed-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-id: 1417166789-1960-1-git-send-email-arei.gonglei@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch uses vring_should_notify() to suppress
guest notification, and looks notification frequency
can be decreased from ~33K/sec to ~2K/sec in my test
environment.
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
After a reset ESP_TCHI should contain the unique ID
of the chip. This value will be overwritten with the
current tranfer count if the transfer count has
previously been set.
So we should always return the chip id if ESP_TCHI
has never been written to.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The size of each element should be sizeof(VirtIOSCSIVring *).
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Old BIOSes left some padding by mistake after the req_size/resp_size.
New QEMU does not like it, thinking it is a bidirectional command.
As a workaround, we can check if the ANY_LAYOUT bit is set; if not, we
always consider the first buffer as the virtio-scsi request/response,
because, back when QEMU did not support ANY_LAYOUT, it expected the
payload to start at the second element of the iovec.
This can show up during migration.
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
A linux guest will be issuing messages:
[ 32.124042] DC390: Deadlock in DataIn_0: DMA aborted unfinished: 000000 bytes remain!!
[ 32.126348] DC390: DataIn_0: DMA State: 0
and the HBA will fail to work properly.
Reason is the emulation is not setting the 'DMA transfer done'
status correctly.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We need to count the ctrlq and eventq, and also cleanup before
returning. Besides, the format string should be unsigned.
The number could never be less than zero.
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
MSI-X works slightly different than INTx; the doorbell
registers are not necessarily used as MSI-X interrupts
are directed anyway. So the head pointer on the
reply queue needs to be updated as soon as a frame
is completed, and we can set the doorbell only
when in INTx mode.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Windows requires the frames to be unmapped, otherwise we run
into a race condition where the updated frame data is not
visible to the guest.
With that we can simplify the queue algorithm and use a bitmap
for tracking free frames.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Improve queue logging by displaying head and tail pointer
of the completion queue.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Some implementations use DCMD_CLUSTER_RESET_LD to simulate
a device reset.
Signed-off-by: Hannes Reinecke <hare@suse.de>
[Compare against id, not lun. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The windows driver is sending several init_firmware commands
when in MSI-X mode. It is, however, using only the first
queue. So disregard any additional init_firmware commands
until the HBA is reset.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The EFI firmware doesn't handle unit attentions properly,
so we need to clear the Power On/Reset unit attention upon
initial reset.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
To ease debugging we should be decoding
the register names.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The check for a valid command buffer size was inverted.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The 2108 chip supports MSI and MSI-X, so update the emulation
to support both chips.
Signed-off-by: Hannes Reinecke <hare@suse.de>
[Make VMStateDescription const. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Logical drives can only be addressed with the 'target_id' number;
LUN numbers cannot be selected.
Physical drives can be selected with both, target and LUN id.
So we should disallow LUN numbers not equal to 0 when in
RAID mode.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The MFI_DCMD_LD_LIST_QUERY function is using a different format than
MFI_DCMD_LD_LIST, so we need to implement it differently.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
scsi_cdb_length() does not return the length of the cdb, but
the transfersize encoded in the cdb. So rename it to scsi_cdb_xfer()
and also rename all other related functions to end with _xfer.
We can then add a new scsi_cdb_length() which actually does return the
length of the cdb. With that DEBUG_SCSI can now display the correct
CDB buffer.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The local variable "type" in virtio_scsi_handle_ctl represents the tmf
command type from the guest and it has the same meaning as the
req->req.tmf.type. However, before the invoking of virtio_scsi_parse_req
the req->req.tmf.type doesn't has the correct value(just initialized to
zero). Therefore, we need to use the "type" variable to judge the case.
Cc: qemu-stable@nongnu.org
Signed-off-by: Bin Wu <wu.wubin@huawei.com>
[Actually make it compile, "type" must be uint32_t in order to pass
it to virtio_tswap32s. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If req->resp.cmd.status is not GOOD, the address of sense for
qemu_iovec_from_buf should be modified from &req->resp to sense.
Cc: qemu-stable@nongnu.org
Signed-off-by: Ting Wang <kathy.wangting@huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
There's no use to constantly trying to enable dataplane if we failed
to set up guest or host notifiers, so fence it off in that case.
We'll try again if the device is reinitialized.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The dataplane code is currently doing a hard exit on various setup
failures. In practice, this may mean that a guest suddenly dies after
a dataplane device failed to come up (e.g., when a file descriptor
limit is hit for the nth device).
Let's just try to unwind the setup instead and return.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
