search for: scsi_cmds

On Wed, Mar 11, 2020 at 12:25:38AM +0800, John Garry wrote: > From: Hannes Reinecke <hare at suse.com> > > Enable the use of reserved commands, and drop the hand-crafted > command allocation. > > Signed-off-by: Hannes Reinecke <hare at suse.com> > --- > drivers/scsi/hpsa.c | 147 ++++++++++++++------------------------------ > drivers/scsi/hpsa.h | 1 -

On Tue, Sep 03, 2019 at 05:04:20PM +0000, Matt Lupfer wrote: > The event handler calls scsi_scan_host() when events are missed, which > will hotplug new LUNs. However, this function won't remove any > unplugged LUNs. The result is that hotunplug doesn't work properly when > the number of unplugged LUNs exceeds the event queue size (currently 8). > > Scan existing LUNs

...I_PREALLOC_SGLS 2048 > #define VHOST_SCSI_PREALLOC_UPAGES 2048 > #define VHOST_SCSI_PREALLOC_PROT_SGLS 2048 > @@ -189,6 +188,9 @@ struct vhost_scsi_virtqueue { > * Writers must also take dev mutex and flush under it. > */ > int inflight_idx; > + struct vhost_scsi_cmd *scsi_cmds; > + struct sbitmap scsi_tags; > + int max_cmds; > }; > > struct vhost_scsi { > @@ -324,7 +326,9 @@ static void vhost_scsi_release_cmd(struct se_cmd *se_cmd) > { > struct vhost_scsi_cmd *tv_cmd = container_of(se_cmd, > struct vhost_scsi_cmd, tvc_se_cmd); >...

This is the only use of kerneldoc in the sourcefile and no descriptions are provided. Fixes the following W=1 kernel build warning(s): drivers/scsi/virtio_scsi.c:109: warning: Function parameter or member 'vscsi' not described in 'virtscsi_complete_cmd' drivers/scsi/virtio_scsi.c:109: warning: Function parameter or member 'buf' not described in

This is the only use of kerneldoc in the sourcefile and no descriptions are provided. Fixes the following W=1 kernel build warning(s): drivers/scsi/virtio_scsi.c:109: warning: Function parameter or member 'vscsi' not described in 'virtscsi_complete_cmd' drivers/scsi/virtio_scsi.c:109: warning: Function parameter or member 'buf' not described in

This is the only use of kerneldoc in the sourcefile and no descriptions are provided. Fixes the following W=1 kernel build warning(s): drivers/scsi/virtio_scsi.c:109: warning: Function parameter or member 'vscsi' not described in 'virtscsi_complete_cmd' drivers/scsi/virtio_scsi.c:109: warning: Function parameter or member 'buf' not described in

On Mon, Jul 13, 2020 at 08:59:49AM +0100, Lee Jones wrote: > This is the only use of kerneldoc in the sourcefile and no > descriptions are provided. > > Fixes the following W=1 kernel build warning(s): > > drivers/scsi/virtio_scsi.c:109: warning: Function parameter or member 'vscsi' not described in 'virtscsi_complete_cmd' > drivers/scsi/virtio_scsi.c:109:

...09-23 594 return ERR_PTR(-ENOMEM); 4a47d3a1ff10e564 drivers/vhost/scsi.c Nicholas Bellinger 2013-09-23 595 } 4a47d3a1ff10e564 drivers/vhost/scsi.c Nicholas Bellinger 2013-09-23 596 aef0e1e9298ab68f drivers/vhost/scsi.c Mike Christie 2020-09-21 597 cmd = &svq->scsi_cmds[tag]; 3aee26b4ae91048c drivers/vhost/scsi.c Nicholas Bellinger 2013-06-21 598 sg = cmd->tvc_sgl; b1935f687bb93b20 drivers/vhost/scsi.c Nicholas Bellinger 2014-02-22 599 prot_sg = cmd->tvc_prot_sgl; 3aee26b4ae91048c drivers/vhost/scsi.c Nicholas Bellinger 2013-06-21 600...

I took a stub at documenting CMD and FLUSH request types in virtio block. Christoph, could you look over this please? I note that the interface seems full of warts to me, this might be a first step to cleaning them. One issue I struggled with especially is how type field mixes bits and non-bit values. I ended up simply defining all legal values, so that we have CMD = 2, CMD_OUT = 3 and so on.

