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>
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>
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>
blockdev_init() always creates a DriveInfo, but only drive_new() fills
it in. qmp_blockdev_add() leaves it blank. This results in a drive
with type = IF_IDE, bus = 0, unit = 0. Screwed up in commit ee13ed1c.
Board initialization code looking for IDE drive (0,0) can pick up one
of these bogus drives. The QMP command has to execute really early to
be visible. Not sure how likely that is in practice.
Fix by creating DriveInfo in drive_new(). Block backends created by
blockdev-add don't get one.
Breaks the test for "has been created by qmp_blockdev_add()" in
blockdev_mark_auto_del() and do_drive_del(), because it changes the
value of dinfo && !dinfo->enable_auto_del from true to false. Simply
test !dinfo instead.
Leaves DriveInfo member enable_auto_del unused. Drop it.
A few places assume a block backend always has a DriveInfo. Fix them
up.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
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>
I'll use it with block backends shortly, and the name is going to fit
badly there. It's a block layer thing anyway, not just a block driver
thing.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The patch is big, but all it really does is replacing
dinfo->bdrv
by
blk_bs(blk_by_legacy_dinfo(dinfo))
The replacement is repetitive, but the conversion of device models to
BlockBackend is imminent, and will shorten it to just
blk_legacy_dinfo(dinfo).
Line wrapping muddies the waters a bit. I also omit tests whether
dinfo->bdrv is null, because it never is.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Benoît Canet <benoit.canet@nodalink.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
by making bootindex a writable qom property.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJUPjeVAAoJEEy22O7T6HE4j5QP/RtecYdC9yiOGsGcI4lrDMo8
5j61JzvY7bpPGJykXH7c8B9s3n2LQIW4rzD5mDVB/bKXPwh3SbqPBQmd1T6G7lrR
4lV+c/pvrTDE9V1k0Favbe0pbfOkaBAnMyYEYFkoK7hzVUTN6acbkz0LhXudb4ci
7V9wbSLnZZrTxB50NTJu17EIa7RCDKQR6urskrxAsJeqCAT7NQtXM5ls1dfGvHQs
Tc6u4+zRqv2Rzr9YxkFKPZe55rTBMUw3fcwg9F3657dCujYvcMq8+ZwFGiMXSjll
oUFxwgZn05aRQwxG1YfFDI576+f9ZCirkQBoDBwgp3ZSLTN8CLVDZ0X1FA7vjntH
fr5j7D0M2ftSsUDI2E3UOzaNtbtyQaCkggl+zc0fgw7dEfbitqpUZQQ4wGngBTKJ
BFkky+29MhBTLqBC38S9iUGqUbHbrqIHP/hSW8ixAGm4n8dul+ROgX4ynFZNOuxE
NEA1rRspDHNVanb+gcpK0wv58vvmwbECGrovkI7ffeCo+8+MDW3ebRbQ2fIxUa4C
KbPp6b5vICVcsG0+XRbjA2rNn76iJYCjc+PX1WQX6vgPYEPRah51G44KLyN/r8kj
fw7wOuYomtu+2nymH/8QXBEyACiuCJLTmOykHxsrYURR3VvVeg2Z0j4e7fNOg/Is
+d+cVKKkN8JLFRlXG8qu
=utUi
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/kraxel/tags/pull-bootindex-20141015-1' into staging
allow changing bootorder via monitor at runtime,
by making bootindex a writable qom property.
* remotes/kraxel/tags/pull-bootindex-20141015-1: (34 commits)
bootindex: change fprintf to error_report
bootindex: delete bootindex when device is removed
bootindex: move calling add_boot_device_patch to bootindex setter function
ide: add calling add_boot_device_patch in bootindex setter function
nvma: ide: add bootindex to qom property
usb-storage: add bootindex to qom property
virtio-blk: alias bootindex property explicitly for virt-blk-pci/ccw/s390
block: remove bootindex property from qdev to qom
virtio-blk: add bootindex to qom property
ide: add bootindex to qom property
scsi: add bootindex to qom property
isa-fdc: remove bootindexA/B property from qdev to qom
redirect: remove bootindex property from qdev to qom
vfio: remove bootindex property from qdev to qom
pci-assign: remove bootindex property from qdev to qom
host-libusb: remove bootindex property from qdev to qom
virtio-net: alias bootindex property explicitly for virt-net-pci/ccw/s390
net: remove bootindex property from qdev to qom
usb-net: add bootindex to qom property
vmxnet3: add bootindex to qom property
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
On this way, we can assure the new bootindex take effect
during vm rebooting.
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Remove bootindex form qdev property to qom, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add a qom property with the same name 'bootindex',
when we remove it form qdev property, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
SCSI subsytem was converted to hotplug handler API and
doesn't use SCSIBusInfo{hotplug, hot_unplug} fields and
related callbacks anymore.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
That would allow to handle SCSI device unplug
on HBAs without dedicated hot(un)plug handlers
and avoid making such HBAs explicitly hotpluggable.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
scsi_req_continue can complete the request and cause the VirtIOSCSIReq
to be freed. Fetch req->sreq just once to avoid the bug.
Reported-by: Richard Jones <rjones@redhat.com>
Tested-by: Richard Jones <rjones@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
For VIRTIO_SCSI_T_TMF_ABORT_TASK and VIRTIO_SCSI_T_TMF_ABORT_TASK_SET,
use scsi_req_cancel_async to start the cancellation.
Because each tmf command may cancel multiple requests, we need to use a
counter to track the number of remaining requests we still need to wait
for.
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Devices will call this function to start an asynchronous cancellation. The
bus->info->cancel will be called after the request is canceled.
Devices will probably need to track a separate TMF request that triggers this
cancellation, and wait until the cancellation is done before completing it. So
we store a notifier list in SCSIRequest and in scsi_req_cancel_complete we
notify them.
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Let the aio cb do the clean up and notification job after scsi_req_cancel, in
preparation for asynchronous cancellation.
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The only two implementations are identical to each other, with nothing specific
to device: they only call bdrv_aio_cancel with the SCSIRequest.aiocb.
Let's move it to scsi-bus.
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Before, scsi_req_cancel will take ownership of the canceled request and unref
it. We did this because we didn't know whether AIO CB will be called or not
during the cancelling, so we set the io_canceled flag before calling it, and
skip unref in the potentially called callbacks, which is not very nice.
Now, bdrv_aio_cancel has a stricter contract that the completion callbacks are
always called, so we can remove the checks of req->io_canceled and just unref
it in callbacks.
It will also make implementing asynchronous cancellation easier.
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Now that we always called the cb in bdrv_aio_cancel, let's make scsi-generic
callbacks check io_canceled flag similarly to scsi-disk.
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The only user of this function is spapr_vscsi.c. We can convert to
scsi_req_cancel plus adding a check in vscsi_request_cancelled.
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
[Drop prototype. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
