2012-02-05 04:16:00 -07:00
|
|
|
/*
|
|
|
|
* Virtio SCSI HBA driver
|
|
|
|
*
|
|
|
|
* Copyright IBM Corp. 2010
|
|
|
|
* Copyright Red Hat, Inc. 2011
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
|
|
|
|
* Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
*
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2 or later.
|
|
|
|
* See the COPYING file in the top-level directory.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2013-03-11 23:04:40 -06:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2012-02-05 04:16:00 -07:00
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/mempool.h>
|
2017-02-05 10:15:26 -07:00
|
|
|
#include <linux/interrupt.h>
|
2012-02-05 04:16:00 -07:00
|
|
|
#include <linux/virtio.h>
|
|
|
|
#include <linux/virtio_ids.h>
|
|
|
|
#include <linux/virtio_config.h>
|
|
|
|
#include <linux/virtio_scsi.h>
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
#include <linux/cpu.h>
|
2014-02-22 19:23:33 -07:00
|
|
|
#include <linux/blkdev.h>
|
2012-02-05 04:16:00 -07:00
|
|
|
#include <scsi/scsi_host.h>
|
|
|
|
#include <scsi/scsi_device.h>
|
|
|
|
#include <scsi/scsi_cmnd.h>
|
2014-07-06 08:39:27 -06:00
|
|
|
#include <scsi/scsi_tcq.h>
|
2017-04-12 20:13:00 -06:00
|
|
|
#include <scsi/scsi_devinfo.h>
|
2014-07-06 08:39:26 -06:00
|
|
|
#include <linux/seqlock.h>
|
2017-02-05 10:15:26 -07:00
|
|
|
#include <linux/blk-mq-virtio.h>
|
2012-02-05 04:16:00 -07:00
|
|
|
|
|
|
|
#define VIRTIO_SCSI_MEMPOOL_SZ 64
|
2012-07-05 03:06:43 -06:00
|
|
|
#define VIRTIO_SCSI_EVENT_LEN 8
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
#define VIRTIO_SCSI_VQ_BASE 2
|
2012-02-05 04:16:00 -07:00
|
|
|
|
|
|
|
/* Command queue element */
|
|
|
|
struct virtio_scsi_cmd {
|
|
|
|
struct scsi_cmnd *sc;
|
|
|
|
struct completion *comp;
|
|
|
|
union {
|
|
|
|
struct virtio_scsi_cmd_req cmd;
|
2014-02-22 19:23:33 -07:00
|
|
|
struct virtio_scsi_cmd_req_pi cmd_pi;
|
2012-02-05 04:16:00 -07:00
|
|
|
struct virtio_scsi_ctrl_tmf_req tmf;
|
|
|
|
struct virtio_scsi_ctrl_an_req an;
|
|
|
|
} req;
|
|
|
|
union {
|
|
|
|
struct virtio_scsi_cmd_resp cmd;
|
|
|
|
struct virtio_scsi_ctrl_tmf_resp tmf;
|
|
|
|
struct virtio_scsi_ctrl_an_resp an;
|
|
|
|
struct virtio_scsi_event evt;
|
|
|
|
} resp;
|
|
|
|
} ____cacheline_aligned_in_smp;
|
|
|
|
|
2012-07-05 03:06:43 -06:00
|
|
|
struct virtio_scsi_event_node {
|
|
|
|
struct virtio_scsi *vscsi;
|
|
|
|
struct virtio_scsi_event event;
|
|
|
|
struct work_struct work;
|
|
|
|
};
|
|
|
|
|
2012-06-13 08:56:32 -06:00
|
|
|
struct virtio_scsi_vq {
|
|
|
|
/* Protects vq */
|
|
|
|
spinlock_t vq_lock;
|
|
|
|
|
|
|
|
struct virtqueue *vq;
|
|
|
|
};
|
|
|
|
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
/*
|
|
|
|
* Per-target queue state.
|
|
|
|
*
|
|
|
|
* This struct holds the data needed by the queue steering policy. When a
|
|
|
|
* target is sent multiple requests, we need to drive them to the same queue so
|
|
|
|
* that FIFO processing order is kept. However, if a target was idle, we can
|
|
|
|
* choose a queue arbitrarily. In this case the queue is chosen according to
|
|
|
|
* the current VCPU, so the driver expects the number of request queues to be
|
|
|
|
* equal to the number of VCPUs. This makes it easy and fast to select the
|
|
|
|
* queue, and also lets the driver optimize the IRQ affinity for the virtqueues
|
|
|
|
* (each virtqueue's affinity is set to the CPU that "owns" the queue).
|
|
|
|
*
|
2014-07-06 08:39:26 -06:00
|
|
|
* tgt_seq is held to serialize reading and writing req_vq.
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
*
|
2014-05-08 01:23:45 -06:00
|
|
|
* Decrements of reqs are never concurrent with writes of req_vq: before the
|
|
|
|
* decrement reqs will be != 0; after the decrement the virtqueue completion
|
|
|
|
* routine will not use the req_vq so it can be changed by a new request.
|
2014-07-06 08:39:26 -06:00
|
|
|
* Thus they can happen outside the tgt_seq, provided of course we make reqs
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
* an atomic_t.
|
|
|
|
*/
|
2012-06-13 08:56:34 -06:00
|
|
|
struct virtio_scsi_target_state {
|
2014-07-06 08:39:26 -06:00
|
|
|
seqcount_t tgt_seq;
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
|
|
|
|
/* Count of outstanding requests. */
|
|
|
|
atomic_t reqs;
|
|
|
|
|
|
|
|
/* Currently active virtqueue for requests sent to this target. */
|
|
|
|
struct virtio_scsi_vq *req_vq;
|
2012-06-13 08:56:34 -06:00
|
|
|
};
|
|
|
|
|
2012-02-05 04:16:00 -07:00
|
|
|
/* Driver instance state */
|
|
|
|
struct virtio_scsi {
|
|
|
|
struct virtio_device *vdev;
|
2012-06-13 08:56:34 -06:00
|
|
|
|
2012-07-05 03:06:43 -06:00
|
|
|
/* Get some buffers ready for event vq */
|
|
|
|
struct virtio_scsi_event_node event_list[VIRTIO_SCSI_EVENT_LEN];
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
|
|
|
|
u32 num_queues;
|
|
|
|
|
|
|
|
/* If the affinity hint is set for virtqueues */
|
|
|
|
bool affinity_hint_set;
|
|
|
|
|
2016-09-06 11:04:46 -06:00
|
|
|
struct hlist_node node;
|
2013-04-08 07:35:49 -06:00
|
|
|
|
2014-10-14 17:52:33 -06:00
|
|
|
/* Protected by event_vq lock */
|
|
|
|
bool stop_events;
|
|
|
|
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
struct virtio_scsi_vq ctrl_vq;
|
|
|
|
struct virtio_scsi_vq event_vq;
|
|
|
|
struct virtio_scsi_vq req_vqs[];
|
2012-02-05 04:16:00 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
static struct kmem_cache *virtscsi_cmd_cache;
|
|
|
|
static mempool_t *virtscsi_cmd_pool;
|
|
|
|
|
|
|
|
static inline struct Scsi_Host *virtio_scsi_host(struct virtio_device *vdev)
|
|
|
|
{
|
|
|
|
return vdev->priv;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void virtscsi_compute_resid(struct scsi_cmnd *sc, u32 resid)
|
|
|
|
{
|
|
|
|
if (!resid)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!scsi_bidi_cmnd(sc)) {
|
|
|
|
scsi_set_resid(sc, resid);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
scsi_in(sc)->resid = min(resid, scsi_in(sc)->length);
|
|
|
|
scsi_out(sc)->resid = resid - scsi_in(sc)->resid;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* virtscsi_complete_cmd - finish a scsi_cmd and invoke scsi_done
|
|
|
|
*
|
|
|
|
* Called with vq_lock held.
|
|
|
|
*/
|
2013-04-08 07:31:38 -06:00
|
|
|
static void virtscsi_complete_cmd(struct virtio_scsi *vscsi, void *buf)
|
2012-02-05 04:16:00 -07:00
|
|
|
{
|
|
|
|
struct virtio_scsi_cmd *cmd = buf;
|
|
|
|
struct scsi_cmnd *sc = cmd->sc;
|
|
|
|
struct virtio_scsi_cmd_resp *resp = &cmd->resp.cmd;
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
struct virtio_scsi_target_state *tgt =
|
|
|
|
scsi_target(sc->device)->hostdata;
|
2012-02-05 04:16:00 -07:00
|
|
|
|
|
|
|
dev_dbg(&sc->device->sdev_gendev,
|
|
|
|
"cmd %p response %u status %#02x sense_len %u\n",
|
|
|
|
sc, resp->response, resp->status, resp->sense_len);
|
|
|
|
|
|
|
|
sc->result = resp->status;
|
2014-11-23 08:28:57 -07:00
|
|
|
virtscsi_compute_resid(sc, virtio32_to_cpu(vscsi->vdev, resp->resid));
|
2012-02-05 04:16:00 -07:00
|
|
|
switch (resp->response) {
|
|
|
|
case VIRTIO_SCSI_S_OK:
|
|
|
|
set_host_byte(sc, DID_OK);
|
|
|
|
break;
|
|
|
|
case VIRTIO_SCSI_S_OVERRUN:
|
|
|
|
set_host_byte(sc, DID_ERROR);
|
|
|
|
break;
|
|
|
|
case VIRTIO_SCSI_S_ABORTED:
|
|
|
|
set_host_byte(sc, DID_ABORT);
|
|
|
|
break;
|
|
|
|
case VIRTIO_SCSI_S_BAD_TARGET:
|
|
|
|
set_host_byte(sc, DID_BAD_TARGET);
|
|
|
|
break;
|
|
|
|
case VIRTIO_SCSI_S_RESET:
|
|
|
|
set_host_byte(sc, DID_RESET);
|
|
|
|
break;
|
|
|
|
case VIRTIO_SCSI_S_BUSY:
|
|
|
|
set_host_byte(sc, DID_BUS_BUSY);
|
|
|
|
break;
|
|
|
|
case VIRTIO_SCSI_S_TRANSPORT_FAILURE:
|
|
|
|
set_host_byte(sc, DID_TRANSPORT_DISRUPTED);
|
|
|
|
break;
|
|
|
|
case VIRTIO_SCSI_S_TARGET_FAILURE:
|
|
|
|
set_host_byte(sc, DID_TARGET_FAILURE);
|
|
|
|
break;
|
|
|
|
case VIRTIO_SCSI_S_NEXUS_FAILURE:
|
|
|
|
set_host_byte(sc, DID_NEXUS_FAILURE);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
scmd_printk(KERN_WARNING, sc, "Unknown response %d",
|
|
|
|
resp->response);
|
|
|
|
/* fall through */
|
|
|
|
case VIRTIO_SCSI_S_FAILURE:
|
|
|
|
set_host_byte(sc, DID_ERROR);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2014-11-23 08:28:57 -07:00
|
|
|
WARN_ON(virtio32_to_cpu(vscsi->vdev, resp->sense_len) >
|
|
|
|
VIRTIO_SCSI_SENSE_SIZE);
|
2012-02-05 04:16:00 -07:00
|
|
|
if (sc->sense_buffer) {
|
|
|
|
memcpy(sc->sense_buffer, resp->sense,
|
2014-11-23 08:28:57 -07:00
|
|
|
min_t(u32,
|
|
|
|
virtio32_to_cpu(vscsi->vdev, resp->sense_len),
|
|
|
|
VIRTIO_SCSI_SENSE_SIZE));
|
2012-02-05 04:16:00 -07:00
|
|
|
if (resp->sense_len)
|
|
|
|
set_driver_byte(sc, DRIVER_SENSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
sc->scsi_done(sc);
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
|
|
|
|
atomic_dec(&tgt->reqs);
|
2012-02-05 04:16:00 -07:00
|
|
|
}
|
|
|
|
|
2013-04-08 07:32:07 -06:00
|
|
|
static void virtscsi_vq_done(struct virtio_scsi *vscsi,
|
|
|
|
struct virtio_scsi_vq *virtscsi_vq,
|
2013-04-08 07:31:38 -06:00
|
|
|
void (*fn)(struct virtio_scsi *vscsi, void *buf))
|
2012-02-05 04:16:00 -07:00
|
|
|
{
|
|
|
|
void *buf;
|
|
|
|
unsigned int len;
|
2013-04-08 07:32:07 -06:00
|
|
|
unsigned long flags;
|
|
|
|
struct virtqueue *vq = virtscsi_vq->vq;
|
2012-02-05 04:16:00 -07:00
|
|
|
|
2013-04-08 07:32:07 -06:00
|
|
|
spin_lock_irqsave(&virtscsi_vq->vq_lock, flags);
|
2012-02-05 04:16:00 -07:00
|
|
|
do {
|
|
|
|
virtqueue_disable_cb(vq);
|
|
|
|
while ((buf = virtqueue_get_buf(vq, &len)) != NULL)
|
2013-04-08 07:31:38 -06:00
|
|
|
fn(vscsi, buf);
|
2013-11-10 18:22:43 -07:00
|
|
|
|
|
|
|
if (unlikely(virtqueue_is_broken(vq)))
|
|
|
|
break;
|
2012-02-05 04:16:00 -07:00
|
|
|
} while (!virtqueue_enable_cb(vq));
|
2013-04-08 07:32:07 -06:00
|
|
|
spin_unlock_irqrestore(&virtscsi_vq->vq_lock, flags);
|
2012-02-05 04:16:00 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void virtscsi_req_done(struct virtqueue *vq)
|
|
|
|
{
|
2012-06-13 08:56:32 -06:00
|
|
|
struct Scsi_Host *sh = virtio_scsi_host(vq->vdev);
|
|
|
|
struct virtio_scsi *vscsi = shost_priv(sh);
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
int index = vq->index - VIRTIO_SCSI_VQ_BASE;
|
|
|
|
struct virtio_scsi_vq *req_vq = &vscsi->req_vqs[index];
|
|
|
|
|
|
|
|
virtscsi_vq_done(vscsi, req_vq, virtscsi_complete_cmd);
|
2012-02-05 04:16:00 -07:00
|
|
|
};
|
|
|
|
|
2014-06-04 05:34:58 -06:00
|
|
|
static void virtscsi_poll_requests(struct virtio_scsi *vscsi)
|
|
|
|
{
|
|
|
|
int i, num_vqs;
|
|
|
|
|
|
|
|
num_vqs = vscsi->num_queues;
|
|
|
|
for (i = 0; i < num_vqs; i++)
|
|
|
|
virtscsi_vq_done(vscsi, &vscsi->req_vqs[i],
|
|
|
|
virtscsi_complete_cmd);
|
|
|
|
}
|
|
|
|
|
2013-04-08 07:31:38 -06:00
|
|
|
static void virtscsi_complete_free(struct virtio_scsi *vscsi, void *buf)
|
2012-02-05 04:16:00 -07:00
|
|
|
{
|
|
|
|
struct virtio_scsi_cmd *cmd = buf;
|
|
|
|
|
|
|
|
if (cmd->comp)
|
2016-09-13 02:58:50 -06:00
|
|
|
complete(cmd->comp);
|
2012-02-05 04:16:00 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void virtscsi_ctrl_done(struct virtqueue *vq)
|
|
|
|
{
|
2012-06-13 08:56:32 -06:00
|
|
|
struct Scsi_Host *sh = virtio_scsi_host(vq->vdev);
|
|
|
|
struct virtio_scsi *vscsi = shost_priv(sh);
|
|
|
|
|
2013-04-08 07:32:07 -06:00
|
|
|
virtscsi_vq_done(vscsi, &vscsi->ctrl_vq, virtscsi_complete_free);
|
2012-02-05 04:16:00 -07:00
|
|
|
};
|
|
|
|
|
2014-06-04 05:34:56 -06:00
|
|
|
static void virtscsi_handle_event(struct work_struct *work);
|
|
|
|
|
2012-07-05 03:06:43 -06:00
|
|
|
static int virtscsi_kick_event(struct virtio_scsi *vscsi,
|
|
|
|
struct virtio_scsi_event_node *event_node)
|
|
|
|
{
|
2012-10-16 07:26:16 -06:00
|
|
|
int err;
|
2012-07-05 03:06:43 -06:00
|
|
|
struct scatterlist sg;
|
|
|
|
unsigned long flags;
|
|
|
|
|
2014-06-04 05:34:56 -06:00
|
|
|
INIT_WORK(&event_node->work, virtscsi_handle_event);
|
2012-10-02 09:25:46 -06:00
|
|
|
sg_init_one(&sg, &event_node->event, sizeof(struct virtio_scsi_event));
|
2012-07-05 03:06:43 -06:00
|
|
|
|
|
|
|
spin_lock_irqsave(&vscsi->event_vq.vq_lock, flags);
|
|
|
|
|
2013-03-19 23:14:28 -06:00
|
|
|
err = virtqueue_add_inbuf(vscsi->event_vq.vq, &sg, 1, event_node,
|
|
|
|
GFP_ATOMIC);
|
2012-10-16 07:26:16 -06:00
|
|
|
if (!err)
|
2012-07-05 03:06:43 -06:00
|
|
|
virtqueue_kick(vscsi->event_vq.vq);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&vscsi->event_vq.vq_lock, flags);
|
|
|
|
|
2012-10-16 07:26:16 -06:00
|
|
|
return err;
|
2012-07-05 03:06:43 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
static int virtscsi_kick_event_all(struct virtio_scsi *vscsi)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < VIRTIO_SCSI_EVENT_LEN; i++) {
|
|
|
|
vscsi->event_list[i].vscsi = vscsi;
|
|
|
|
virtscsi_kick_event(vscsi, &vscsi->event_list[i]);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void virtscsi_cancel_event_work(struct virtio_scsi *vscsi)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2014-10-14 17:52:33 -06:00
|
|
|
/* Stop scheduling work before calling cancel_work_sync. */
|
|
|
|
spin_lock_irq(&vscsi->event_vq.vq_lock);
|
|
|
|
vscsi->stop_events = true;
|
|
|
|
spin_unlock_irq(&vscsi->event_vq.vq_lock);
|
|
|
|
|
2012-07-05 03:06:43 -06:00
|
|
|
for (i = 0; i < VIRTIO_SCSI_EVENT_LEN; i++)
|
|
|
|
cancel_work_sync(&vscsi->event_list[i].work);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void virtscsi_handle_transport_reset(struct virtio_scsi *vscsi,
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
struct virtio_scsi_event *event)
|
2012-07-05 03:06:43 -06:00
|
|
|
{
|
|
|
|
struct scsi_device *sdev;
|
|
|
|
struct Scsi_Host *shost = virtio_scsi_host(vscsi->vdev);
|
|
|
|
unsigned int target = event->lun[1];
|
|
|
|
unsigned int lun = (event->lun[2] << 8) | event->lun[3];
|
|
|
|
|
2014-11-23 08:28:57 -07:00
|
|
|
switch (virtio32_to_cpu(vscsi->vdev, event->reason)) {
|
2012-07-05 03:06:43 -06:00
|
|
|
case VIRTIO_SCSI_EVT_RESET_RESCAN:
|
|
|
|
scsi_add_device(shost, 0, target, lun);
|
|
|
|
break;
|
|
|
|
case VIRTIO_SCSI_EVT_RESET_REMOVED:
|
|
|
|
sdev = scsi_device_lookup(shost, 0, target, lun);
|
|
|
|
if (sdev) {
|
|
|
|
scsi_remove_device(sdev);
|
|
|
|
scsi_device_put(sdev);
|
|
|
|
} else {
|
|
|
|
pr_err("SCSI device %d 0 %d %d not found\n",
|
|
|
|
shost->host_no, target, lun);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
pr_info("Unsupport virtio scsi event reason %x\n", event->reason);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-10-02 09:25:48 -06:00
|
|
|
static void virtscsi_handle_param_change(struct virtio_scsi *vscsi,
|
|
|
|
struct virtio_scsi_event *event)
|
|
|
|
{
|
|
|
|
struct scsi_device *sdev;
|
|
|
|
struct Scsi_Host *shost = virtio_scsi_host(vscsi->vdev);
|
|
|
|
unsigned int target = event->lun[1];
|
|
|
|
unsigned int lun = (event->lun[2] << 8) | event->lun[3];
|
2014-11-23 08:28:57 -07:00
|
|
|
u8 asc = virtio32_to_cpu(vscsi->vdev, event->reason) & 255;
|
|
|
|
u8 ascq = virtio32_to_cpu(vscsi->vdev, event->reason) >> 8;
|
2012-10-02 09:25:48 -06:00
|
|
|
|
|
|
|
sdev = scsi_device_lookup(shost, 0, target, lun);
|
|
|
|
if (!sdev) {
|
|
|
|
pr_err("SCSI device %d 0 %d %d not found\n",
|
|
|
|
shost->host_no, target, lun);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Handle "Parameters changed", "Mode parameters changed", and
|
|
|
|
"Capacity data has changed". */
|
|
|
|
if (asc == 0x2a && (ascq == 0x00 || ascq == 0x01 || ascq == 0x09))
|
|
|
|
scsi_rescan_device(&sdev->sdev_gendev);
|
|
|
|
|
|
|
|
scsi_device_put(sdev);
|
|
|
|
}
|
|
|
|
|
2012-07-05 03:06:43 -06:00
|
|
|
static void virtscsi_handle_event(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct virtio_scsi_event_node *event_node =
|
|
|
|
container_of(work, struct virtio_scsi_event_node, work);
|
|
|
|
struct virtio_scsi *vscsi = event_node->vscsi;
|
|
|
|
struct virtio_scsi_event *event = &event_node->event;
|
|
|
|
|
2014-11-23 08:28:57 -07:00
|
|
|
if (event->event &
|
|
|
|
cpu_to_virtio32(vscsi->vdev, VIRTIO_SCSI_T_EVENTS_MISSED)) {
|
|
|
|
event->event &= ~cpu_to_virtio32(vscsi->vdev,
|
|
|
|
VIRTIO_SCSI_T_EVENTS_MISSED);
|
2012-07-05 03:06:43 -06:00
|
|
|
scsi_scan_host(virtio_scsi_host(vscsi->vdev));
|
|
|
|
}
|
|
|
|
|
2014-11-23 08:28:57 -07:00
|
|
|
switch (virtio32_to_cpu(vscsi->vdev, event->event)) {
|
2012-07-05 03:06:43 -06:00
|
|
|
case VIRTIO_SCSI_T_NO_EVENT:
|
|
|
|
break;
|
|
|
|
case VIRTIO_SCSI_T_TRANSPORT_RESET:
|
|
|
|
virtscsi_handle_transport_reset(vscsi, event);
|
|
|
|
break;
|
2012-10-02 09:25:48 -06:00
|
|
|
case VIRTIO_SCSI_T_PARAM_CHANGE:
|
|
|
|
virtscsi_handle_param_change(vscsi, event);
|
|
|
|
break;
|
2012-07-05 03:06:43 -06:00
|
|
|
default:
|
|
|
|
pr_err("Unsupport virtio scsi event %x\n", event->event);
|
|
|
|
}
|
|
|
|
virtscsi_kick_event(vscsi, event_node);
|
|
|
|
}
|
|
|
|
|
2013-04-08 07:31:38 -06:00
|
|
|
static void virtscsi_complete_event(struct virtio_scsi *vscsi, void *buf)
|
2012-07-05 03:06:43 -06:00
|
|
|
{
|
|
|
|
struct virtio_scsi_event_node *event_node = buf;
|
|
|
|
|
2014-10-14 17:52:33 -06:00
|
|
|
if (!vscsi->stop_events)
|
|
|
|
queue_work(system_freezable_wq, &event_node->work);
|
2012-07-05 03:06:43 -06:00
|
|
|
}
|
|
|
|
|
2012-02-05 04:16:00 -07:00
|
|
|
static void virtscsi_event_done(struct virtqueue *vq)
|
|
|
|
{
|
2012-06-13 08:56:32 -06:00
|
|
|
struct Scsi_Host *sh = virtio_scsi_host(vq->vdev);
|
|
|
|
struct virtio_scsi *vscsi = shost_priv(sh);
|
|
|
|
|
2013-04-08 07:32:07 -06:00
|
|
|
virtscsi_vq_done(vscsi, &vscsi->event_vq, virtscsi_complete_event);
|
2012-02-05 04:16:00 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
2013-03-19 23:14:28 -06:00
|
|
|
* virtscsi_add_cmd - add a virtio_scsi_cmd to a virtqueue
|
|
|
|
* @vq : the struct virtqueue we're talking about
|
2012-02-05 04:16:00 -07:00
|
|
|
* @cmd : command structure
|
|
|
|
* @req_size : size of the request buffer
|
|
|
|
* @resp_size : size of the response buffer
|
|
|
|
*/
|
2013-03-19 23:14:28 -06:00
|
|
|
static int virtscsi_add_cmd(struct virtqueue *vq,
|
|
|
|
struct virtio_scsi_cmd *cmd,
|
2014-05-20 19:55:04 -06:00
|
|
|
size_t req_size, size_t resp_size)
|
2012-02-05 04:16:00 -07:00
|
|
|
{
|
|
|
|
struct scsi_cmnd *sc = cmd->sc;
|
2014-02-22 19:23:33 -07:00
|
|
|
struct scatterlist *sgs[6], req, resp;
|
2013-03-19 23:14:28 -06:00
|
|
|
struct sg_table *out, *in;
|
|
|
|
unsigned out_num = 0, in_num = 0;
|
|
|
|
|
|
|
|
out = in = NULL;
|
|
|
|
|
|
|
|
if (sc && sc->sc_data_direction != DMA_NONE) {
|
|
|
|
if (sc->sc_data_direction != DMA_FROM_DEVICE)
|
|
|
|
out = &scsi_out(sc)->table;
|
|
|
|
if (sc->sc_data_direction != DMA_TO_DEVICE)
|
|
|
|
in = &scsi_in(sc)->table;
|
|
|
|
}
|
2012-02-05 04:16:00 -07:00
|
|
|
|
|
|
|
/* Request header. */
|
2013-03-19 23:14:28 -06:00
|
|
|
sg_init_one(&req, &cmd->req, req_size);
|
|
|
|
sgs[out_num++] = &req;
|
2012-02-05 04:16:00 -07:00
|
|
|
|
|
|
|
/* Data-out buffer. */
|
2014-02-22 19:23:33 -07:00
|
|
|
if (out) {
|
|
|
|
/* Place WRITE protection SGLs before Data OUT payload */
|
|
|
|
if (scsi_prot_sg_count(sc))
|
|
|
|
sgs[out_num++] = scsi_prot_sglist(sc);
|
2013-03-19 23:14:28 -06:00
|
|
|
sgs[out_num++] = out->sgl;
|
2014-02-22 19:23:33 -07:00
|
|
|
}
|
2012-02-05 04:16:00 -07:00
|
|
|
|
|
|
|
/* Response header. */
|
2013-03-19 23:14:28 -06:00
|
|
|
sg_init_one(&resp, &cmd->resp, resp_size);
|
|
|
|
sgs[out_num + in_num++] = &resp;
|
2012-02-05 04:16:00 -07:00
|
|
|
|
|
|
|
/* Data-in buffer */
|
2014-02-22 19:23:33 -07:00
|
|
|
if (in) {
|
|
|
|
/* Place READ protection SGLs before Data IN payload */
|
|
|
|
if (scsi_prot_sg_count(sc))
|
|
|
|
sgs[out_num + in_num++] = scsi_prot_sglist(sc);
|
2013-03-19 23:14:28 -06:00
|
|
|
sgs[out_num + in_num++] = in->sgl;
|
2014-02-22 19:23:33 -07:00
|
|
|
}
|
2012-02-05 04:16:00 -07:00
|
|
|
|
2014-05-20 19:55:04 -06:00
|
|
|
return virtqueue_add_sgs(vq, sgs, out_num, in_num, cmd, GFP_ATOMIC);
|
2012-02-05 04:16:00 -07:00
|
|
|
}
|
|
|
|
|
2013-03-19 23:14:28 -06:00
|
|
|
static int virtscsi_kick_cmd(struct virtio_scsi_vq *vq,
|
2012-02-05 04:16:00 -07:00
|
|
|
struct virtio_scsi_cmd *cmd,
|
2014-05-20 19:55:04 -06:00
|
|
|
size_t req_size, size_t resp_size)
|
2012-02-05 04:16:00 -07:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
2012-10-16 07:26:16 -06:00
|
|
|
int err;
|
|
|
|
bool needs_kick = false;
|
2012-02-05 04:16:00 -07:00
|
|
|
|
2013-03-19 23:14:28 -06:00
|
|
|
spin_lock_irqsave(&vq->vq_lock, flags);
|
2014-05-20 19:55:04 -06:00
|
|
|
err = virtscsi_add_cmd(vq->vq, cmd, req_size, resp_size);
|
2012-10-16 07:26:16 -06:00
|
|
|
if (!err)
|
|
|
|
needs_kick = virtqueue_kick_prepare(vq->vq);
|
2012-06-13 08:56:32 -06:00
|
|
|
|
2012-06-13 08:56:33 -06:00
|
|
|
spin_unlock_irqrestore(&vq->vq_lock, flags);
|
2012-02-05 04:16:00 -07:00
|
|
|
|
2012-10-16 07:26:16 -06:00
|
|
|
if (needs_kick)
|
2012-06-13 08:56:32 -06:00
|
|
|
virtqueue_notify(vq->vq);
|
2012-10-16 07:26:16 -06:00
|
|
|
return err;
|
2012-02-05 04:16:00 -07:00
|
|
|
}
|
|
|
|
|
2014-11-23 08:28:57 -07:00
|
|
|
static void virtio_scsi_init_hdr(struct virtio_device *vdev,
|
|
|
|
struct virtio_scsi_cmd_req *cmd,
|
2014-02-22 19:23:33 -07:00
|
|
|
struct scsi_cmnd *sc)
|
|
|
|
{
|
|
|
|
cmd->lun[0] = 1;
|
|
|
|
cmd->lun[1] = sc->device->id;
|
|
|
|
cmd->lun[2] = (sc->device->lun >> 8) | 0x40;
|
|
|
|
cmd->lun[3] = sc->device->lun & 0xff;
|
2014-11-23 08:28:57 -07:00
|
|
|
cmd->tag = cpu_to_virtio64(vdev, (unsigned long)sc);
|
2014-02-22 19:23:33 -07:00
|
|
|
cmd->task_attr = VIRTIO_SCSI_S_SIMPLE;
|
|
|
|
cmd->prio = 0;
|
|
|
|
cmd->crn = 0;
|
|
|
|
}
|
|
|
|
|
2015-04-27 06:56:14 -06:00
|
|
|
#ifdef CONFIG_BLK_DEV_INTEGRITY
|
2014-11-23 08:28:57 -07:00
|
|
|
static void virtio_scsi_init_hdr_pi(struct virtio_device *vdev,
|
|
|
|
struct virtio_scsi_cmd_req_pi *cmd_pi,
|
2014-02-22 19:23:33 -07:00
|
|
|
struct scsi_cmnd *sc)
|
|
|
|
{
|
|
|
|
struct request *rq = sc->request;
|
|
|
|
struct blk_integrity *bi;
|
|
|
|
|
2014-11-23 08:28:57 -07:00
|
|
|
virtio_scsi_init_hdr(vdev, (struct virtio_scsi_cmd_req *)cmd_pi, sc);
|
2014-02-22 19:23:33 -07:00
|
|
|
|
|
|
|
if (!rq || !scsi_prot_sg_count(sc))
|
|
|
|
return;
|
|
|
|
|
|
|
|
bi = blk_get_integrity(rq->rq_disk);
|
|
|
|
|
|
|
|
if (sc->sc_data_direction == DMA_TO_DEVICE)
|
2014-11-23 08:28:57 -07:00
|
|
|
cmd_pi->pi_bytesout = cpu_to_virtio32(vdev,
|
|
|
|
blk_rq_sectors(rq) *
|
|
|
|
bi->tuple_size);
|
2014-02-22 19:23:33 -07:00
|
|
|
else if (sc->sc_data_direction == DMA_FROM_DEVICE)
|
2014-11-23 08:28:57 -07:00
|
|
|
cmd_pi->pi_bytesin = cpu_to_virtio32(vdev,
|
|
|
|
blk_rq_sectors(rq) *
|
|
|
|
bi->tuple_size);
|
2014-02-22 19:23:33 -07:00
|
|
|
}
|
2015-04-27 06:56:14 -06:00
|
|
|
#endif
|
2014-02-22 19:23:33 -07:00
|
|
|
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
|
|
|
|
struct virtio_scsi_vq *req_vq,
|
|
|
|
struct scsi_cmnd *sc)
|
2012-02-05 04:16:00 -07:00
|
|
|
{
|
2012-06-13 08:56:34 -06:00
|
|
|
struct Scsi_Host *shost = virtio_scsi_host(vscsi->vdev);
|
2014-05-01 08:51:50 -06:00
|
|
|
struct virtio_scsi_cmd *cmd = scsi_cmd_priv(sc);
|
scsi: virtio_scsi: Reject commands when virtqueue is broken
In the case of a graceful set of detaches, where the virtio-scsi-ccw
disk is removed from the guest prior to the controller, the guest
behaves quite normally. Specifically, the detach gets us into
sd_sync_cache to issue a Synchronize Cache(10) command, which
immediately fails (and is retried a couple of times) because the device
has been removed. Later, the removal of the controller sees two CRWs
presented, but there's no further indication of the removal from the
guest viewpoint.
[ 17.217458] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 17.219257] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 21.449400] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0, erc=4, rsid=2
[ 21.449406] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0, erc=4, rsid=0
However, on s390, the SCSI disks can be removed "by surprise" when an
entire controller (host) is removed and all associated disks are removed
via the loop in scsi_forget_host. The same call to sd_sync_cache is
made, but because the controller has already been removed, the
Synchronize Cache(10) command is neither issued (and then failed) nor
rejected.
That the I/O isn't returned means the guest cannot have other devices
added nor removed, and other tasks (such as shutdown or reboot) issued
by the guest will not complete either. The virtio ring has already been
marked as broken (via virtio_break_device in virtio_ccw_remove), but we
still attempt to queue the command only to have it remain there. The
calling sequence provides a bit of distinction for us:
virtscsi_queuecommand()
-> virtscsi_kick_cmd()
-> virtscsi_add_cmd()
-> virtqueue_add_sgs()
-> virtqueue_add()
if success
return 0
elseif vq->broken or vring_mapping_error()
return -EIO
else
return -ENOSPC
A return of ENOSPC is generally a temporary condition, so returning
"host busy" from virtscsi_queuecommand makes sense here, to have it
redriven in a moment or two. But the EIO return code is more of a
permanent error and so it would be wise to return the I/O itself and
allow the calling thread to finish gracefully. The result is these four
kernel messages in the guest (the fourth one does not occur prior to
this patch):
[ 22.921562] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0, erc=4, rsid=2
[ 22.921580] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0, erc=4, rsid=0
[ 22.921978] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 22.921993] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
I opted to fill in the same response data that is returned from the more
graceful device detach, where the disk device is removed prior to the
controller device.
Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-01-13 10:48:06 -07:00
|
|
|
unsigned long flags;
|
2014-06-12 23:38:32 -06:00
|
|
|
int req_size;
|
scsi: virtio_scsi: Reject commands when virtqueue is broken
In the case of a graceful set of detaches, where the virtio-scsi-ccw
disk is removed from the guest prior to the controller, the guest
behaves quite normally. Specifically, the detach gets us into
sd_sync_cache to issue a Synchronize Cache(10) command, which
immediately fails (and is retried a couple of times) because the device
has been removed. Later, the removal of the controller sees two CRWs
presented, but there's no further indication of the removal from the
guest viewpoint.
[ 17.217458] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 17.219257] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 21.449400] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0, erc=4, rsid=2
[ 21.449406] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0, erc=4, rsid=0
However, on s390, the SCSI disks can be removed "by surprise" when an
entire controller (host) is removed and all associated disks are removed
via the loop in scsi_forget_host. The same call to sd_sync_cache is
made, but because the controller has already been removed, the
Synchronize Cache(10) command is neither issued (and then failed) nor
rejected.
That the I/O isn't returned means the guest cannot have other devices
added nor removed, and other tasks (such as shutdown or reboot) issued
by the guest will not complete either. The virtio ring has already been
marked as broken (via virtio_break_device in virtio_ccw_remove), but we
still attempt to queue the command only to have it remain there. The
calling sequence provides a bit of distinction for us:
virtscsi_queuecommand()
-> virtscsi_kick_cmd()
-> virtscsi_add_cmd()
-> virtqueue_add_sgs()
-> virtqueue_add()
if success
return 0
elseif vq->broken or vring_mapping_error()
return -EIO
else
return -ENOSPC
A return of ENOSPC is generally a temporary condition, so returning
"host busy" from virtscsi_queuecommand makes sense here, to have it
redriven in a moment or two. But the EIO return code is more of a
permanent error and so it would be wise to return the I/O itself and
allow the calling thread to finish gracefully. The result is these four
kernel messages in the guest (the fourth one does not occur prior to
this patch):
[ 22.921562] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0, erc=4, rsid=2
[ 22.921580] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0, erc=4, rsid=0
[ 22.921978] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 22.921993] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
I opted to fill in the same response data that is returned from the more
graceful device detach, where the disk device is removed prior to the
controller device.
Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-01-13 10:48:06 -07:00
|
|
|
int ret;
|
2014-05-01 08:51:50 -06:00
|
|
|
|
2012-06-13 08:56:34 -06:00
|
|
|
BUG_ON(scsi_sg_count(sc) > shost->sg_tablesize);
|
|
|
|
|
|
|
|
/* TODO: check feature bit and fail if unsupported? */
|
|
|
|
BUG_ON(sc->sc_data_direction == DMA_BIDIRECTIONAL);
|
|
|
|
|
2012-02-05 04:16:00 -07:00
|
|
|
dev_dbg(&sc->device->sdev_gendev,
|
|
|
|
"cmd %p CDB: %#02x\n", sc, sc->cmnd[0]);
|
|
|
|
|
|
|
|
cmd->sc = sc;
|
|
|
|
|
|
|
|
BUG_ON(sc->cmd_len > VIRTIO_SCSI_CDB_SIZE);
|
|
|
|
|
2015-04-27 06:56:14 -06:00
|
|
|
#ifdef CONFIG_BLK_DEV_INTEGRITY
|
2014-02-22 19:23:33 -07:00
|
|
|
if (virtio_has_feature(vscsi->vdev, VIRTIO_SCSI_F_T10_PI)) {
|
2014-11-23 08:28:57 -07:00
|
|
|
virtio_scsi_init_hdr_pi(vscsi->vdev, &cmd->req.cmd_pi, sc);
|
2014-02-22 19:23:33 -07:00
|
|
|
memcpy(cmd->req.cmd_pi.cdb, sc->cmnd, sc->cmd_len);
|
|
|
|
req_size = sizeof(cmd->req.cmd_pi);
|
2015-04-27 06:56:14 -06:00
|
|
|
} else
|
|
|
|
#endif
|
|
|
|
{
|
2014-11-23 08:28:57 -07:00
|
|
|
virtio_scsi_init_hdr(vscsi->vdev, &cmd->req.cmd, sc);
|
2014-02-22 19:23:33 -07:00
|
|
|
memcpy(cmd->req.cmd.cdb, sc->cmnd, sc->cmd_len);
|
|
|
|
req_size = sizeof(cmd->req.cmd);
|
|
|
|
}
|
|
|
|
|
scsi: virtio_scsi: Reject commands when virtqueue is broken
In the case of a graceful set of detaches, where the virtio-scsi-ccw
disk is removed from the guest prior to the controller, the guest
behaves quite normally. Specifically, the detach gets us into
sd_sync_cache to issue a Synchronize Cache(10) command, which
immediately fails (and is retried a couple of times) because the device
has been removed. Later, the removal of the controller sees two CRWs
presented, but there's no further indication of the removal from the
guest viewpoint.
[ 17.217458] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 17.219257] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 21.449400] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0, erc=4, rsid=2
[ 21.449406] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0, erc=4, rsid=0
However, on s390, the SCSI disks can be removed "by surprise" when an
entire controller (host) is removed and all associated disks are removed
via the loop in scsi_forget_host. The same call to sd_sync_cache is
made, but because the controller has already been removed, the
Synchronize Cache(10) command is neither issued (and then failed) nor
rejected.
That the I/O isn't returned means the guest cannot have other devices
added nor removed, and other tasks (such as shutdown or reboot) issued
by the guest will not complete either. The virtio ring has already been
marked as broken (via virtio_break_device in virtio_ccw_remove), but we
still attempt to queue the command only to have it remain there. The
calling sequence provides a bit of distinction for us:
virtscsi_queuecommand()
-> virtscsi_kick_cmd()
-> virtscsi_add_cmd()
-> virtqueue_add_sgs()
-> virtqueue_add()
if success
return 0
elseif vq->broken or vring_mapping_error()
return -EIO
else
return -ENOSPC
A return of ENOSPC is generally a temporary condition, so returning
"host busy" from virtscsi_queuecommand makes sense here, to have it
redriven in a moment or two. But the EIO return code is more of a
permanent error and so it would be wise to return the I/O itself and
allow the calling thread to finish gracefully. The result is these four
kernel messages in the guest (the fourth one does not occur prior to
this patch):
[ 22.921562] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0, erc=4, rsid=2
[ 22.921580] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0, erc=4, rsid=0
[ 22.921978] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 22.921993] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
I opted to fill in the same response data that is returned from the more
graceful device detach, where the disk device is removed prior to the
controller device.
Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-01-13 10:48:06 -07:00
|
|
|
ret = virtscsi_kick_cmd(req_vq, cmd, req_size, sizeof(cmd->resp.cmd));
|
|
|
|
if (ret == -EIO) {
|
|
|
|
cmd->resp.cmd.response = VIRTIO_SCSI_S_BAD_TARGET;
|
|
|
|
spin_lock_irqsave(&req_vq->vq_lock, flags);
|
|
|
|
virtscsi_complete_cmd(vscsi, cmd);
|
|
|
|
spin_unlock_irqrestore(&req_vq->vq_lock, flags);
|
|
|
|
} else if (ret != 0) {
|
2014-05-01 08:51:50 -06:00
|
|
|
return SCSI_MLQUEUE_HOST_BUSY;
|
scsi: virtio_scsi: Reject commands when virtqueue is broken
In the case of a graceful set of detaches, where the virtio-scsi-ccw
disk is removed from the guest prior to the controller, the guest
behaves quite normally. Specifically, the detach gets us into
sd_sync_cache to issue a Synchronize Cache(10) command, which
immediately fails (and is retried a couple of times) because the device
has been removed. Later, the removal of the controller sees two CRWs
presented, but there's no further indication of the removal from the
guest viewpoint.
[ 17.217458] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 17.219257] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 21.449400] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0, erc=4, rsid=2
[ 21.449406] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0, erc=4, rsid=0
However, on s390, the SCSI disks can be removed "by surprise" when an
entire controller (host) is removed and all associated disks are removed
via the loop in scsi_forget_host. The same call to sd_sync_cache is
made, but because the controller has already been removed, the
Synchronize Cache(10) command is neither issued (and then failed) nor
rejected.
That the I/O isn't returned means the guest cannot have other devices
added nor removed, and other tasks (such as shutdown or reboot) issued
by the guest will not complete either. The virtio ring has already been
marked as broken (via virtio_break_device in virtio_ccw_remove), but we
still attempt to queue the command only to have it remain there. The
calling sequence provides a bit of distinction for us:
virtscsi_queuecommand()
-> virtscsi_kick_cmd()
-> virtscsi_add_cmd()
-> virtqueue_add_sgs()
-> virtqueue_add()
if success
return 0
elseif vq->broken or vring_mapping_error()
return -EIO
else
return -ENOSPC
A return of ENOSPC is generally a temporary condition, so returning
"host busy" from virtscsi_queuecommand makes sense here, to have it
redriven in a moment or two. But the EIO return code is more of a
permanent error and so it would be wise to return the I/O itself and
allow the calling thread to finish gracefully. The result is these four
kernel messages in the guest (the fourth one does not occur prior to
this patch):
[ 22.921562] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0, erc=4, rsid=2
[ 22.921580] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0, erc=4, rsid=0
[ 22.921978] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 22.921993] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
I opted to fill in the same response data that is returned from the more
graceful device detach, where the disk device is removed prior to the
controller device.
Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-01-13 10:48:06 -07:00
|
|
|
}
|
2014-05-01 08:51:50 -06:00
|
|
|
return 0;
|
2012-02-05 04:16:00 -07:00
|
|
|
}
|
|
|
|
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
static int virtscsi_queuecommand_single(struct Scsi_Host *sh,
|
|
|
|
struct scsi_cmnd *sc)
|
|
|
|
{
|
|
|
|
struct virtio_scsi *vscsi = shost_priv(sh);
|
|
|
|
struct virtio_scsi_target_state *tgt =
|
|
|
|
scsi_target(sc->device)->hostdata;
|
|
|
|
|
|
|
|
atomic_inc(&tgt->reqs);
|
|
|
|
return virtscsi_queuecommand(vscsi, &vscsi->req_vqs[0], sc);
|
|
|
|
}
|
|
|
|
|
2014-11-14 20:47:14 -07:00
|
|
|
static struct virtio_scsi_vq *virtscsi_pick_vq_mq(struct virtio_scsi *vscsi,
|
|
|
|
struct scsi_cmnd *sc)
|
|
|
|
{
|
|
|
|
u32 tag = blk_mq_unique_tag(sc->request);
|
|
|
|
u16 hwq = blk_mq_unique_tag_to_hwq(tag);
|
|
|
|
|
|
|
|
return &vscsi->req_vqs[hwq];
|
|
|
|
}
|
|
|
|
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
static struct virtio_scsi_vq *virtscsi_pick_vq(struct virtio_scsi *vscsi,
|
|
|
|
struct virtio_scsi_target_state *tgt)
|
|
|
|
{
|
|
|
|
struct virtio_scsi_vq *vq;
|
|
|
|
unsigned long flags;
|
|
|
|
u32 queue_num;
|
|
|
|
|
2014-07-06 08:39:26 -06:00
|
|
|
local_irq_save(flags);
|
|
|
|
if (atomic_inc_return(&tgt->reqs) > 1) {
|
|
|
|
unsigned long seq;
|
|
|
|
|
|
|
|
do {
|
|
|
|
seq = read_seqcount_begin(&tgt->tgt_seq);
|
|
|
|
vq = tgt->req_vq;
|
|
|
|
} while (read_seqcount_retry(&tgt->tgt_seq, seq));
|
|
|
|
} else {
|
|
|
|
/* no writes can be concurrent because of atomic_t */
|
|
|
|
write_seqcount_begin(&tgt->tgt_seq);
|
|
|
|
|
|
|
|
/* keep previous req_vq if a reader just arrived */
|
|
|
|
if (unlikely(atomic_read(&tgt->reqs) > 1)) {
|
|
|
|
vq = tgt->req_vq;
|
|
|
|
goto unlock;
|
|
|
|
}
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
|
|
|
|
queue_num = smp_processor_id();
|
|
|
|
while (unlikely(queue_num >= vscsi->num_queues))
|
|
|
|
queue_num -= vscsi->num_queues;
|
|
|
|
tgt->req_vq = vq = &vscsi->req_vqs[queue_num];
|
2014-07-06 08:39:26 -06:00
|
|
|
unlock:
|
|
|
|
write_seqcount_end(&tgt->tgt_seq);
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
}
|
2014-07-06 08:39:26 -06:00
|
|
|
local_irq_restore(flags);
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
|
|
|
|
return vq;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int virtscsi_queuecommand_multi(struct Scsi_Host *sh,
|
|
|
|
struct scsi_cmnd *sc)
|
|
|
|
{
|
|
|
|
struct virtio_scsi *vscsi = shost_priv(sh);
|
|
|
|
struct virtio_scsi_target_state *tgt =
|
|
|
|
scsi_target(sc->device)->hostdata;
|
2014-11-14 20:47:14 -07:00
|
|
|
struct virtio_scsi_vq *req_vq;
|
|
|
|
|
|
|
|
if (shost_use_blk_mq(sh))
|
|
|
|
req_vq = virtscsi_pick_vq_mq(vscsi, sc);
|
|
|
|
else
|
|
|
|
req_vq = virtscsi_pick_vq(vscsi, tgt);
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
|
|
|
|
return virtscsi_queuecommand(vscsi, req_vq, sc);
|
|
|
|
}
|
|
|
|
|
2012-02-05 04:16:00 -07:00
|
|
|
static int virtscsi_tmf(struct virtio_scsi *vscsi, struct virtio_scsi_cmd *cmd)
|
|
|
|
{
|
|
|
|
DECLARE_COMPLETION_ONSTACK(comp);
|
2012-05-04 04:32:04 -06:00
|
|
|
int ret = FAILED;
|
2012-02-05 04:16:00 -07:00
|
|
|
|
|
|
|
cmd->comp = ∁
|
2013-03-19 23:14:28 -06:00
|
|
|
if (virtscsi_kick_cmd(&vscsi->ctrl_vq, cmd,
|
2014-05-20 19:55:04 -06:00
|
|
|
sizeof cmd->req.tmf, sizeof cmd->resp.tmf) < 0)
|
2012-05-04 04:32:04 -06:00
|
|
|
goto out;
|
2012-02-05 04:16:00 -07:00
|
|
|
|
|
|
|
wait_for_completion(&comp);
|
2012-05-04 04:32:04 -06:00
|
|
|
if (cmd->resp.tmf.response == VIRTIO_SCSI_S_OK ||
|
|
|
|
cmd->resp.tmf.response == VIRTIO_SCSI_S_FUNCTION_SUCCEEDED)
|
|
|
|
ret = SUCCESS;
|
2012-02-05 04:16:00 -07:00
|
|
|
|
2014-06-04 05:34:58 -06:00
|
|
|
/*
|
|
|
|
* The spec guarantees that all requests related to the TMF have
|
|
|
|
* been completed, but the callback might not have run yet if
|
|
|
|
* we're using independent interrupts (e.g. MSI). Poll the
|
|
|
|
* virtqueues once.
|
|
|
|
*
|
|
|
|
* In the abort case, sc->scsi_done will do nothing, because
|
|
|
|
* the block layer must have detected a timeout and as a result
|
|
|
|
* REQ_ATOM_COMPLETE has been set.
|
|
|
|
*/
|
|
|
|
virtscsi_poll_requests(vscsi);
|
|
|
|
|
2012-05-04 04:32:04 -06:00
|
|
|
out:
|
|
|
|
mempool_free(cmd, virtscsi_cmd_pool);
|
|
|
|
return ret;
|
2012-02-05 04:16:00 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int virtscsi_device_reset(struct scsi_cmnd *sc)
|
|
|
|
{
|
|
|
|
struct virtio_scsi *vscsi = shost_priv(sc->device->host);
|
|
|
|
struct virtio_scsi_cmd *cmd;
|
|
|
|
|
|
|
|
sdev_printk(KERN_INFO, sc->device, "device reset\n");
|
|
|
|
cmd = mempool_alloc(virtscsi_cmd_pool, GFP_NOIO);
|
|
|
|
if (!cmd)
|
|
|
|
return FAILED;
|
|
|
|
|
|
|
|
memset(cmd, 0, sizeof(*cmd));
|
|
|
|
cmd->sc = sc;
|
|
|
|
cmd->req.tmf = (struct virtio_scsi_ctrl_tmf_req){
|
|
|
|
.type = VIRTIO_SCSI_T_TMF,
|
2014-11-23 08:28:57 -07:00
|
|
|
.subtype = cpu_to_virtio32(vscsi->vdev,
|
|
|
|
VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET),
|
2012-02-05 04:16:00 -07:00
|
|
|
.lun[0] = 1,
|
|
|
|
.lun[1] = sc->device->id,
|
|
|
|
.lun[2] = (sc->device->lun >> 8) | 0x40,
|
|
|
|
.lun[3] = sc->device->lun & 0xff,
|
|
|
|
};
|
|
|
|
return virtscsi_tmf(vscsi, cmd);
|
|
|
|
}
|
|
|
|
|
2017-04-12 20:13:00 -06:00
|
|
|
static int virtscsi_device_alloc(struct scsi_device *sdevice)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Passed through SCSI targets (e.g. with qemu's 'scsi-block')
|
|
|
|
* may have transfer limits which come from the host SCSI
|
|
|
|
* controller or something on the host side other than the
|
|
|
|
* target itself.
|
|
|
|
*
|
|
|
|
* To make this work properly, the hypervisor can adjust the
|
|
|
|
* target's VPD information to advertise these limits. But
|
|
|
|
* for that to work, the guest has to look at the VPD pages,
|
|
|
|
* which we won't do by default if it is an SPC-2 device, even
|
|
|
|
* if it does actually support it.
|
|
|
|
*
|
|
|
|
* So, set the blist to always try to read the VPD pages.
|
|
|
|
*/
|
|
|
|
sdevice->sdev_bflags = BLIST_TRY_VPD_PAGES;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-07-06 08:39:27 -06:00
|
|
|
/**
|
|
|
|
* virtscsi_change_queue_depth() - Change a virtscsi target's queue depth
|
|
|
|
* @sdev: Virtscsi target whose queue depth to change
|
|
|
|
* @qdepth: New queue depth
|
|
|
|
*/
|
2014-11-13 07:08:42 -07:00
|
|
|
static int virtscsi_change_queue_depth(struct scsi_device *sdev, int qdepth)
|
2014-07-06 08:39:27 -06:00
|
|
|
{
|
|
|
|
struct Scsi_Host *shost = sdev->host;
|
|
|
|
int max_depth = shost->cmd_per_lun;
|
|
|
|
|
2014-11-13 07:08:42 -07:00
|
|
|
return scsi_change_queue_depth(sdev, min(max_depth, qdepth));
|
2014-07-06 08:39:27 -06:00
|
|
|
}
|
|
|
|
|
2012-02-05 04:16:00 -07:00
|
|
|
static int virtscsi_abort(struct scsi_cmnd *sc)
|
|
|
|
{
|
|
|
|
struct virtio_scsi *vscsi = shost_priv(sc->device->host);
|
|
|
|
struct virtio_scsi_cmd *cmd;
|
|
|
|
|
|
|
|
scmd_printk(KERN_INFO, sc, "abort\n");
|
|
|
|
cmd = mempool_alloc(virtscsi_cmd_pool, GFP_NOIO);
|
|
|
|
if (!cmd)
|
|
|
|
return FAILED;
|
|
|
|
|
|
|
|
memset(cmd, 0, sizeof(*cmd));
|
|
|
|
cmd->sc = sc;
|
|
|
|
cmd->req.tmf = (struct virtio_scsi_ctrl_tmf_req){
|
|
|
|
.type = VIRTIO_SCSI_T_TMF,
|
|
|
|
.subtype = VIRTIO_SCSI_T_TMF_ABORT_TASK,
|
|
|
|
.lun[0] = 1,
|
|
|
|
.lun[1] = sc->device->id,
|
|
|
|
.lun[2] = (sc->device->lun >> 8) | 0x40,
|
|
|
|
.lun[3] = sc->device->lun & 0xff,
|
2014-11-23 08:28:57 -07:00
|
|
|
.tag = cpu_to_virtio64(vscsi->vdev, (unsigned long)sc),
|
2012-02-05 04:16:00 -07:00
|
|
|
};
|
|
|
|
return virtscsi_tmf(vscsi, cmd);
|
|
|
|
}
|
|
|
|
|
2013-04-08 07:31:16 -06:00
|
|
|
static int virtscsi_target_alloc(struct scsi_target *starget)
|
|
|
|
{
|
2014-07-06 08:39:26 -06:00
|
|
|
struct Scsi_Host *sh = dev_to_shost(starget->dev.parent);
|
|
|
|
struct virtio_scsi *vscsi = shost_priv(sh);
|
|
|
|
|
2013-04-08 07:31:16 -06:00
|
|
|
struct virtio_scsi_target_state *tgt =
|
|
|
|
kmalloc(sizeof(*tgt), GFP_KERNEL);
|
|
|
|
if (!tgt)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2014-07-06 08:39:26 -06:00
|
|
|
seqcount_init(&tgt->tgt_seq);
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
atomic_set(&tgt->reqs, 0);
|
2014-07-06 08:39:26 -06:00
|
|
|
tgt->req_vq = &vscsi->req_vqs[0];
|
2013-04-08 07:31:16 -06:00
|
|
|
|
|
|
|
starget->hostdata = tgt;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void virtscsi_target_destroy(struct scsi_target *starget)
|
|
|
|
{
|
|
|
|
struct virtio_scsi_target_state *tgt = starget->hostdata;
|
|
|
|
kfree(tgt);
|
|
|
|
}
|
|
|
|
|
2017-02-05 10:15:26 -07:00
|
|
|
static int virtscsi_map_queues(struct Scsi_Host *shost)
|
|
|
|
{
|
|
|
|
struct virtio_scsi *vscsi = shost_priv(shost);
|
|
|
|
|
|
|
|
return blk_mq_virtio_map_queues(&shost->tag_set, vscsi->vdev, 2);
|
|
|
|
}
|
|
|
|
|
2017-06-21 08:35:46 -06:00
|
|
|
/*
|
|
|
|
* The host guarantees to respond to each command, although I/O
|
|
|
|
* latencies might be higher than on bare metal. Reset the timer
|
|
|
|
* unconditionally to give the host a chance to perform EH.
|
|
|
|
*/
|
|
|
|
static enum blk_eh_timer_return virtscsi_eh_timed_out(struct scsi_cmnd *scmnd)
|
|
|
|
{
|
|
|
|
return BLK_EH_RESET_TIMER;
|
|
|
|
}
|
|
|
|
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
static struct scsi_host_template virtscsi_host_template_single = {
|
|
|
|
.module = THIS_MODULE,
|
|
|
|
.name = "Virtio SCSI HBA",
|
|
|
|
.proc_name = "virtio_scsi",
|
|
|
|
.this_id = -1,
|
2014-05-01 08:51:50 -06:00
|
|
|
.cmd_size = sizeof(struct virtio_scsi_cmd),
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
.queuecommand = virtscsi_queuecommand_single,
|
2014-07-06 08:39:27 -06:00
|
|
|
.change_queue_depth = virtscsi_change_queue_depth,
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
.eh_abort_handler = virtscsi_abort,
|
|
|
|
.eh_device_reset_handler = virtscsi_device_reset,
|
2017-06-21 08:35:46 -06:00
|
|
|
.eh_timed_out = virtscsi_eh_timed_out,
|
2017-04-12 20:13:00 -06:00
|
|
|
.slave_alloc = virtscsi_device_alloc,
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
|
|
|
|
.can_queue = 1024,
|
|
|
|
.dma_boundary = UINT_MAX,
|
|
|
|
.use_clustering = ENABLE_CLUSTERING,
|
|
|
|
.target_alloc = virtscsi_target_alloc,
|
|
|
|
.target_destroy = virtscsi_target_destroy,
|
2014-11-13 06:25:11 -07:00
|
|
|
.track_queue_depth = 1,
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
};
|
|
|
|
|
|
|
|
static struct scsi_host_template virtscsi_host_template_multi = {
|
2012-02-05 04:16:00 -07:00
|
|
|
.module = THIS_MODULE,
|
|
|
|
.name = "Virtio SCSI HBA",
|
|
|
|
.proc_name = "virtio_scsi",
|
|
|
|
.this_id = -1,
|
2014-05-01 08:51:50 -06:00
|
|
|
.cmd_size = sizeof(struct virtio_scsi_cmd),
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
.queuecommand = virtscsi_queuecommand_multi,
|
2014-07-06 08:39:27 -06:00
|
|
|
.change_queue_depth = virtscsi_change_queue_depth,
|
2012-02-05 04:16:00 -07:00
|
|
|
.eh_abort_handler = virtscsi_abort,
|
|
|
|
.eh_device_reset_handler = virtscsi_device_reset,
|
2017-06-21 08:35:46 -06:00
|
|
|
.eh_timed_out = virtscsi_eh_timed_out,
|
2017-07-05 02:30:56 -06:00
|
|
|
.slave_alloc = virtscsi_device_alloc,
|
2012-02-05 04:16:00 -07:00
|
|
|
|
|
|
|
.can_queue = 1024,
|
|
|
|
.dma_boundary = UINT_MAX,
|
|
|
|
.use_clustering = ENABLE_CLUSTERING,
|
2013-04-08 07:31:16 -06:00
|
|
|
.target_alloc = virtscsi_target_alloc,
|
|
|
|
.target_destroy = virtscsi_target_destroy,
|
2017-02-05 10:15:26 -07:00
|
|
|
.map_queues = virtscsi_map_queues,
|
2014-11-13 06:25:11 -07:00
|
|
|
.track_queue_depth = 1,
|
2012-02-05 04:16:00 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
#define virtscsi_config_get(vdev, fld) \
|
|
|
|
({ \
|
|
|
|
typeof(((struct virtio_scsi_config *)0)->fld) __val; \
|
2013-10-14 01:41:51 -06:00
|
|
|
virtio_cread(vdev, struct virtio_scsi_config, fld, &__val); \
|
2012-02-05 04:16:00 -07:00
|
|
|
__val; \
|
|
|
|
})
|
|
|
|
|
|
|
|
#define virtscsi_config_set(vdev, fld, val) \
|
2013-10-14 01:41:51 -06:00
|
|
|
do { \
|
2012-02-05 04:16:00 -07:00
|
|
|
typeof(((struct virtio_scsi_config *)0)->fld) __val = (val); \
|
2013-10-14 01:41:51 -06:00
|
|
|
virtio_cwrite(vdev, struct virtio_scsi_config, fld, &__val); \
|
|
|
|
} while(0)
|
2012-02-05 04:16:00 -07:00
|
|
|
|
2012-06-13 08:56:32 -06:00
|
|
|
static void virtscsi_init_vq(struct virtio_scsi_vq *virtscsi_vq,
|
|
|
|
struct virtqueue *vq)
|
|
|
|
{
|
|
|
|
spin_lock_init(&virtscsi_vq->vq_lock);
|
|
|
|
virtscsi_vq->vq = vq;
|
|
|
|
}
|
|
|
|
|
2012-06-13 08:56:34 -06:00
|
|
|
static void virtscsi_remove_vqs(struct virtio_device *vdev)
|
|
|
|
{
|
|
|
|
/* Stop all the virtqueues. */
|
|
|
|
vdev->config->reset(vdev);
|
|
|
|
vdev->config->del_vqs(vdev);
|
|
|
|
}
|
|
|
|
|
2012-02-05 04:16:00 -07:00
|
|
|
static int virtscsi_init(struct virtio_device *vdev,
|
2013-04-08 07:31:16 -06:00
|
|
|
struct virtio_scsi *vscsi)
|
2012-02-05 04:16:00 -07:00
|
|
|
{
|
|
|
|
int err;
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
u32 i;
|
|
|
|
u32 num_vqs;
|
|
|
|
vq_callback_t **callbacks;
|
|
|
|
const char **names;
|
|
|
|
struct virtqueue **vqs;
|
2017-02-05 10:15:26 -07:00
|
|
|
struct irq_affinity desc = { .pre_vectors = 2 };
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
|
|
|
|
num_vqs = vscsi->num_queues + VIRTIO_SCSI_VQ_BASE;
|
|
|
|
vqs = kmalloc(num_vqs * sizeof(struct virtqueue *), GFP_KERNEL);
|
|
|
|
callbacks = kmalloc(num_vqs * sizeof(vq_callback_t *), GFP_KERNEL);
|
|
|
|
names = kmalloc(num_vqs * sizeof(char *), GFP_KERNEL);
|
|
|
|
|
|
|
|
if (!callbacks || !vqs || !names) {
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto out;
|
|
|
|
}
|
2012-06-13 08:56:34 -06:00
|
|
|
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
callbacks[0] = virtscsi_ctrl_done;
|
|
|
|
callbacks[1] = virtscsi_event_done;
|
|
|
|
names[0] = "control";
|
|
|
|
names[1] = "event";
|
|
|
|
for (i = VIRTIO_SCSI_VQ_BASE; i < num_vqs; i++) {
|
|
|
|
callbacks[i] = virtscsi_req_done;
|
|
|
|
names[i] = "request";
|
|
|
|
}
|
2012-02-05 04:16:00 -07:00
|
|
|
|
|
|
|
/* Discover virtqueues and write information to configuration. */
|
2017-03-06 09:19:39 -07:00
|
|
|
err = virtio_find_vqs(vdev, num_vqs, vqs, callbacks, names, &desc);
|
2012-02-05 04:16:00 -07:00
|
|
|
if (err)
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
goto out;
|
2012-02-05 04:16:00 -07:00
|
|
|
|
2012-06-13 08:56:32 -06:00
|
|
|
virtscsi_init_vq(&vscsi->ctrl_vq, vqs[0]);
|
|
|
|
virtscsi_init_vq(&vscsi->event_vq, vqs[1]);
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
for (i = VIRTIO_SCSI_VQ_BASE; i < num_vqs; i++)
|
|
|
|
virtscsi_init_vq(&vscsi->req_vqs[i - VIRTIO_SCSI_VQ_BASE],
|
|
|
|
vqs[i]);
|
|
|
|
|
2012-02-05 04:16:00 -07:00
|
|
|
virtscsi_config_set(vdev, cdb_size, VIRTIO_SCSI_CDB_SIZE);
|
|
|
|
virtscsi_config_set(vdev, sense_size, VIRTIO_SCSI_SENSE_SIZE);
|
2012-06-13 08:56:34 -06:00
|
|
|
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
err = 0;
|
|
|
|
|
|
|
|
out:
|
|
|
|
kfree(names);
|
|
|
|
kfree(callbacks);
|
|
|
|
kfree(vqs);
|
|
|
|
if (err)
|
|
|
|
virtscsi_remove_vqs(vdev);
|
2012-06-13 08:56:34 -06:00
|
|
|
return err;
|
2012-02-05 04:16:00 -07:00
|
|
|
}
|
|
|
|
|
2012-12-21 14:08:55 -07:00
|
|
|
static int virtscsi_probe(struct virtio_device *vdev)
|
2012-02-05 04:16:00 -07:00
|
|
|
{
|
|
|
|
struct Scsi_Host *shost;
|
|
|
|
struct virtio_scsi *vscsi;
|
2015-06-29 18:59:04 -06:00
|
|
|
int err;
|
2012-06-13 08:56:34 -06:00
|
|
|
u32 sg_elems, num_targets;
|
2012-02-05 04:16:00 -07:00
|
|
|
u32 cmd_per_lun;
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
u32 num_queues;
|
|
|
|
struct scsi_host_template *hostt;
|
|
|
|
|
2015-01-12 07:23:37 -07:00
|
|
|
if (!vdev->config->get) {
|
|
|
|
dev_err(&vdev->dev, "%s failure: config access disabled\n",
|
|
|
|
__func__);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
/* We need to know how many queues before we allocate. */
|
|
|
|
num_queues = virtscsi_config_get(vdev, num_queues) ? : 1;
|
2012-02-05 04:16:00 -07:00
|
|
|
|
2012-06-13 08:56:34 -06:00
|
|
|
num_targets = virtscsi_config_get(vdev, max_target) + 1;
|
2012-02-05 04:16:00 -07:00
|
|
|
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
if (num_queues == 1)
|
|
|
|
hostt = &virtscsi_host_template_single;
|
|
|
|
else
|
|
|
|
hostt = &virtscsi_host_template_multi;
|
|
|
|
|
|
|
|
shost = scsi_host_alloc(hostt,
|
|
|
|
sizeof(*vscsi) + sizeof(vscsi->req_vqs[0]) * num_queues);
|
2012-02-05 04:16:00 -07:00
|
|
|
if (!shost)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2012-06-13 08:56:34 -06:00
|
|
|
sg_elems = virtscsi_config_get(vdev, seg_max) ?: 1;
|
2012-02-05 04:16:00 -07:00
|
|
|
shost->sg_tablesize = sg_elems;
|
|
|
|
vscsi = shost_priv(shost);
|
|
|
|
vscsi->vdev = vdev;
|
virtio-scsi: introduce multiqueue support
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU, so the driver expects the number of request queues to be
equal to the number of VCPUs. This makes it easy and fast to select
the queue, and also lets the driver optimize the IRQ affinity for the
virtqueues (each virtqueue's affinity is set to the CPU that "owns"
the queue).
The speedup comes from improving cache locality and giving CPU affinity
to the virtqueues, which is why this scheme was selected. Assuming that
the thread that is sending requests to the device is I/O-bound, it is
likely to be sleeping at the time the ISR is executed, and thus executing
the ISR on the same processor that sent the requests is cheap.
However, the kernel will not execute the ISR on the "best" processor
unless you explicitly set the affinity. This is because in practice
you will have many such I/O-bound processes and thus many otherwise
idle processors. Then the kernel will execute the ISR on a random
processor, rather than the one that is sending requests to the device.
The alternative to per-CPU virtqueues is per-target virtqueues. To
achieve the same locality, we could dynamically choose the virtqueue's
affinity based on the CPU of the last task that sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: Asias He <asias@redhat.com>
Tested-by: Venkatesh Srinivas <venkateshs@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2013-04-08 07:33:25 -06:00
|
|
|
vscsi->num_queues = num_queues;
|
2012-02-05 04:16:00 -07:00
|
|
|
vdev->priv = shost;
|
|
|
|
|
2013-04-08 07:31:16 -06:00
|
|
|
err = virtscsi_init(vdev, vscsi);
|
2012-02-05 04:16:00 -07:00
|
|
|
if (err)
|
|
|
|
goto virtscsi_init_failed;
|
|
|
|
|
|
|
|
cmd_per_lun = virtscsi_config_get(vdev, cmd_per_lun) ?: 1;
|
|
|
|
shost->cmd_per_lun = min_t(u32, cmd_per_lun, shost->can_queue);
|
|
|
|
shost->max_sectors = virtscsi_config_get(vdev, max_sectors) ?: 0xFFFF;
|
2012-10-02 09:25:47 -06:00
|
|
|
|
|
|
|
/* LUNs > 256 are reported with format 1, so they go in the range
|
|
|
|
* 16640-32767.
|
|
|
|
*/
|
|
|
|
shost->max_lun = virtscsi_config_get(vdev, max_lun) + 1 + 0x4000;
|
2012-06-13 08:56:34 -06:00
|
|
|
shost->max_id = num_targets;
|
2012-02-05 04:16:00 -07:00
|
|
|
shost->max_channel = 0;
|
|
|
|
shost->max_cmd_len = VIRTIO_SCSI_CDB_SIZE;
|
2014-11-14 20:47:14 -07:00
|
|
|
shost->nr_hw_queues = num_queues;
|
2014-02-22 19:23:33 -07:00
|
|
|
|
2015-04-27 06:56:14 -06:00
|
|
|
#ifdef CONFIG_BLK_DEV_INTEGRITY
|
2014-02-22 19:23:33 -07:00
|
|
|
if (virtio_has_feature(vdev, VIRTIO_SCSI_F_T10_PI)) {
|
2015-06-29 18:59:04 -06:00
|
|
|
int host_prot;
|
|
|
|
|
2014-02-22 19:23:33 -07:00
|
|
|
host_prot = SHOST_DIF_TYPE1_PROTECTION | SHOST_DIF_TYPE2_PROTECTION |
|
|
|
|
SHOST_DIF_TYPE3_PROTECTION | SHOST_DIX_TYPE1_PROTECTION |
|
|
|
|
SHOST_DIX_TYPE2_PROTECTION | SHOST_DIX_TYPE3_PROTECTION;
|
|
|
|
|
|
|
|
scsi_host_set_prot(shost, host_prot);
|
|
|
|
scsi_host_set_guard(shost, SHOST_DIX_GUARD_CRC);
|
|
|
|
}
|
2015-04-27 06:56:14 -06:00
|
|
|
#endif
|
2014-02-22 19:23:33 -07:00
|
|
|
|
2012-02-05 04:16:00 -07:00
|
|
|
err = scsi_add_host(shost, &vdev->dev);
|
|
|
|
if (err)
|
|
|
|
goto scsi_add_host_failed;
|
2014-10-14 17:52:33 -06:00
|
|
|
|
|
|
|
virtio_device_ready(vdev);
|
|
|
|
|
|
|
|
if (virtio_has_feature(vdev, VIRTIO_SCSI_F_HOTPLUG))
|
|
|
|
virtscsi_kick_event_all(vscsi);
|
|
|
|
|
|
|
|
scsi_scan_host(shost);
|
2012-02-05 04:16:00 -07:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
scsi_add_host_failed:
|
|
|
|
vdev->config->del_vqs(vdev);
|
|
|
|
virtscsi_init_failed:
|
|
|
|
scsi_host_put(shost);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2012-12-21 14:08:55 -07:00
|
|
|
static void virtscsi_remove(struct virtio_device *vdev)
|
2012-02-05 04:16:00 -07:00
|
|
|
{
|
|
|
|
struct Scsi_Host *shost = virtio_scsi_host(vdev);
|
2012-07-05 03:06:43 -06:00
|
|
|
struct virtio_scsi *vscsi = shost_priv(shost);
|
|
|
|
|
|
|
|
if (virtio_has_feature(vdev, VIRTIO_SCSI_F_HOTPLUG))
|
|
|
|
virtscsi_cancel_event_work(vscsi);
|
2012-02-05 04:16:00 -07:00
|
|
|
|
|
|
|
scsi_remove_host(shost);
|
|
|
|
virtscsi_remove_vqs(vdev);
|
|
|
|
scsi_host_put(shost);
|
|
|
|
}
|
|
|
|
|
2013-09-16 17:55:23 -06:00
|
|
|
#ifdef CONFIG_PM_SLEEP
|
2012-02-05 04:16:00 -07:00
|
|
|
static int virtscsi_freeze(struct virtio_device *vdev)
|
|
|
|
{
|
|
|
|
virtscsi_remove_vqs(vdev);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int virtscsi_restore(struct virtio_device *vdev)
|
|
|
|
{
|
|
|
|
struct Scsi_Host *sh = virtio_scsi_host(vdev);
|
|
|
|
struct virtio_scsi *vscsi = shost_priv(sh);
|
2014-01-15 16:48:48 -07:00
|
|
|
int err;
|
|
|
|
|
|
|
|
err = virtscsi_init(vdev, vscsi);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2014-10-14 17:52:32 -06:00
|
|
|
virtio_device_ready(vdev);
|
|
|
|
|
2014-10-14 17:52:31 -06:00
|
|
|
if (virtio_has_feature(vdev, VIRTIO_SCSI_F_HOTPLUG))
|
|
|
|
virtscsi_kick_event_all(vscsi);
|
2012-02-05 04:16:00 -07:00
|
|
|
|
2014-01-15 16:48:48 -07:00
|
|
|
return err;
|
2012-02-05 04:16:00 -07:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static struct virtio_device_id id_table[] = {
|
|
|
|
{ VIRTIO_ID_SCSI, VIRTIO_DEV_ANY_ID },
|
|
|
|
{ 0 },
|
|
|
|
};
|
|
|
|
|
2012-07-05 03:06:43 -06:00
|
|
|
static unsigned int features[] = {
|
2012-10-02 09:25:48 -06:00
|
|
|
VIRTIO_SCSI_F_HOTPLUG,
|
|
|
|
VIRTIO_SCSI_F_CHANGE,
|
2015-04-27 06:56:14 -06:00
|
|
|
#ifdef CONFIG_BLK_DEV_INTEGRITY
|
2014-02-22 19:23:33 -07:00
|
|
|
VIRTIO_SCSI_F_T10_PI,
|
2015-04-27 06:56:14 -06:00
|
|
|
#endif
|
2012-07-05 03:06:43 -06:00
|
|
|
};
|
|
|
|
|
2012-02-05 04:16:00 -07:00
|
|
|
static struct virtio_driver virtio_scsi_driver = {
|
2012-07-05 03:06:43 -06:00
|
|
|
.feature_table = features,
|
|
|
|
.feature_table_size = ARRAY_SIZE(features),
|
2012-02-05 04:16:00 -07:00
|
|
|
.driver.name = KBUILD_MODNAME,
|
|
|
|
.driver.owner = THIS_MODULE,
|
|
|
|
.id_table = id_table,
|
|
|
|
.probe = virtscsi_probe,
|
2013-09-16 17:55:23 -06:00
|
|
|
#ifdef CONFIG_PM_SLEEP
|
2012-02-05 04:16:00 -07:00
|
|
|
.freeze = virtscsi_freeze,
|
|
|
|
.restore = virtscsi_restore,
|
|
|
|
#endif
|
2012-12-21 14:08:55 -07:00
|
|
|
.remove = virtscsi_remove,
|
2012-02-05 04:16:00 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
static int __init init(void)
|
|
|
|
{
|
|
|
|
int ret = -ENOMEM;
|
|
|
|
|
|
|
|
virtscsi_cmd_cache = KMEM_CACHE(virtio_scsi_cmd, 0);
|
|
|
|
if (!virtscsi_cmd_cache) {
|
2013-03-11 23:04:40 -06:00
|
|
|
pr_err("kmem_cache_create() for virtscsi_cmd_cache failed\n");
|
2012-02-05 04:16:00 -07:00
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
virtscsi_cmd_pool =
|
|
|
|
mempool_create_slab_pool(VIRTIO_SCSI_MEMPOOL_SZ,
|
|
|
|
virtscsi_cmd_cache);
|
|
|
|
if (!virtscsi_cmd_pool) {
|
2013-03-11 23:04:40 -06:00
|
|
|
pr_err("mempool_create() for virtscsi_cmd_pool failed\n");
|
2012-02-05 04:16:00 -07:00
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
ret = register_virtio_driver(&virtio_scsi_driver);
|
|
|
|
if (ret < 0)
|
|
|
|
goto error;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
error:
|
|
|
|
if (virtscsi_cmd_pool) {
|
|
|
|
mempool_destroy(virtscsi_cmd_pool);
|
|
|
|
virtscsi_cmd_pool = NULL;
|
|
|
|
}
|
|
|
|
if (virtscsi_cmd_cache) {
|
|
|
|
kmem_cache_destroy(virtscsi_cmd_cache);
|
|
|
|
virtscsi_cmd_cache = NULL;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit fini(void)
|
|
|
|
{
|
|
|
|
unregister_virtio_driver(&virtio_scsi_driver);
|
|
|
|
mempool_destroy(virtscsi_cmd_pool);
|
|
|
|
kmem_cache_destroy(virtscsi_cmd_cache);
|
|
|
|
}
|
|
|
|
module_init(init);
|
|
|
|
module_exit(fini);
|
|
|
|
|
|
|
|
MODULE_DEVICE_TABLE(virtio, id_table);
|
|
|
|
MODULE_DESCRIPTION("Virtio SCSI HBA driver");
|
|
|
|
MODULE_LICENSE("GPL");
|