aboutsummaryrefslogtreecommitdiff
path: root/hw/scsi/virtio-scsi-dataplane.c
AgeCommit message (Collapse)Author
2015-10-23dataplane: Mark host notifiers' client type as "external"Fam Zheng
They will be excluded by type in the nested event loops in block layer, so that unwanted events won't be processed there. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-10-23aio: Add "is_external" flag for event handlersFam Zheng
All callers pass in false, and the real external ones will switch to true in coming patches. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-10-12scsi: switch from g_slice allocator to mallocPaolo Bonzini
Simplify memory allocation by sticking with a single API. GSlice is not that fast anyway (tcmalloc/jemalloc are better). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-03-26virtio-scsi-dataplane: fix memory leak for VirtIOSCSIVringTing Wang
VirtIOSCSIVring which allocated in virtio_scsi_vring_init should be free when dataplane has been stopped or failed to start. Signed-off-by: Ting Wang <kathy.wangting@huawei.com> Message-Id: <1427355752-25844-1-git-send-email-kathy.wangting@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-03-18virtio-scsi-dataplane: fix memory leak in virtio_scsi_vring_initBo Su
if k->set_host_notifier failed, VirtIOSCSIVring *r will leak Signed-off-by: Bo Su <subo7@huawei.com> Message-Id: <1426671732-80213-1-git-send-email-subo7@huawei.com> Reviewed-by: Fam Zheng <famz@redhat.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-03-02virtio-scsi: Allocate op blocker reason before blockingMax Reitz
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>
2015-02-16dataplane: endianness-aware accessesCornelia Huck
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>
2014-11-12virtio-scsi: dataplane: suppress guest notificationMing Lei
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>
2014-11-11virtio-scsi: dataplane: fix allocation for 'cmd_vrings'Ming Lei
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>
2014-10-31virtio-scsi: fix dataplanePaolo Bonzini
Commit 361dcc7 (virtio-scsi: dataplane: fail setup gracefully, 2014-10-15) actually broke successful dataplane setup in a not-so-graceful manner: qemu-system-x86_64: .../util/rfifolock.c:71: rfifolock_unlock: Assertion `r->nesting > 0' failed. due to a missing return statement. Fixes: 361dcc790db8c87b2e46ab610739191ced894c44 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-10-23virtio-scsi: dataplane: stop trying on notifier errorCornelia Huck
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>
2014-10-23virtio-scsi: dataplane: fail setup gracefullyCornelia Huck
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>
2014-10-23virtio-scsi: dataplane: print why starting failedCornelia Huck
Setting up guest or host notifiers may fail, but the user will have no idea why: Let's print the error returned by the callback. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-10-23virtio-scsi-dataplane: Add op blockerFam Zheng
We need this to protect dataplane thread from race conditions with block jobs until the latter is made dataplane-safe. Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-10-20hw: Convert from BlockDriverState to BlockBackend, mostlyMarkus Armbruster
Device models should access their block backends only through the block-backend.h API. Convert them, and drop direct includes of inappropriate headers. Just four uses of BlockDriverState are left: * The Xen paravirtual block device backend (xen_disk.c) opens images itself when set up via xenbus, bypassing blockdev.c. I figure it should go through qmp_blockdev_add() instead. * Device model "usb-storage" prompts for keys. No other device model does, and this one probably shouldn't do it, either. * ide_issue_trim_cb() uses bdrv_aio_discard() instead of blk_aio_discard() because it fishes its backend out of a BlockAIOCB, which has only the BlockDriverState. * PC87312State has an unused BlockDriverState[] member. The next two commits take care of the latter two. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-30virtio-scsi: Batched prepare for cmd reqsFam Zheng
Queue the popped requests while calling virtio_scsi_handle_cmd_req_prepare(), then submit them after all prepared. Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-09-30virtio-scsi: Two stages processing of cmd requestFam Zheng
Mechanical change, in preparation for bdrv_io_plug/bdrv_io_unplug. Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-09-30virtio-scsi-dataplane: Code to run virtio-scsi on iothreadFam Zheng
This implements the core part of dataplane feature of virtio-scsi. A few fields are added in VirtIOSCSICommon to maintain the dataplane status. These fields are managed by a new source file: virtio-scsi-dataplane.c. Most code in this file will run on an iothread, unless otherwise commented as in a global mutex context, such as those functions to start, stop and setting the iothread property. Upon start, we set up guest/host event notifiers, in a same way as virtio-blk does. The handlers then pop request from vring and call into virtio-scsi.c functions to process it. So we need to make sure make all those called functions work with iothread, too. Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>