Starting
-------------
If you want IBM VIO target driver, get kernel version 2.6.20, rebuild
the kernel, and reboot with the new kernel. Note you need to enable
SCSI_TGT, SCSI_SRP, and SCSI_IBMVSCSIS kernel options.

host:~/tgt/usr$ make KERNELSRC=<kernel-src-directory> IBMVIO=1

Make sure that everything is built successfully.

Try the following commands:

host:~/tgt$ su
host:~/tgt# modprobe scsi_tgt
host:~/tgt# modprobe libsrp
host:~/tgt# modprobe ibmvstgt
host:~/tgt# ./usr/tgtd

See /var/log/kern.log (your Linux distributions may use the different
log file name) to make sure that the kernel modules are loaded
properly. You should see messages like the followings:

Feb 27 19:37:52 lilac kernel: IBM eServer i/pSeries Virtual SCSI Target Driver
Feb 27 19:37:52 lilac kernel: vio_register_driver: driver ibmvscsi registering
Feb 27 19:37:52 lilac kernel: scsi1 : ibmvstgt

You need the scsi host number (it is 1 in this example) in the next
stage (configuration).


Configuration
-------------
Everyting is configured via the tgtadm management tool.

The following example creates a target with id 1, adds a logical unit
(backed by /dev/sdb1) with lun 0, and then bind the target with
/sys/devices/vio/30000003.

You need to targetname to create a new target just as a reference.

host:~/tgt# ./usr/tgtadm --lld ibmvio --mode target --op new --tid 1 --targetname volume1
host:~/tgt# ./usr/tgtadm --lld ibmvio --mode logicalunit --op new --tid 1 --lun 0 -b /dev/sdb1
host:~/tgt# ./usr/tgtadm --lld ibmvio --mode target --op bind --tid 1 --bus vio,30000003


Please see /var/log/daemon.log (your Linux distributions may use the
different log file name again) to make sure that everything is
fine. You should see something like the followings:

Feb 27 22:36:40 lilac tgtd: dl_init(71) istgt library is not loaded.
Feb 27 22:36:40 lilac tgtd: dl_init(71) ibmvstgt library is not loaded.
Feb 27 22:37:08 lilac tgtd: tgt_target_create(572) Succeed to create a new target 1
Feb 27 22:37:08 lilac tgtd: tgt_target_bind(517) Succeed to bind the target 1 to the scsi host 1
Feb 27 22:37:08 lilac tgtd: tgt_device_create(238) Succeed to add a logical unit 0 to the target 1
Now you are ready. Boot up VIO clients.


History
-------------
The following description was taken from the original ibmvscsis
driver:

http://lkml.org/lkml/2005/10/17/99


This driver is a SCSI target that interoperates according to the PAPR
(POWER Architecture Platform Requirements) document.  Currently it is
specific to POWER logical partitioning, however in the future it would
be nice to extend this to other virtualized environments.

The architecture defines virtual adapters, whose configuration is
reported in the Open Firmware device tree.  There area number of power
hypervisor calls (such as h_reg_crq, to register the inter-OS queue)
that support the virtual adapters.

Messages are sent between partitions on a "Command/Response Queue"
(CRQ), which is just a buffer of 16 byte entries in the receiver's
Senders cannot access the buffer directly, but send messages by making
a hypervisor call and passing in the 16 bytes.  The hypervisor puts
the message in the next 16 byte space in round-robbin fashion, turns
on the high order bit of the message (the valid bit), and generates an
interrupt to the receiver (if interrupts are turned on.)  The receiver
just turns off the valid bit when they have copied out the message.

The VSCSI client builds a SCSI Remote Protocol (SRP) Information Unit
(IU) (as defined in the T10 standard available at www.t10.org), gets a
DMA address for the message, and sends it to the target as the payload
of a CRQ message.  The target DMAs the SRP IU and processes it,
including doing any additional data transfers.  When it is done, it
DMAs the SRP response back to the same address as the request came
from and sends a CRQ message back to inform the client that the
request has completed.

This target interoperates not only with the Linux client (ibmvscsi.c)
but also with AIX and OS/400 clients.  Thus, while the implementation
can be changed, the underlying behaviour (protocol) is fixed.

Configuration of the target is done via sysfs.  The target driver maps
either block devices (e.g. IDE CD drive, loopback file, etc) to SCSI
LUNs, in which case it emulates the SCSI protocol and issues kernel
block device calls, or maps real SCSI devices, in which case the SCSI
commands are just passed on to the real SCSI device.
