Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1622670 > unrolled thread

[PATCH] virtio_scsi: Always try to read VPD pages

Back to article view | Back to linux.kernel

Contents

  [PATCH] virtio_scsi: Always try to read VPD pages David Gibson <david@gibson.dropbear.id.au> - 2017-04-13 04:30 +0200
    Re: [PATCH] virtio_scsi: Always try to read VPD pages Stefan Hajnoczi <stefanha@redhat.com> - 2017-04-13 15:40 +0200
      Re: [PATCH] virtio_scsi: Always try to read VPD pages Paolo Bonzini <pbonzini@redhat.com> - 2017-04-19 17:10 +0200
    Re: [PATCH] virtio_scsi: Always try to read VPD pages "Martin K. Petersen" <martin.petersen@oracle.com> - 2017-04-20 01:20 +0200

#1622670 — [PATCH] virtio_scsi: Always try to read VPD pages

Passed through SCSI targets may have transfer limits which come from the
host SCSI controller 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.

This adds a workaround to address this, forcing devices attached to a
virtio-scsi controller to always check the VPD pages.  This is modelled on
a similar workaround for the storvsc (Hyper-V) SCSI controller, although
that exists for slightly different reasons.

A specific case which causes this is a volume from IBM's IPR RAID
controller (which presents as an SPC-2 device, although it does support
VPD) passed through with qemu's 'scsi-block' device.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 drivers/scsi/virtio_scsi.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 939c47d..961a1fc 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -29,6 +29,7 @@
 #include <scsi/scsi_device.h>
 #include <scsi/scsi_cmnd.h>
 #include <scsi/scsi_tcq.h>
+#include <scsi/scsi_devinfo.h>
 #include <linux/seqlock.h>
 #include <linux/blk-mq-virtio.h>
 
@@ -705,6 +706,28 @@ static int virtscsi_device_reset(struct scsi_cmnd *sc)
 	return virtscsi_tmf(vscsi, cmd);
 }
 
+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 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;
+}
+
+
 /**
  * virtscsi_change_queue_depth() - Change a virtscsi target's queue depth
  * @sdev:	Virtscsi target whose queue depth to change
@@ -783,6 +806,7 @@ static struct scsi_host_template virtscsi_host_template_single = {
 	.change_queue_depth = virtscsi_change_queue_depth,
 	.eh_abort_handler = virtscsi_abort,
 	.eh_device_reset_handler = virtscsi_device_reset,
+	.slave_alloc = virtscsi_device_alloc,
 
 	.can_queue = 1024,
 	.dma_boundary = UINT_MAX,
-- 
2.9.3

[toc] | [next] | [standalone]

#1623020

[Multipart message — attachments visible in raw view] — view raw

On Thu, Apr 13, 2017 at 12:13:00PM +1000, David Gibson wrote:
> @@ -705,6 +706,28 @@ static int virtscsi_device_reset(struct scsi_cmnd *sc)
>  	return virtscsi_tmf(vscsi, cmd);
>  }
>  
> +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 something on the host side other than the target

s/controller something/controller or something/ ?

> +	 * 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;
> +}

Looks good to me.  Not a SCSI expert but I checked
scsi_device_supports_vpd() callers and this seems sane.

[toc] | [prev] | [next] | [standalone]

#1626311

On 13/04/2017 15:39, Stefan Hajnoczi wrote:
> On Thu, Apr 13, 2017 at 12:13:00PM +1000, David Gibson wrote:
>> @@ -705,6 +706,28 @@ static int virtscsi_device_reset(struct scsi_cmnd *sc)
>>  	return virtscsi_tmf(vscsi, cmd);
>>  }
>>  
>> +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 something on the host side other than the target
> 
> s/controller something/controller or something/ ?

Acked-by: Paolo Bonzini <pbonzini@redhat.com>

with this change.

Paolo

[toc] | [prev] | [next] | [standalone]

#1626860

David,

> Passed through SCSI targets may have transfer limits which come from
> the host SCSI controller 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.

Applied to 4.12/scsi-queue.

-- 
Martin K. Petersen	Oracle Linux Engineering

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web