Commit Graph

13 Commits

Author SHA1 Message Date
Max Reitz
f6758f7d6b 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 <mreitz@redhat.com>
Message-Id: <1425057113-26940-1-git-send-email-mreitz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-03-02 10:57:07 +01:00
Cornelia Huck
b0e5d90ebc dataplane: endianness-aware accesses
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>
2015-02-16 15:07:16 +00:00
Ming Lei
6012ca8159 virtio-scsi: dataplane: suppress guest notification
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-12 11:19:19 +01:00
Ming Lei
ed4b43265d virtio-scsi: dataplane: fix allocation for 'cmd_vrings'
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-11-11 12:03:47 +01:00
Paolo Bonzini
ace386b4e0 virtio-scsi: fix dataplane
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: 361dcc790d
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-10-31 17:39:41 +01:00
Cornelia Huck
4adea8042f virtio-scsi: dataplane: stop trying on notifier error
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-23 16:41:25 +02:00
Cornelia Huck
361dcc790d virtio-scsi: dataplane: fail setup gracefully
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-23 16:41:24 +02:00
Cornelia Huck
6d2c83165b virtio-scsi: dataplane: print why starting failed
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-23 16:41:24 +02:00
Fam Zheng
3e2b2a9c49 virtio-scsi-dataplane: Add op blocker
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-23 16:41:22 +02:00
Markus Armbruster
4be746345f hw: Convert from BlockDriverState to BlockBackend, mostly
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-10-20 14:02:25 +02:00
Fam Zheng
1880ad4f4e virtio-scsi: Batched prepare for cmd reqs
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-30 11:11:20 +02:00
Fam Zheng
359eea71d9 virtio-scsi: Two stages processing of cmd request
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-30 11:11:20 +02:00
Fam Zheng
91cb1c9b56 virtio-scsi-dataplane: Code to run virtio-scsi on iothread
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>
2014-09-30 11:11:20 +02:00