I took a stub at documenting CMD and FLUSH request types in virtio block. Christoph, could you look over this please? I note that the interface seems full of warts to me, this might be a first step to cleaning them. One issue I struggled with especially is how type field mixes bits and non-bit values. I ended up simply defining all legal values, so that we have CMD = 2, CMD_OUT = 3 and so on.

...2013-09-23 594 return ERR_PTR(-ENOMEM); 4a47d3a1ff10e5 drivers/vhost/scsi.c Nicholas Bellinger 2013-09-23 595 } 4a47d3a1ff10e5 drivers/vhost/scsi.c Nicholas Bellinger 2013-09-23 596 aef0e1e9298ab6 drivers/vhost/scsi.c Mike Christie 2020-09-21 597 cmd = &svq->scsi_cmds[tag]; 3aee26b4ae9104 drivers/vhost/scsi.c Nicholas Bellinger 2013-06-21 598 sg = cmd->tvc_sgl; b1935f687bb93b drivers/vhost/scsi.c Nicholas Bellinger 2014-02-22 599 prot_sg = cmd->tvc_prot_sgl; 3aee26b4ae9104 drivers/vhost/scsi.c Nicholas Bellinger 2013-06-21 600 pages...

Hi all, this series adds multiqueue support to the virtio-scsi driver, based on Jason Wang's work on virtio-net. It uses a simple queue steering algorithm that expects one queue per CPU. LUNs in the same target always use the same queue (so that commands are not reordered); queue switching occurs when the request being queued is the only one for the target. Also based on Jason's

Hi all, this series adds multiqueue support to the virtio-scsi driver, based on Jason Wang's work on virtio-net. It uses a simple queue steering algorithm that expects one queue per CPU. LUNs in the same target always use the same queue (so that commands are not reordered); queue switching occurs when the request being queued is the only one for the target. Also based on Jason's

OK, this is (ab)uses some of Paolo's patches. The first 7 are candidates for this merge window (maybe), the rest I'm not so sure about. Thanks, Rusty. Paolo Bonzini (3): scatterlist: introduce sg_unmark_end virtio-blk: reorganize virtblk_add_req virtio-blk: use virtqueue_add_sgs on req path Rusty Russell (13): virtio_ring: virtqueue_add_sgs, to add multiple sgs. virtio-blk:

OK, this is (ab)uses some of Paolo's patches. The first 7 are candidates for this merge window (maybe), the rest I'm not so sure about. Thanks, Rusty. Paolo Bonzini (3): scatterlist: introduce sg_unmark_end virtio-blk: reorganize virtblk_add_req virtio-blk: use virtqueue_add_sgs on req path Rusty Russell (13): virtio_ring: virtqueue_add_sgs, to add multiple sgs. virtio-blk:

The virtqueue_add_buf function has two limitations: 1) it requires the caller to provide all the buffers in a single call; 2) it does not support chained scatterlists: the buffers must be provided as an array of struct scatterlist. Because of these limitations, virtio-scsi has to copy each request into a scatterlist internal to the driver. It cannot just use the one that was prepared by the

The virtqueue_add_buf function has two limitations: 1) it requires the caller to provide all the buffers in a single call; 2) it does not support chained scatterlists: the buffers must be provided as an array of struct scatterlist. Because of these limitations, virtio-scsi has to copy each request into a scatterlist internal to the driver. It cannot just use the one that was prepared by the

The following patches were built over linux-next which contains various vhost patches in mst's tree and the vhost_task patchset in Christian Brauner's tree: git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git kernel.user_worker branch: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=kernel.user_worker The latter patchset handles the review comment

Most device drivers do not need to perform any postprocessing on the scatterlists they receive from higher-level drivers (e.g. the block or SCSI layer), because they translate the request metadata directly from the various C structs into the data that is required by the device. virtio devices however do this translation in two steps: a device-specific step in the device driver, and generic

Most device drivers do not need to perform any postprocessing on the scatterlists they receive from higher-level drivers (e.g. the block or SCSI layer), because they translate the request metadata directly from the various C structs into the data that is required by the device. virtio devices however do this translation in two steps: a device-specific step in the device driver, and generic