ibmvstgt: Port from tgt to SCST
Subsystems (4)
Bart Van Assche
maintainerPATCH 5/7 ibmvstgt: Port from tgt to SCST
The ibmvstgt and libsrp kernel modules as included in the 2.6.37 kernel are based on the tgt SCSI target framework. Both kernel modules need the scsi_tgt kernel module and the tgtd user space process in order to function properly. This patch modifies the ibmvstgt and libsrp kernel modules such that both use the SCST storage target framework instead of tgt. As a result, neither the scsi_tgt kernel module nor the tgtd user space process are any more necessary when using the ibmvstgt driver.
This patch introduces one backwards-incompatible change, namely that the path of the ibmvstgt sysfs attributes is modified. This change is unavoidable because this patch dissociates ibmvstgt SRP sessions from a SCSI host instance. Since the user space STGT driver ibmvio was the only user of these attributes this isn't an issue.
Changes in ibmvstgt:
- Increased maximum data size for a single SRP command from 128 KB to 64 MB such that an initiator is not forced to split large transfers into multiple SCSI commands.
- The maximum RDMA transfer size supported by a single H_COPY_RDMA call is queried at driver initialization time from the open firmware tree / larger transfers than 128 KB are now supported too.
- If DMA mapping fails while handling a READ or WRITE command, the offending command is retried until the associated data has been transferred instead of reporting to the ibmvscsi client that the SCSI command failed.
- VSCSI command/response queue: one element has been reserved for management datagrams since these fall outside the SRP credit mechanism. Added a compile- time check whether the size of this queue is a power of two.
- Fixed a race condition which in theory could have caused the VSCSI receive queue to overflow: srp_iu_put() is now invoked before a response is sent back to the initiator instead of after.
- Moved enum iue_flags from libsrp to ibmvstgt because it is ibmvstgt-specific.
- Removed a variable that was modified but never read from ibmvstgt_rdma().
- ibmvstgt_probe(): changed the datatype of the variable "dma" from unsigned * into const unsigned * such that a cast could be removed.
- Fixed all compiler and sparse warnings (C=2 CF=-D__CHECK_ENDIAN__).
Changes in libsrp compared to kernel 2.6.36:
- Renamed vscsis_data_length() into srp_data_length() and exported this function.
- All error messages reported via printk() do now have prefix KERN_ERR.
- Modified srp_target_alloc() and srp_target_free() such that the driver-private data reflects whether or not target data has been allocated. This change was necessary to avoid that ibmvstgt_remove() triggers a NULL-pointer dereference if ibmvstgt_probe() failed.
- srp_transfer_data(): All three return statements related to DMA mapping failure do now return -ENOMEM instead of 0, -EIO and -ENOMEM.
- srp_direct_data(): Removed the ext_desc argument since not used.
- srp_direct_data() and srp_indirect_data(): Use DMA_TO/FROM_DEVICE instead of DMA_BIDIRECTIONAL for the buffers mapped for transferring data via DMA.
- struct srp_target: eliminated the information unit linked list and also the V_FLYING flag since both were duplicating information managed by the SCST core.
- Fixed all compiler and sparse warnings (C=2 CF=-D__CHECK_ENDIAN__).
Tests performed on a backport to kernel version 2.6.18 of this driver with a Linux initiator system:
- Verified that the kernel module ibmvstgt loads and initializes successfully and also that the client connects after loading.
- Verified that all virtual disks configured in scst_vdisk were discovered by the client after rescanning the SCSI bus.
- Verified that after unloading and reloading ibmvstgt and after client recovery that the initiator devices were functioning normally.
- Verified that after a client reboot ibmvscsic reconnected with the target and that the target devices were again usable.
- Performed IO stress testing on the device.
- Verified that SCSI task abortion works correctly.
- Performed basic I/O performance testing. With a RAM disk as target linear direct I/O throughput was above 2 GB/s and a random I/O test resulted in about 30000 IOPS for all block sizes between 512 bytes and 16 KB. Both initiator and target were dual core POWER6 LPAR systems.
Note: ibmvstgt is the only user of libsrp.
--- Documentation/powerpc/ibmvstgt.txt | 89 ++++ drivers/scsi/ibmvscsi/ibmvstgt.c | 914 +++++++++++++++++++++++++----------- drivers/scsi/libsrp.c | 174 ++++---- include/scsi/libsrp.h | 27 +- include/scsi/srp.h | 7 + 5 files changed, 843 insertions(+), 368 deletions(-) create mode 100644 Documentation/powerpc/ibmvstgt.txt
Documentation/powerpc/ibmvstgt.txt new file +89 -0
@@ -0,0 +1,89 @@ +IBM Virtual SCSI Target (ibmvstgt) +================================== + + +Introduction +------------ +The virtual SCSI (VSCSI) protocol as defined in [2] is a protocol that allows +one logical partition (LPAR) to access SCSI targets provided by another LPAR. +The LPAR that provides one or more SCSI targets is called the VIO server or +VIOS. The ibmvstgt driver is a VIOS driver that makes it possible to access +exported target devices via the VSCSI protocol. + +Setup +----- +After having configured the LPARs, boot the LPARs and load the ibmvstgt kernel +module in the VIOS. After the target driver has been loaded, verify that a +message similar to the following appears in the initiator kernel log: + +ibmvscsi 30000028: partner initialized +ibmvscsi 30000028: host srp version: 16.a, host partition VIOS3-P6 (40), OS 2, max io 67108864 +ibmvscsi 30000028: sent SRP login +ibmvscsi 30000028: SRP_LOGIN succeeded + +In the above log messages, the number 30000028 refers to the VIOS. The last +two digits, 0x28, refer to the VIOS partition number (0x28 = 40). + +The next step is to decide which SCSI devices to export. Here is an example of +a configuration in which 16 RAM disks have been exported (see also [1] for +more information): + +# ls /sys/kernel/scst_tgt/devices +2:0:0:0 ram000 ram001 ram002 ram003 ram004 ram005 ram006 ram007 +ram008 ram009 ram010 ram011 ram012 ram013 ram014 ram015 + +After this step a LUN has to be assigned to each exported SCSI device. Some +non-Linux initiator operating systems only accept LUN numbes that are +multiples of 256 and require that the LUN addressing method is used. +Assigning LUN numbers is possible e.g. as follows: + + lun=0 + for name in ram000 ram001 ram002 ram003 ram004 ram005 ram006 ram007 \ + ram008 ram009 ram010 ram011 ram012 ram013 ram014 ram015 + do + lun=$((lun+256)) + echo "add $name $lun" \ + >/sys/kernel/scst_tgt/targets/ibmvstgt/ibmvstgt_target_0/luns/mgmt + done + echo 1 >/sys/kernel/scst_tgt/targets/ibmvstgt/ibmvstgt_target_0/enabled + +The result of the above commands will be as follows: + +# cat /sys/kernel/scst_tgt/targets/ibmvstgt/ibmvstgt_target_0/addr_method +LUN +# ls /sys/kernel/scst_tgt/targets/ibmvstgt/ibmvstgt_target_0/luns +256 512 768 1024 1280 1536 1792 2048 2304 2560 2816 3072 3328 3584 3840 4096 +mgmt +# cat /sys/kernel/scst_tgt/targets/ibmvstgt/ibmvstgt_target_0/enabled +1 + +After SCST has been configured, make the new configuration available to the +initiator by rescanning the SCSI bus, e.g. as follows: + +# rescan-scsi-bus --hosts=2 --ids=0-31 +# lsscsi 2: +[2:0:1:0] disk IBM VDASD blkdev 0001 /dev/sdb +[2:0:2:0] disk IBM VDASD blkdev 0001 /dev/sdc +[2:0:3:0] disk IBM VDASD blkdev 0001 /dev/sdd +[2:0:4:0] disk IBM VDASD blkdev 0001 /dev/sde +[2:0:5:0] disk IBM VDASD blkdev 0001 /dev/sdf +[2:0:6:0] disk IBM VDASD blkdev 0001 /dev/sdg +[2:0:7:0] disk IBM VDASD blkdev 0001 /dev/sdh +[2:0:8:0] disk IBM VDASD blkdev 0001 /dev/sdi +[2:0:9:0] disk IBM VDASD blkdev 0001 /dev/sdj +[2:0:10:0] disk IBM VDASD blkdev 0001 /dev/sdk +[2:0:11:0] disk IBM VDASD blkdev 0001 /dev/sdl +[2:0:12:0] disk IBM VDASD blkdev 0001 /dev/sdm +[2:0:13:0] disk IBM VDASD blkdev 0001 /dev/sdn +[2:0:14:0] disk IBM VDASD blkdev 0001 /dev/sdo +[2:0:15:0] disk IBM VDASD blkdev 0001 /dev/sdp +[2:0:16:0] disk IBM VDASD blkdev 0001 /dev/sdq + + +References +---------- +[1] SCST Configuration Interface, Documentation/scst/README.scst. +[2] Power.org Standard for Power Architecture Platform Requirements (PAPR) +(Workstation, Server), Version 2.4, December 7, 2009, http://www.power.org. +[3] Virtual I/O (VIO) and Virtualization, IBM Developerworks, 2010, +http://www.ibm.com/developerworks/wikis/display/virtualization/VIO.
drivers/scsi/ibmvscsi/ibmvstgt.c +651 -263
1,297 lines not on this page · raw message
drivers/scsi/libsrp.c +90 -84
336 lines not on this page · raw message
include/scsi/libsrp.h +6 -21
@@ -3,17 +3,9 @@#include <linux/list.h> #include <linux/kfifo.h> -#include <scsi/scsi_cmnd.h> -#include <scsi/scsi_host.h> +#include <scst/scst.h> #include <scsi/srp.h> -enum iue_flags { -V_DIOVER , -V_WRITE , -V_LINKED , -V_FLYING , -}; -struct srp_buf {dma_addr_t dma;void *buf;
@@ -27,11 +19,10 @@ struct srp_queue { };struct srp_target { -struct Scsi_Host *shost; +struct scst_tgt *tgt;struct device *dev;spinlock_t lock; -struct list_head cmd_queue;size_t srp_iu_size;struct srp_queue iu_queue;
@@ -44,14 +35,13 @@ struct srp_target {struct iu_entry {struct srp_target *target; -struct list_head ilist;dma_addr_t remote_token;unsigned long flags;struct srp_buf *sbuf; }; -typedef int (srp_rdma_t )(struct scsi_cmnd *,struct scatterlist *,int , +typedef int (srp_rdma_t )(struct scst_cmd *,struct scatterlist *,int ,struct srp_direct_buf *,int ,enum dma_data_direction ,unsigned int );extern int srp_target_alloc (struct srp_target *,struct device *,size_t ,size_t );
@@ -60,16 +50,11 @@ extern void srp_target_free(struct srp_target *);extern struct iu_entry *srp_iu_get (struct srp_target *);extern void srp_iu_put (struct iu_entry *); -extern int srp_cmd_queue (struct Scsi_Host *,struct srp_cmd *,void *,u64 ,u64 ); -extern int srp_transfer_data (struct scsi_cmnd *,struct srp_cmd *, +extern int srp_data_length (struct srp_cmd *,enum dma_data_direction ); +extern int srp_cmd_queue (struct scst_session *,struct srp_cmd *,void *,int ); +extern int srp_transfer_data (struct scst_cmd *,struct srp_cmd *,srp_rdma_t ,int ,int ); - -static inline struct srp_target *host_to_srp_target (struct Scsi_Host *host) -{ -return (struct srp_target *) host->hostdata; -} -static inline int srp_cmd_direction (struct srp_cmd *cmd) {return (cmd->buf_fmt >>4 ) ?DMA_TO_DEVICE :DMA_FROM_DEVICE ;
include/scsi/srp.h +7 -0
@@ -69,6 +69,13 @@ enum {SRP_DATA_DESC_INDIRECT =2 }; +enum srp_task_attribute { +SRP_SIMPLE_TASK =0 , +SRP_HEAD_TASK =1 , +SRP_ORDERED_TASK =2 , +SRP_ACA_TASK =4 +}; +enum {SRP_TSK_ABORT_TASK =0x01 ,SRP_TSK_ABORT_TASK_SET =0x02 ,
Signature · 1 line
1.7.1