vscsi 2TB patches

vscsi 2TB patches

[Samuel Kvasnica]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

Hello xen developers,

the current xen vscsi driver implementation has a nasty >2TB limitation.
Both the
backend and frontend driver need a patch - included in the attachments.

Basically, for the frontend, just the max_cmd_len needs to be set correctly.
For for the backend, at least the READ_16 and WRITE_16 scsi commands
vere missing.
I also enabled/added some more scsi commands to allow tape drives and
autoloader
work properly.

Could please somebody here take care to add this to mainstream code ?
SuSE people were not interested really and the original author is not
really known, i.e. "Copyright by Fujitsu Limited". I'm really sick of
patching every new kernel over and over...

best ragards,

Sam



[-- Attachment #2: scsiback_2TB_fix.patch --]
[-- Type: text/plain, Size: 4935 bytes --]

diff -r ./scsiback.orig/emulate.c scsiback/emulate.c
30a31,35
> /*
> * Patched to support >2TB drives + allow tape & autoloader operations
> * 2010, Samuel Kvasnica, IMS Nanofabrication AG
> */
> 
384,385c389,390
< 	NO_EMULATE(TEST_UNIT_READY);       /*0x00*/
< 	NO_EMULATE(REZERO_UNIT);           /*0x01*/
---
> 	NO_EMULATE(TEST_UNIT_READY);       /*0x00*/ /* sd,st */
> 	NO_EMULATE(REZERO_UNIT);           /*0x01*/ /* st */
388c393
< 	NO_EMULATE(READ_BLOCK_LIMITS);     /*0x05*/
---
> 	NO_EMULATE(READ_BLOCK_LIMITS);     /*0x05*/ /* st */
390,393c395,398
< 	/*NO_EMULATE(INITIALIZE_ELEMENT_STATUS); *//*0x07*/
< 	NO_EMULATE(READ_6);                /*0x08*/
< 	NO_EMULATE(WRITE_6);               /*0x0a*/
< 	/*NO_EMULATE(SEEK_6);                *//*0x0b*/
---
> 	NO_EMULATE(INITIALIZE_ELEMENT_STATUS); /*0x07*/ /* ch */
> 	NO_EMULATE(READ_6);                /*0x08*/ /* sd,st */
> 	NO_EMULATE(WRITE_6);               /*0x0a*/ /* sd,st */
> 	NO_EMULATE(SEEK_6);                /*0x0b*/
395,396c400,401
< 	NO_EMULATE(WRITE_FILEMARKS);       /*0x10*/
< 	NO_EMULATE(SPACE);                 /*0x11*/
---
> 	NO_EMULATE(WRITE_FILEMARKS);       /*0x10*/ /* st */
> 	NO_EMULATE(SPACE);                 /*0x11*/ /* st */
399c404
< 	/*NO_EMULATE(MODE_SELECT);           *//*0x15*/
---
> 	NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
403,406c408,411
< 	NO_EMULATE(ERASE);                 /*0x19*/
< 	NO_EMULATE(MODE_SENSE);            /*0x1a*/
< 	/*NO_EMULATE(START_STOP);            *//*0x1b*/
< 	/*NO_EMULATE(RECEIVE_DIAGNOSTIC);    *//*0x1c*/
---
> 	NO_EMULATE(ERASE);                 /*0x19*/ /* st */
> 	NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */
> 	NO_EMULATE(START_STOP);            /*0x1b*/ /* sd,st */
> 	NO_EMULATE(RECEIVE_DIAGNOSTIC);    /*0x1c*/
408c413
< 	/*NO_EMULATE(ALLOW_MEDIUM_REMOVAL);  *//*0x1e*/
---
> 	NO_EMULATE(ALLOW_MEDIUM_REMOVAL);  /*0x1e*/
411,415c416,420
< 	NO_EMULATE(READ_CAPACITY);         /*0x25*/
< 	NO_EMULATE(READ_10);               /*0x28*/
< 	NO_EMULATE(WRITE_10);              /*0x2a*/
< 	/*NO_EMULATE(SEEK_10);               *//*0x2b*/
< 	/*NO_EMULATE(POSITION_TO_ELEMENT);   *//*0x2b*/
---
> 	NO_EMULATE(READ_CAPACITY);         /*0x25*/ /* sd */
> 	NO_EMULATE(READ_10);               /*0x28*/ /* sd */
> 	NO_EMULATE(WRITE_10);              /*0x2a*/ /* sd */
> 	NO_EMULATE(SEEK_10);               /*0x2b*/ /* st */
> 	NO_EMULATE(POSITION_TO_ELEMENT);   /*0x2b*/ /* ch */
421,427c426,432
< 	/*NO_EMULATE(SET_LIMITS);            *//*0x33*/
< 	/*NO_EMULATE(PRE_FETCH);             *//*0x34*/
< 	/*NO_EMULATE(READ_POSITION);         *//*0x34*/
< 	/*NO_EMULATE(SYNCHRONIZE_CACHE);     *//*0x35*/
< 	/*NO_EMULATE(LOCK_UNLOCK_CACHE);     *//*0x36*/
< 	/*NO_EMULATE(READ_DEFECT_DATA);      *//*0x37*/
< 	/*NO_EMULATE(MEDIUM_SCAN);           *//*0x38*/
---
> 	NO_EMULATE(SET_LIMITS);            /*0x33*/
> 	NO_EMULATE(PRE_FETCH);             /*0x34*/ /* st! */
> 	NO_EMULATE(READ_POSITION);          /*0x34*/ /* st */
> 	NO_EMULATE(SYNCHRONIZE_CACHE);      /*0x35*/ /* sd */
> 	NO_EMULATE(LOCK_UNLOCK_CACHE);     /*0x36*/
> 	NO_EMULATE(READ_DEFECT_DATA);      /*0x37*/
> 	NO_EMULATE(MEDIUM_SCAN);           /*0x38*/
430,431c435,436
< 	/*NO_EMULATE(WRITE_BUFFER);          *//*0x3b*/
< 	/*NO_EMULATE(READ_BUFFER);           *//*0x3c*/
---
> 	NO_EMULATE(WRITE_BUFFER);          /*0x3b*/
> 	NO_EMULATE(READ_BUFFER);           /*0x3c*/ /* osst */
437,439c442,444
< 	/*NO_EMULATE(READ_TOC);              *//*0x43*/
< 	/*NO_EMULATE(LOG_SELECT);            *//*0x4c*/
< 	/*NO_EMULATE(LOG_SENSE);             *//*0x4d*/
---
> 	NO_EMULATE(READ_TOC);              /*0x43*/ /* sr */
> 	NO_EMULATE(LOG_SELECT);            /*0x4c*/
> 	NO_EMULATE(LOG_SENSE);             /*0x4d*/ /* st! */
443c448
< 	/*NO_EMULATE(MODE_SENSE_10);         *//*0x5a*/
---
> 	NO_EMULATE(MODE_SENSE_10);         /*0x5a*/ /* scsi_lib */
447,448c452,455
< 	/*NO_EMULATE(MOVE_MEDIUM);           *//*0xa5*/
< 	/*NO_EMULATE(EXCHANGE_MEDIUM);       *//*0xa6*/
---
> 	NO_EMULATE(MAINTENANCE_IN);           /*0xa3*/ /* IFT alua */
> 	NO_EMULATE(MAINTENANCE_OUT);       /*0xa4*/ /* IFT alua */
> 	NO_EMULATE(MOVE_MEDIUM);           /*0xa5*/ /* ch */
> 	NO_EMULATE(EXCHANGE_MEDIUM);       /*0xa6*/ /* ch */
455,456c462,463
< 	/*NO_EMULATE(READ_ELEMENT_STATUS);   *//*0xb8*/
< 	/*NO_EMULATE(SEND_VOLUME_TAG);       *//*0xb6*/
---
> 	NO_EMULATE(READ_ELEMENT_STATUS);   /*0xb8*/ /* ch */
> 	NO_EMULATE(SEND_VOLUME_TAG);       /*0xb6*/ /* ch */
458,461c465,468
< 	/*NO_EMULATE(READ_16);               *//*0x88*/
< 	/*NO_EMULATE(WRITE_16);              *//*0x8a*/
< 	/*NO_EMULATE(VERIFY_16);	      *//*0x8f*/
< 	/*NO_EMULATE(SERVICE_ACTION_IN);     *//*0x9e*/
---
> 	NO_EMULATE(READ_16);               /*0x88*/ /* sd >2TB */
> 	NO_EMULATE(WRITE_16);              /*0x8a*/ /* sd >2TB */
> 	NO_EMULATE(VERIFY_16);	           /*0x8f*/
> 	NO_EMULATE(SERVICE_ACTION_IN);     /*0x9e*/ /* sd >2TB */
462a470
> /* st: QFA_REQUEST_BLOCK, QFA_SEEK_BLOCK */

[-- Attachment #3: scsifront_2TB_fix.patch --]
[-- Type: text/plain, Size: 238 bytes --]

diff -r ./scsifront.orig/xenbus.c ./scsifront/xenbus.c
30c30,34
<  
---
> 
> /*
> * Patched to support >2TB drives
> * 2010, Samuel Kvasnica, IMS Nanofabrication AG
> */
125d128
< 
222a226
> 	host->max_cmd_len = VSCSIIF_MAX_COMMAND_SIZE;

[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: vscsi 2TB patches

[Pasi Kärkkäinen]

On Mon, Jan 03, 2011 at 09:11:29PM +0100, Samuel Kvasnica wrote:
> Hello xen developers,
> 

Hello,

> the current xen vscsi driver implementation has a nasty >2TB limitation.
> Both the
> backend and frontend driver need a patch - included in the attachments.
> 

Thanks for the patch!

> Basically, for the frontend, just the max_cmd_len needs to be set correctly.
> For for the backend, at least the READ_16 and WRITE_16 scsi commands
> vere missing.
> I also enabled/added some more scsi commands to allow tape drives and
> autoloader
> work properly.
> 
> Could please somebody here take care to add this to mainstream code ?
> SuSE people were not interested really and the original author is not
> really known, i.e. "Copyright by Fujitsu Limited". I'm really sick of
> patching every new kernel over and over...
> 

Which kernels did you test this against? I assume this should be
applied to linux-2.6.18-xen tree.

Note that pvops kernels don't have pvscsi drivers yet! 
(Noone ported them yet from Xenlinux kernels).

Also two minor things:
	- Please send patches made with "diff -u" (unified diffs)
	- Include Signed-Off-By line

-- Pasi

> best ragards,
> 
> Sam
> 
> 

> diff -r ./scsiback.orig/emulate.c scsiback/emulate.c
> 30a31,35
> > /*
> > * Patched to support >2TB drives + allow tape & autoloader operations
> > * 2010, Samuel Kvasnica, IMS Nanofabrication AG
> > */
> > 
> 384,385c389,390
> < 	NO_EMULATE(TEST_UNIT_READY);       /*0x00*/
> < 	NO_EMULATE(REZERO_UNIT);           /*0x01*/
> ---
> > 	NO_EMULATE(TEST_UNIT_READY);       /*0x00*/ /* sd,st */
> > 	NO_EMULATE(REZERO_UNIT);           /*0x01*/ /* st */
> 388c393
> < 	NO_EMULATE(READ_BLOCK_LIMITS);     /*0x05*/
> ---
> > 	NO_EMULATE(READ_BLOCK_LIMITS);     /*0x05*/ /* st */
> 390,393c395,398
> < 	/*NO_EMULATE(INITIALIZE_ELEMENT_STATUS); *//*0x07*/
> < 	NO_EMULATE(READ_6);                /*0x08*/
> < 	NO_EMULATE(WRITE_6);               /*0x0a*/
> < 	/*NO_EMULATE(SEEK_6);                *//*0x0b*/
> ---
> > 	NO_EMULATE(INITIALIZE_ELEMENT_STATUS); /*0x07*/ /* ch */
> > 	NO_EMULATE(READ_6);                /*0x08*/ /* sd,st */
> > 	NO_EMULATE(WRITE_6);               /*0x0a*/ /* sd,st */
> > 	NO_EMULATE(SEEK_6);                /*0x0b*/
> 395,396c400,401
> < 	NO_EMULATE(WRITE_FILEMARKS);       /*0x10*/
> < 	NO_EMULATE(SPACE);                 /*0x11*/
> ---
> > 	NO_EMULATE(WRITE_FILEMARKS);       /*0x10*/ /* st */
> > 	NO_EMULATE(SPACE);                 /*0x11*/ /* st */
> 399c404
> < 	/*NO_EMULATE(MODE_SELECT);           *//*0x15*/
> ---
> > 	NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
> 403,406c408,411
> < 	NO_EMULATE(ERASE);                 /*0x19*/
> < 	NO_EMULATE(MODE_SENSE);            /*0x1a*/
> < 	/*NO_EMULATE(START_STOP);            *//*0x1b*/
> < 	/*NO_EMULATE(RECEIVE_DIAGNOSTIC);    *//*0x1c*/
> ---
> > 	NO_EMULATE(ERASE);                 /*0x19*/ /* st */
> > 	NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */
> > 	NO_EMULATE(START_STOP);            /*0x1b*/ /* sd,st */
> > 	NO_EMULATE(RECEIVE_DIAGNOSTIC);    /*0x1c*/
> 408c413
> < 	/*NO_EMULATE(ALLOW_MEDIUM_REMOVAL);  *//*0x1e*/
> ---
> > 	NO_EMULATE(ALLOW_MEDIUM_REMOVAL);  /*0x1e*/
> 411,415c416,420
> < 	NO_EMULATE(READ_CAPACITY);         /*0x25*/
> < 	NO_EMULATE(READ_10);               /*0x28*/
> < 	NO_EMULATE(WRITE_10);              /*0x2a*/
> < 	/*NO_EMULATE(SEEK_10);               *//*0x2b*/
> < 	/*NO_EMULATE(POSITION_TO_ELEMENT);   *//*0x2b*/
> ---
> > 	NO_EMULATE(READ_CAPACITY);         /*0x25*/ /* sd */
> > 	NO_EMULATE(READ_10);               /*0x28*/ /* sd */
> > 	NO_EMULATE(WRITE_10);              /*0x2a*/ /* sd */
> > 	NO_EMULATE(SEEK_10);               /*0x2b*/ /* st */
> > 	NO_EMULATE(POSITION_TO_ELEMENT);   /*0x2b*/ /* ch */
> 421,427c426,432
> < 	/*NO_EMULATE(SET_LIMITS);            *//*0x33*/
> < 	/*NO_EMULATE(PRE_FETCH);             *//*0x34*/
> < 	/*NO_EMULATE(READ_POSITION);         *//*0x34*/
> < 	/*NO_EMULATE(SYNCHRONIZE_CACHE);     *//*0x35*/
> < 	/*NO_EMULATE(LOCK_UNLOCK_CACHE);     *//*0x36*/
> < 	/*NO_EMULATE(READ_DEFECT_DATA);      *//*0x37*/
> < 	/*NO_EMULATE(MEDIUM_SCAN);           *//*0x38*/
> ---
> > 	NO_EMULATE(SET_LIMITS);            /*0x33*/
> > 	NO_EMULATE(PRE_FETCH);             /*0x34*/ /* st! */
> > 	NO_EMULATE(READ_POSITION);          /*0x34*/ /* st */
> > 	NO_EMULATE(SYNCHRONIZE_CACHE);      /*0x35*/ /* sd */
> > 	NO_EMULATE(LOCK_UNLOCK_CACHE);     /*0x36*/
> > 	NO_EMULATE(READ_DEFECT_DATA);      /*0x37*/
> > 	NO_EMULATE(MEDIUM_SCAN);           /*0x38*/
> 430,431c435,436
> < 	/*NO_EMULATE(WRITE_BUFFER);          *//*0x3b*/
> < 	/*NO_EMULATE(READ_BUFFER);           *//*0x3c*/
> ---
> > 	NO_EMULATE(WRITE_BUFFER);          /*0x3b*/
> > 	NO_EMULATE(READ_BUFFER);           /*0x3c*/ /* osst */
> 437,439c442,444
> < 	/*NO_EMULATE(READ_TOC);              *//*0x43*/
> < 	/*NO_EMULATE(LOG_SELECT);            *//*0x4c*/
> < 	/*NO_EMULATE(LOG_SENSE);             *//*0x4d*/
> ---
> > 	NO_EMULATE(READ_TOC);              /*0x43*/ /* sr */
> > 	NO_EMULATE(LOG_SELECT);            /*0x4c*/
> > 	NO_EMULATE(LOG_SENSE);             /*0x4d*/ /* st! */
> 443c448
> < 	/*NO_EMULATE(MODE_SENSE_10);         *//*0x5a*/
> ---
> > 	NO_EMULATE(MODE_SENSE_10);         /*0x5a*/ /* scsi_lib */
> 447,448c452,455
> < 	/*NO_EMULATE(MOVE_MEDIUM);           *//*0xa5*/
> < 	/*NO_EMULATE(EXCHANGE_MEDIUM);       *//*0xa6*/
> ---
> > 	NO_EMULATE(MAINTENANCE_IN);           /*0xa3*/ /* IFT alua */
> > 	NO_EMULATE(MAINTENANCE_OUT);       /*0xa4*/ /* IFT alua */
> > 	NO_EMULATE(MOVE_MEDIUM);           /*0xa5*/ /* ch */
> > 	NO_EMULATE(EXCHANGE_MEDIUM);       /*0xa6*/ /* ch */
> 455,456c462,463
> < 	/*NO_EMULATE(READ_ELEMENT_STATUS);   *//*0xb8*/
> < 	/*NO_EMULATE(SEND_VOLUME_TAG);       *//*0xb6*/
> ---
> > 	NO_EMULATE(READ_ELEMENT_STATUS);   /*0xb8*/ /* ch */
> > 	NO_EMULATE(SEND_VOLUME_TAG);       /*0xb6*/ /* ch */
> 458,461c465,468
> < 	/*NO_EMULATE(READ_16);               *//*0x88*/
> < 	/*NO_EMULATE(WRITE_16);              *//*0x8a*/
> < 	/*NO_EMULATE(VERIFY_16);	      *//*0x8f*/
> < 	/*NO_EMULATE(SERVICE_ACTION_IN);     *//*0x9e*/
> ---
> > 	NO_EMULATE(READ_16);               /*0x88*/ /* sd >2TB */
> > 	NO_EMULATE(WRITE_16);              /*0x8a*/ /* sd >2TB */
> > 	NO_EMULATE(VERIFY_16);	           /*0x8f*/
> > 	NO_EMULATE(SERVICE_ACTION_IN);     /*0x9e*/ /* sd >2TB */
> 462a470
> > /* st: QFA_REQUEST_BLOCK, QFA_SEEK_BLOCK */

> diff -r ./scsifront.orig/xenbus.c ./scsifront/xenbus.c
> 30c30,34
> <  
> ---
> > 
> > /*
> > * Patched to support >2TB drives
> > * 2010, Samuel Kvasnica, IMS Nanofabrication AG
> > */
> 125d128
> < 
> 222a226
> > 	host->max_cmd_len = VSCSIIF_MAX_COMMAND_SIZE;

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: vscsi 2TB patches

[Samuel Kvasnica]

[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]

Hello Pasi,

On 01/04/2011 12:06 AM, Pasi Kärkkäinen wrote:
> Which kernels did you test this against? I assume this should be
this is thoroughly tested against opensuse 2.6.31.x-xen - 2.6.34.7-xen
with paravirtualized domU, xen 4.0.1.

> applied to linux-2.6.18-xen tree.
Huh ??? 2.6.18 ? I remember that was ~5 years ago, cannot imagine even
boot it up
on current hardware. But as long as scsi constant names did not change, the
patch should be compatible, there is nothing kernel-specific.

Btw, I'm still confused, why did the original author exclude so many
scsi commands from passthrough.
> Note that pvops kernels don't have pvscsi drivers yet! 
> (Noone ported them yet from Xenlinux kernels).
Hmm, so why does it work at all, did suse people port it secretly ?
Correct me if I'm wrong,
but actually, I cannot imagine the vscsi drivers have anything special
related to pvops,
its just a simple passthrough layer for scsi commands. Or do you mean a
real paravirt
scsi driver implementation is planned ? The current vscsi works actually
pretty well,
I'm getting native performance, much better than using xvd.

There some are other glitches with the vscsi python xend code in current
4.0.x -
scsi devices are not found on "xm create" due to mismatch with lsscsi
interface and
some deprecated python stuff. But I don´t have a clean patch, just
workaround,
maybe I submit another bugreport to suse.
> Also two minor things:
> 	- Please send patches made with "diff -u" (unified diffs)
> 	- Include Signed-Off-By line
Ok, I'm attaching the changed patch, hope the format is correct now.

I'm also adding the Fujitsu authors to cc: as Jan kindly googled out
somewhere their emails.

regards,

Sam

[-- Attachment #2: vscsi_2TB.patch --]
[-- Type: text/plain, Size: 9689 bytes --]

From: Samuel Kvasnica <bugreports@list.ims.co.at>
Subject: vscsi >2TB patch

This patch fixes current 2TB limitation of the xen vscsi driver.
Both frontend (command size) and backend (missing READ_16/WRITE_16 commands)
driver need a fix. Also an scsi command added to support ALUA.
Tested thoroughly on 4TB external RAID.

I also enabled some more commands to allow operating LTO tape
drives and autoloaders (tested on HP Ultrium 1/8 + Bacula).

Still more scsi commands might be missing for other specific devices 
(why not to enable all scsi commands by default ?).

This patch was tested on opensuse xenified kernels 2.6.31-2.6.34.7
in paravirtualized domU.

Signed-off-by: Samuel Kvasnica <samuel.kvasnica@ims.co.at>
---
diff -rup ./scsiback.orig/emulate.c scsiback/emulate.c
--- ./scsiback.orig/emulate.c	2010-10-30 07:05:01.000000000 +0200
+++ scsiback/emulate.c	2011-01-03 20:41:19.890669438 +0100
@@ -28,6 +28,11 @@
  * IN THE SOFTWARE.
  */
 
+/*
+* Patched to support >2TB drives + allow tape & autoloader operations
+* 2010, Samuel Kvasnica, IMS Nanofabrication AG
+*/
+
 #include <scsi/scsi.h>
 #include <scsi/scsi_cmnd.h>
 #include <scsi/scsi_device.h>
@@ -381,85 +386,88 @@ void scsiback_emulation_init(void)
 	/*
 	  Following commands do not require emulation.
 	*/
-	NO_EMULATE(TEST_UNIT_READY);       /*0x00*/
-	NO_EMULATE(REZERO_UNIT);           /*0x01*/
+	NO_EMULATE(TEST_UNIT_READY);       /*0x00*/ /* sd,st */
+	NO_EMULATE(REZERO_UNIT);           /*0x01*/ /* st */
 	NO_EMULATE(REQUEST_SENSE);         /*0x03*/
 	NO_EMULATE(FORMAT_UNIT);           /*0x04*/
-	NO_EMULATE(READ_BLOCK_LIMITS);     /*0x05*/
+	NO_EMULATE(READ_BLOCK_LIMITS);     /*0x05*/ /* st */
 	/*NO_EMULATE(REASSIGN_BLOCKS);       *//*0x07*/
-	/*NO_EMULATE(INITIALIZE_ELEMENT_STATUS); *//*0x07*/
-	NO_EMULATE(READ_6);                /*0x08*/
-	NO_EMULATE(WRITE_6);               /*0x0a*/
-	/*NO_EMULATE(SEEK_6);                *//*0x0b*/
+	NO_EMULATE(INITIALIZE_ELEMENT_STATUS); /*0x07*/ /* ch */
+	NO_EMULATE(READ_6);                /*0x08*/ /* sd,st */
+	NO_EMULATE(WRITE_6);               /*0x0a*/ /* sd,st */
+	NO_EMULATE(SEEK_6);                /*0x0b*/
 	/*NO_EMULATE(READ_REVERSE);          *//*0x0f*/
-	NO_EMULATE(WRITE_FILEMARKS);       /*0x10*/
-	NO_EMULATE(SPACE);                 /*0x11*/
+	NO_EMULATE(WRITE_FILEMARKS);       /*0x10*/ /* st */
+	NO_EMULATE(SPACE);                 /*0x11*/ /* st */
 	NO_EMULATE(INQUIRY);               /*0x12*/
 	/*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/
-	/*NO_EMULATE(MODE_SELECT);           *//*0x15*/
+	NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
 	/*NO_EMULATE(RESERVE);               *//*0x16*/
 	/*NO_EMULATE(RELEASE);               *//*0x17*/
 	/*NO_EMULATE(COPY);                  *//*0x18*/
-	NO_EMULATE(ERASE);                 /*0x19*/
-	NO_EMULATE(MODE_SENSE);            /*0x1a*/
-	/*NO_EMULATE(START_STOP);            *//*0x1b*/
-	/*NO_EMULATE(RECEIVE_DIAGNOSTIC);    *//*0x1c*/
+	NO_EMULATE(ERASE);                 /*0x19*/ /* st */
+	NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */
+	NO_EMULATE(START_STOP);            /*0x1b*/ /* sd,st */
+	NO_EMULATE(RECEIVE_DIAGNOSTIC);    /*0x1c*/
 	NO_EMULATE(SEND_DIAGNOSTIC);       /*0x1d*/
-	/*NO_EMULATE(ALLOW_MEDIUM_REMOVAL);  *//*0x1e*/
+	NO_EMULATE(ALLOW_MEDIUM_REMOVAL);  /*0x1e*/
 
 	/*NO_EMULATE(SET_WINDOW);            *//*0x24*/
-	NO_EMULATE(READ_CAPACITY);         /*0x25*/
-	NO_EMULATE(READ_10);               /*0x28*/
-	NO_EMULATE(WRITE_10);              /*0x2a*/
-	/*NO_EMULATE(SEEK_10);               *//*0x2b*/
-	/*NO_EMULATE(POSITION_TO_ELEMENT);   *//*0x2b*/
+	NO_EMULATE(READ_CAPACITY);         /*0x25*/ /* sd */
+	NO_EMULATE(READ_10);               /*0x28*/ /* sd */
+	NO_EMULATE(WRITE_10);              /*0x2a*/ /* sd */
+	NO_EMULATE(SEEK_10);               /*0x2b*/ /* st */
+	NO_EMULATE(POSITION_TO_ELEMENT);   /*0x2b*/ /* ch */
 	/*NO_EMULATE(WRITE_VERIFY);          *//*0x2e*/
 	/*NO_EMULATE(VERIFY);                *//*0x2f*/
 	/*NO_EMULATE(SEARCH_HIGH);           *//*0x30*/
 	/*NO_EMULATE(SEARCH_EQUAL);          *//*0x31*/
 	/*NO_EMULATE(SEARCH_LOW);            *//*0x32*/
-	/*NO_EMULATE(SET_LIMITS);            *//*0x33*/
-	/*NO_EMULATE(PRE_FETCH);             *//*0x34*/
-	/*NO_EMULATE(READ_POSITION);         *//*0x34*/
-	/*NO_EMULATE(SYNCHRONIZE_CACHE);     *//*0x35*/
-	/*NO_EMULATE(LOCK_UNLOCK_CACHE);     *//*0x36*/
-	/*NO_EMULATE(READ_DEFECT_DATA);      *//*0x37*/
-	/*NO_EMULATE(MEDIUM_SCAN);           *//*0x38*/
+	NO_EMULATE(SET_LIMITS);            /*0x33*/
+	NO_EMULATE(PRE_FETCH);             /*0x34*/ /* st! */
+	NO_EMULATE(READ_POSITION);          /*0x34*/ /* st */
+	NO_EMULATE(SYNCHRONIZE_CACHE);      /*0x35*/ /* sd */
+	NO_EMULATE(LOCK_UNLOCK_CACHE);     /*0x36*/
+	NO_EMULATE(READ_DEFECT_DATA);      /*0x37*/
+	NO_EMULATE(MEDIUM_SCAN);           /*0x38*/
 	/*NO_EMULATE(COMPARE);               *//*0x39*/
 	/*NO_EMULATE(COPY_VERIFY);           *//*0x3a*/
-	/*NO_EMULATE(WRITE_BUFFER);          *//*0x3b*/
-	/*NO_EMULATE(READ_BUFFER);           *//*0x3c*/
+	NO_EMULATE(WRITE_BUFFER);          /*0x3b*/
+	NO_EMULATE(READ_BUFFER);           /*0x3c*/ /* osst */
 	/*NO_EMULATE(UPDATE_BLOCK);          *//*0x3d*/
 	/*NO_EMULATE(READ_LONG);             *//*0x3e*/
 	/*NO_EMULATE(WRITE_LONG);            *//*0x3f*/
 	/*NO_EMULATE(CHANGE_DEFINITION);     *//*0x40*/
 	/*NO_EMULATE(WRITE_SAME);            *//*0x41*/
-	/*NO_EMULATE(READ_TOC);              *//*0x43*/
-	/*NO_EMULATE(LOG_SELECT);            *//*0x4c*/
-	/*NO_EMULATE(LOG_SENSE);             *//*0x4d*/
+	NO_EMULATE(READ_TOC);              /*0x43*/ /* sr */
+	NO_EMULATE(LOG_SELECT);            /*0x4c*/
+	NO_EMULATE(LOG_SENSE);             /*0x4d*/ /* st! */
 	/*NO_EMULATE(MODE_SELECT_10);        *//*0x55*/
 	/*NO_EMULATE(RESERVE_10);            *//*0x56*/
 	/*NO_EMULATE(RELEASE_10);            *//*0x57*/
-	/*NO_EMULATE(MODE_SENSE_10);         *//*0x5a*/
+	NO_EMULATE(MODE_SENSE_10);         /*0x5a*/ /* scsi_lib */
 	/*NO_EMULATE(PERSISTENT_RESERVE_IN); *//*0x5e*/
 	/*NO_EMULATE(PERSISTENT_RESERVE_OUT); *//*0x5f*/
 	/*           REPORT_LUNS             *//*0xa0*//*Full emulaiton*/
-	/*NO_EMULATE(MOVE_MEDIUM);           *//*0xa5*/
-	/*NO_EMULATE(EXCHANGE_MEDIUM);       *//*0xa6*/
+	NO_EMULATE(MAINTENANCE_IN);           /*0xa3*/ /* IFT alua */
+	NO_EMULATE(MAINTENANCE_OUT);       /*0xa4*/ /* IFT alua */
+	NO_EMULATE(MOVE_MEDIUM);           /*0xa5*/ /* ch */
+	NO_EMULATE(EXCHANGE_MEDIUM);       /*0xa6*/ /* ch */
 	/*NO_EMULATE(READ_12);               *//*0xa8*/
 	/*NO_EMULATE(WRITE_12);              *//*0xaa*/
 	/*NO_EMULATE(WRITE_VERIFY_12);       *//*0xae*/
 	/*NO_EMULATE(SEARCH_HIGH_12);        *//*0xb0*/
 	/*NO_EMULATE(SEARCH_EQUAL_12);       *//*0xb1*/
 	/*NO_EMULATE(SEARCH_LOW_12);         *//*0xb2*/
-	/*NO_EMULATE(READ_ELEMENT_STATUS);   *//*0xb8*/
-	/*NO_EMULATE(SEND_VOLUME_TAG);       *//*0xb6*/
+	NO_EMULATE(READ_ELEMENT_STATUS);   /*0xb8*/ /* ch */
+	NO_EMULATE(SEND_VOLUME_TAG);       /*0xb6*/ /* ch */
 	/*NO_EMULATE(WRITE_LONG_2);          *//*0xea*/
-	/*NO_EMULATE(READ_16);               *//*0x88*/
-	/*NO_EMULATE(WRITE_16);              *//*0x8a*/
-	/*NO_EMULATE(VERIFY_16);	      *//*0x8f*/
-	/*NO_EMULATE(SERVICE_ACTION_IN);     *//*0x9e*/
+	NO_EMULATE(READ_16);               /*0x88*/ /* sd >2TB */
+	NO_EMULATE(WRITE_16);              /*0x8a*/ /* sd >2TB */
+	NO_EMULATE(VERIFY_16);	           /*0x8f*/
+	NO_EMULATE(SERVICE_ACTION_IN);     /*0x9e*/ /* sd >2TB */
 
+/* st: QFA_REQUEST_BLOCK, QFA_SEEK_BLOCK might be needed ? */
 	/*
 	  Following commands require emulation.
 	*/
diff -rup ./scsifront.orig/scsifront.c ./scsifront/scsifront.c
--- ./scsifront.orig/scsifront.c	2010-10-30 07:05:01.000000000 +0200
+++ ./scsifront/scsifront.c	2010-07-24 16:00:59.000000000 +0200
@@ -94,7 +94,6 @@ static void scsifront_do_request(struct
 	struct vscsiif_front_ring *ring = &(info->ring);
 	unsigned int irq = info->irq;
 	int notify;
-
 	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(ring, notify);
 	if (notify)
 		notify_remote_via_irq(irq);
@@ -137,6 +136,7 @@ static void scsifront_cdb_cmd_done(struc
 	uint32_t id;
 	uint8_t sense_len;
 
+
 	id = ring_res->rqid;
 	sc = (struct scsi_cmnd *)info->shadow[id].req_scsi_cmnd;
 
@@ -324,6 +324,11 @@ static int scsifront_queuecommand(struct
 	int ref_cnt;
 	uint16_t rqid;
 
+/*	printk(KERN_INFO "scsicmd: len=%i, 0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x",sc->cmd_len,
+		sc->cmnd[0],sc->cmnd[1],sc->cmnd[2],sc->cmnd[3],sc->cmnd[4],
+		sc->cmnd[5],sc->cmnd[6],sc->cmnd[7],sc->cmnd[8],sc->cmnd[9]
+		);
+*/
 	if (RING_FULL(&info->ring)) {
 		goto out_host_busy;
 	}
@@ -342,6 +347,7 @@ static int scsifront_queuecommand(struct
 
 	BUG_ON(sc->cmd_len > VSCSIIF_MAX_COMMAND_SIZE);
 
+
 	if ( sc->cmd_len )
 		memcpy(ring_req->cmnd, sc->cmnd, sc->cmd_len);
 	else
diff -rup ./scsifront.orig/xenbus.c ./scsifront/xenbus.c
--- ./scsifront.orig/xenbus.c	2010-10-30 07:05:01.000000000 +0200
+++ ./scsifront/xenbus.c	2011-01-03 20:41:40.562665612 +0100
@@ -27,7 +27,11 @@
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
  * IN THE SOFTWARE.
  */
- 
+
+/*
+* Patched to support >2TB drives
+* 2010, Samuel Kvasnica, IMS Nanofabrication AG
+*/
 
 #include <linux/version.h>
 #include <linux/slab.h>
@@ -122,7 +126,6 @@ static int scsifront_init_ring(struct vs
 	int err;
 
 	DPRINTK("%s\n",__FUNCTION__);
-
 	err = scsifront_alloc_ring(info);
 	if (err)
 		return err;
@@ -220,6 +223,7 @@ static int scsifront_probe(struct xenbus
 	host->max_channel = 0;
 	host->max_lun     = VSCSIIF_MAX_LUN;
 	host->max_sectors = (VSCSIIF_SG_TABLESIZE - 1) * PAGE_SIZE / 512;
+	host->max_cmd_len = VSCSIIF_MAX_COMMAND_SIZE;
 
 	err = scsi_add_host(host, &dev->dev);
 	if (err) {

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: vscsi 2TB patches

[Jan Beulich]

>>> On 04.01.11 at 12:24, Samuel Kvasnica <bugreports@list.ims.co.at> wrote:
>> applied to linux-2.6.18-xen tree.
> Huh ??? 2.6.18 ? I remember that was ~5 years ago, cannot imagine even
> boot it up
> on current hardware. But as long as scsi constant names did not change, the
> patch should be compatible, there is nothing kernel-specific.

But you need to specify what xenbits tree you intend this to be
applied to, and there you have the choice between 2.6.18,
XCI/XCP, and (not really on xenbits) pv-ops. Since the forward
porting of the 2.6.18 tree doesn't generally leave the files in
drivers/xen/scsi*/ completely untouched, it cannot be taken as
given that the patch you used on top of .31/.34 will apply as-is
on .18.

Jan

Re: vscsi 2TB patches

[Samuel Kvasnica]

Hi Pasi,

we had some discussion with Jan in the background:

On 01/04/2011 03:14 PM, Jan Beulich wrote:
>>>> On 04.01.11 at 14:34, Samuel Kvasnica <bugreports@list.ims.co.at> wrote:
>>> Did you *try* whether it applies to the 2.6.18 tree? And in order
>>> for it to be applied (given that the 2.6.18 tree is legacy and not
>>> fully maintained anymore), you'd also have to specifically indicate
>>> that it's intended for that tree in the subject, otherwise Keir will
>>> just ignore any Linux patches, assuming they're destined for
>>> pv-ops.
>> well, never tried 2.6.18 and I did not even assume xen community still
>> sticks to 2.6.18 tree
>> for whatever strange reasons. There is no way to even boot 2.6.18 in my
>> case, so lets forget
>> about it, not going to submit patch without testing it on real system.
> In all reality that's what happens quite frequently.
Pasi: do you see a possibility  to try it out on 2.6.18 ? I'm not sure
if anybody from Fujitsu takes
actively care, it is quite old code.
>> Well, ok, so now whats the procedure to get this by default at least to
>> opensuse kernel ?
> If it is reasonably applicable to the 2.6.18 kernel, we prefer getting
> it through that tree. Second choice would be to get it through the
> pv-ops one, pointing us to the relevant commits. Third choice (we
> actually did so only very few times thus far, and we're going to be
> reluctant to take anything that could go through either of the
> earlier paths) is to give us the patch on top of our HEAD/master
> tree, accompanied by sufficient information on what the change
> does and how was tested (so we can judge how likely regressions
> from the patch might be).
Jan: but if I understood Pasi, he claims there are no pvscsi drivers
included in the pv-ops tree at all
because it was not ported so far.
But your opensuse pv-ops kernel definitely includes pvscsi drivers -
does this part exist only in
suse kernel tree ?

Sam

Re: vscsi 2TB patches

[Jan Beulich]

>>> On 04.01.11 at 15:46, Samuel Kvasnica <bugreports@list.ims.co.at> wrote:
> On 01/04/2011 03:14 PM, Jan Beulich wrote:
>> If it is reasonably applicable to the 2.6.18 kernel, we prefer getting
>> it through that tree. Second choice would be to get it through the
>> pv-ops one, pointing us to the relevant commits. Third choice (we
>> actually did so only very few times thus far, and we're going to be
>> reluctant to take anything that could go through either of the
>> earlier paths) is to give us the patch on top of our HEAD/master
>> tree, accompanied by sufficient information on what the change
>> does and how was tested (so we can judge how likely regressions
>> from the patch might be).
> Jan: but if I understood Pasi, he claims there are no pvscsi drivers
> included in the pv-ops tree at all
> because it was not ported so far.
> But your opensuse pv-ops kernel definitely includes pvscsi drivers -
> does this part exist only in
> suse kernel tree ?

Again - we derive out code from the 2.6.18 tree, which has pvscsi
drrivers. Above I just gave a general description, not all of which
would always (read: here) apply.

Jan

Re: vscsi 2TB patches

[Jan Beulich]

>>> On 04.01.11 at 12:24, Samuel Kvasnica <bugreports@list.ims.co.at> wrote:
> Ok, I'm attaching the changed patch, hope the format is correct now.

I notice that compared to your first mail, at least scsifront has more
changes now - how is that explained?

Jan

Re: vscsi 2TB patches

[Samuel Kvasnica]

On 01/04/2011 12:47 PM, Jan Beulich wrote:
>>>> On 04.01.11 at 12:24, Samuel Kvasnica <bugreports@list.ims.co.at> wrote:
>> Ok, I'm attaching the changed patch, hope the format is correct now.
> I notice that compared to your first mail, at least scsifront has more
> changes now - how is that explained?
>
> Jan
>
Yeh, sorry for that, theres one extra debug printk included now, which
is commented out.
However, this can be very handy in future, if somebody looks for more
missing
scsi commands, so maybe it could remain there ?

Sam

Re: vscsi 2TB patches

[Jan Beulich]

>>> On 04.01.11 at 14:03, Samuel Kvasnica <bugreports@list.ims.co.at> wrote:
> On 01/04/2011 12:47 PM, Jan Beulich wrote:
>>>>> On 04.01.11 at 12:24, Samuel Kvasnica <bugreports@list.ims.co.at> wrote:
>>> Ok, I'm attaching the changed patch, hope the format is correct now.
>> I notice that compared to your first mail, at least scsifront has more
>> changes now - how is that explained?
>>
>> Jan
>>
> Yeh, sorry for that, theres one extra debug printk included now, which
> is commented out.
> However, this can be very handy in future, if somebody looks for more
> missing
> scsi commands, so maybe it could remain there ?

I wasn't actually after the printk(), but rather noticing your original
scsifront patch apparently consisted of only an added comment;
that I was wrong with actually (not being used to read non-unified
diffs), but your newer patch still contains a number of apparently
arbitrary newline insertions and removals.

Jan

Re: vscsi 2TB patches

[Samuel Kvasnica]

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

On 01/04/2011 02:07 PM, Jan Beulich wrote:
> I wasn't actually after the printk(), but rather noticing your original
> scsifront patch apparently consisted of only an added comment;
> that I was wrong with actually (not being used to read non-unified
> diffs), but your newer patch still contains a number of apparently
> arbitrary newline insertions and removals.

is this ok now ?

Sam


[-- Attachment #2: vscsi_2TB.patch --]
[-- Type: text/plain, Size: 8938 bytes --]

From: Samuel Kvasnica <bugreports@list.ims.co.at>
Subject: vscsi >2TB patch

This patch fixes current 2TB limitation of the xen vscsi driver.
Both frontend (command size) and backend (missing READ_16/WRITE_16 commands)
driver need a fix. Also an scsi command added to support ALUA.
Tested thoroughly on 4TB external RAID.

I also enabled some more commands to allow operating LTO tape
drives and autoloaders (tested on HP Ultrium 1/8 + Bacula).

Still more scsi commands might be missing for other specific devices 
(why not to enable all scsi commands by default ?).

This patch was tested on opensuse xenified kernels 2.6.31-2.6.34.7
in paravirtualized domU.

Signed-off-by: Samuel Kvasnica <samuel.kvasnica@ims.co.at>
---
diff -rup ./scsiback.orig/emulate.c scsiback/emulate.c
--- ./scsiback.orig/emulate.c	2010-10-30 07:05:01.000000000 +0200
+++ scsiback/emulate.c	2011-01-03 20:41:19.890669438 +0100
@@ -28,6 +28,11 @@
  * IN THE SOFTWARE.
  */
 
+/*
+* Patched to support >2TB drives + allow tape & autoloader operations
+* 2010, Samuel Kvasnica, IMS Nanofabrication AG
+*/
+
 #include <scsi/scsi.h>
 #include <scsi/scsi_cmnd.h>
 #include <scsi/scsi_device.h>
@@ -381,85 +386,88 @@ void scsiback_emulation_init(void)
 	/*
 	  Following commands do not require emulation.
 	*/
-	NO_EMULATE(TEST_UNIT_READY);       /*0x00*/
-	NO_EMULATE(REZERO_UNIT);           /*0x01*/
+	NO_EMULATE(TEST_UNIT_READY);       /*0x00*/ /* sd,st */
+	NO_EMULATE(REZERO_UNIT);           /*0x01*/ /* st */
 	NO_EMULATE(REQUEST_SENSE);         /*0x03*/
 	NO_EMULATE(FORMAT_UNIT);           /*0x04*/
-	NO_EMULATE(READ_BLOCK_LIMITS);     /*0x05*/
+	NO_EMULATE(READ_BLOCK_LIMITS);     /*0x05*/ /* st */
 	/*NO_EMULATE(REASSIGN_BLOCKS);       *//*0x07*/
-	/*NO_EMULATE(INITIALIZE_ELEMENT_STATUS); *//*0x07*/
-	NO_EMULATE(READ_6);                /*0x08*/
-	NO_EMULATE(WRITE_6);               /*0x0a*/
-	/*NO_EMULATE(SEEK_6);                *//*0x0b*/
+	NO_EMULATE(INITIALIZE_ELEMENT_STATUS); /*0x07*/ /* ch */
+	NO_EMULATE(READ_6);                /*0x08*/ /* sd,st */
+	NO_EMULATE(WRITE_6);               /*0x0a*/ /* sd,st */
+	NO_EMULATE(SEEK_6);                /*0x0b*/
 	/*NO_EMULATE(READ_REVERSE);          *//*0x0f*/
-	NO_EMULATE(WRITE_FILEMARKS);       /*0x10*/
-	NO_EMULATE(SPACE);                 /*0x11*/
+	NO_EMULATE(WRITE_FILEMARKS);       /*0x10*/ /* st */
+	NO_EMULATE(SPACE);                 /*0x11*/ /* st */
 	NO_EMULATE(INQUIRY);               /*0x12*/
 	/*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/
-	/*NO_EMULATE(MODE_SELECT);           *//*0x15*/
+	NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
 	/*NO_EMULATE(RESERVE);               *//*0x16*/
 	/*NO_EMULATE(RELEASE);               *//*0x17*/
 	/*NO_EMULATE(COPY);                  *//*0x18*/
-	NO_EMULATE(ERASE);                 /*0x19*/
-	NO_EMULATE(MODE_SENSE);            /*0x1a*/
-	/*NO_EMULATE(START_STOP);            *//*0x1b*/
-	/*NO_EMULATE(RECEIVE_DIAGNOSTIC);    *//*0x1c*/
+	NO_EMULATE(ERASE);                 /*0x19*/ /* st */
+	NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */
+	NO_EMULATE(START_STOP);            /*0x1b*/ /* sd,st */
+	NO_EMULATE(RECEIVE_DIAGNOSTIC);    /*0x1c*/
 	NO_EMULATE(SEND_DIAGNOSTIC);       /*0x1d*/
-	/*NO_EMULATE(ALLOW_MEDIUM_REMOVAL);  *//*0x1e*/
+	NO_EMULATE(ALLOW_MEDIUM_REMOVAL);  /*0x1e*/
 
 	/*NO_EMULATE(SET_WINDOW);            *//*0x24*/
-	NO_EMULATE(READ_CAPACITY);         /*0x25*/
-	NO_EMULATE(READ_10);               /*0x28*/
-	NO_EMULATE(WRITE_10);              /*0x2a*/
-	/*NO_EMULATE(SEEK_10);               *//*0x2b*/
-	/*NO_EMULATE(POSITION_TO_ELEMENT);   *//*0x2b*/
+	NO_EMULATE(READ_CAPACITY);         /*0x25*/ /* sd */
+	NO_EMULATE(READ_10);               /*0x28*/ /* sd */
+	NO_EMULATE(WRITE_10);              /*0x2a*/ /* sd */
+	NO_EMULATE(SEEK_10);               /*0x2b*/ /* st */
+	NO_EMULATE(POSITION_TO_ELEMENT);   /*0x2b*/ /* ch */
 	/*NO_EMULATE(WRITE_VERIFY);          *//*0x2e*/
 	/*NO_EMULATE(VERIFY);                *//*0x2f*/
 	/*NO_EMULATE(SEARCH_HIGH);           *//*0x30*/
 	/*NO_EMULATE(SEARCH_EQUAL);          *//*0x31*/
 	/*NO_EMULATE(SEARCH_LOW);            *//*0x32*/
-	/*NO_EMULATE(SET_LIMITS);            *//*0x33*/
-	/*NO_EMULATE(PRE_FETCH);             *//*0x34*/
-	/*NO_EMULATE(READ_POSITION);         *//*0x34*/
-	/*NO_EMULATE(SYNCHRONIZE_CACHE);     *//*0x35*/
-	/*NO_EMULATE(LOCK_UNLOCK_CACHE);     *//*0x36*/
-	/*NO_EMULATE(READ_DEFECT_DATA);      *//*0x37*/
-	/*NO_EMULATE(MEDIUM_SCAN);           *//*0x38*/
+	NO_EMULATE(SET_LIMITS);            /*0x33*/
+	NO_EMULATE(PRE_FETCH);             /*0x34*/ /* st! */
+	NO_EMULATE(READ_POSITION);          /*0x34*/ /* st */
+	NO_EMULATE(SYNCHRONIZE_CACHE);      /*0x35*/ /* sd */
+	NO_EMULATE(LOCK_UNLOCK_CACHE);     /*0x36*/
+	NO_EMULATE(READ_DEFECT_DATA);      /*0x37*/
+	NO_EMULATE(MEDIUM_SCAN);           /*0x38*/
 	/*NO_EMULATE(COMPARE);               *//*0x39*/
 	/*NO_EMULATE(COPY_VERIFY);           *//*0x3a*/
-	/*NO_EMULATE(WRITE_BUFFER);          *//*0x3b*/
-	/*NO_EMULATE(READ_BUFFER);           *//*0x3c*/
+	NO_EMULATE(WRITE_BUFFER);          /*0x3b*/
+	NO_EMULATE(READ_BUFFER);           /*0x3c*/ /* osst */
 	/*NO_EMULATE(UPDATE_BLOCK);          *//*0x3d*/
 	/*NO_EMULATE(READ_LONG);             *//*0x3e*/
 	/*NO_EMULATE(WRITE_LONG);            *//*0x3f*/
 	/*NO_EMULATE(CHANGE_DEFINITION);     *//*0x40*/
 	/*NO_EMULATE(WRITE_SAME);            *//*0x41*/
-	/*NO_EMULATE(READ_TOC);              *//*0x43*/
-	/*NO_EMULATE(LOG_SELECT);            *//*0x4c*/
-	/*NO_EMULATE(LOG_SENSE);             *//*0x4d*/
+	NO_EMULATE(READ_TOC);              /*0x43*/ /* sr */
+	NO_EMULATE(LOG_SELECT);            /*0x4c*/
+	NO_EMULATE(LOG_SENSE);             /*0x4d*/ /* st! */
 	/*NO_EMULATE(MODE_SELECT_10);        *//*0x55*/
 	/*NO_EMULATE(RESERVE_10);            *//*0x56*/
 	/*NO_EMULATE(RELEASE_10);            *//*0x57*/
-	/*NO_EMULATE(MODE_SENSE_10);         *//*0x5a*/
+	NO_EMULATE(MODE_SENSE_10);         /*0x5a*/ /* scsi_lib */
 	/*NO_EMULATE(PERSISTENT_RESERVE_IN); *//*0x5e*/
 	/*NO_EMULATE(PERSISTENT_RESERVE_OUT); *//*0x5f*/
 	/*           REPORT_LUNS             *//*0xa0*//*Full emulaiton*/
-	/*NO_EMULATE(MOVE_MEDIUM);           *//*0xa5*/
-	/*NO_EMULATE(EXCHANGE_MEDIUM);       *//*0xa6*/
+	NO_EMULATE(MAINTENANCE_IN);           /*0xa3*/ /* IFT alua */
+	NO_EMULATE(MAINTENANCE_OUT);       /*0xa4*/ /* IFT alua */
+	NO_EMULATE(MOVE_MEDIUM);           /*0xa5*/ /* ch */
+	NO_EMULATE(EXCHANGE_MEDIUM);       /*0xa6*/ /* ch */
 	/*NO_EMULATE(READ_12);               *//*0xa8*/
 	/*NO_EMULATE(WRITE_12);              *//*0xaa*/
 	/*NO_EMULATE(WRITE_VERIFY_12);       *//*0xae*/
 	/*NO_EMULATE(SEARCH_HIGH_12);        *//*0xb0*/
 	/*NO_EMULATE(SEARCH_EQUAL_12);       *//*0xb1*/
 	/*NO_EMULATE(SEARCH_LOW_12);         *//*0xb2*/
-	/*NO_EMULATE(READ_ELEMENT_STATUS);   *//*0xb8*/
-	/*NO_EMULATE(SEND_VOLUME_TAG);       *//*0xb6*/
+	NO_EMULATE(READ_ELEMENT_STATUS);   /*0xb8*/ /* ch */
+	NO_EMULATE(SEND_VOLUME_TAG);       /*0xb6*/ /* ch */
 	/*NO_EMULATE(WRITE_LONG_2);          *//*0xea*/
-	/*NO_EMULATE(READ_16);               *//*0x88*/
-	/*NO_EMULATE(WRITE_16);              *//*0x8a*/
-	/*NO_EMULATE(VERIFY_16);	      *//*0x8f*/
-	/*NO_EMULATE(SERVICE_ACTION_IN);     *//*0x9e*/
+	NO_EMULATE(READ_16);               /*0x88*/ /* sd >2TB */
+	NO_EMULATE(WRITE_16);              /*0x8a*/ /* sd >2TB */
+	NO_EMULATE(VERIFY_16);	           /*0x8f*/
+	NO_EMULATE(SERVICE_ACTION_IN);     /*0x9e*/ /* sd >2TB */
 
+/* st: QFA_REQUEST_BLOCK, QFA_SEEK_BLOCK might be needed ? */
 	/*
 	  Following commands require emulation.
 	*/
diff -rup ./scsifront.orig/scsifront.c ./scsifront/scsifront.c
--- ./scsifront.orig/scsifront.c	2010-10-30 07:05:01.000000000 +0200
+++ ./scsifront/scsifront.c	2010-07-24 16:00:59.000000000 +0200
@@ -324,6 +324,11 @@ static int scsifront_queuecommand(struct
 	int ref_cnt;
 	uint16_t rqid;
 
+/* debug printk to identify more missing scsi commands
+	printk(KERN_INFO "scsicmd: len=%i, 0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x",sc->cmd_len,
+		sc->cmnd[0],sc->cmnd[1],sc->cmnd[2],sc->cmnd[3],sc->cmnd[4],
+		sc->cmnd[5],sc->cmnd[6],sc->cmnd[7],sc->cmnd[8],sc->cmnd[9]
+		);
+*/
 	if (RING_FULL(&info->ring)) {
 		goto out_host_busy;
 	}
diff -rup ./scsifront.orig/xenbus.c ./scsifront/xenbus.c
--- ./scsifront.orig/xenbus.c	2010-10-30 07:05:01.000000000 +0200
+++ ./scsifront/xenbus.c	2011-01-03 20:41:40.562665612 +0100
@@ -27,7 +27,11 @@
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
  * IN THE SOFTWARE.
  */
- 
+
+/*
+* Patched to support >2TB drives
+* 2010, Samuel Kvasnica, IMS Nanofabrication AG
+*/
 
 #include <linux/version.h>
 #include <linux/slab.h>
@@ -220,6 +223,7 @@ static int scsifront_probe(struct xenbus
 	host->max_channel = 0;
 	host->max_lun     = VSCSIIF_MAX_LUN;
 	host->max_sectors = (VSCSIIF_SG_TABLESIZE - 1) * PAGE_SIZE / 512;
+	host->max_cmd_len = VSCSIIF_MAX_COMMAND_SIZE;
 
 	err = scsi_add_host(host, &dev->dev);
 	if (err) {

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: vscsi 2TB patches

[Jan Beulich]

>>> On 04.01.11 at 14:23, Samuel Kvasnica <bugreports@list.ims.co.at> wrote:
> On 01/04/2011 02:07 PM, Jan Beulich wrote:
>> I wasn't actually after the printk(), but rather noticing your original
>> scsifront patch apparently consisted of only an added comment;
>> that I was wrong with actually (not being used to read non-unified
>> diffs), but your newer patch still contains a number of apparently
>> arbitrary newline insertions and removals.
> 
> is this ok now ?

Yes, looks okay to me from a formal perspective. I'd still like to
see some sort of comment on it from the Fujitsu guys.

Jan

Re: vscsi 2TB patches

[Jan Beulich]

>>> On 04.01.11 at 14:23, Samuel Kvasnica <bugreports@list.ims.co.at> wrote:
> On 01/04/2011 02:07 PM, Jan Beulich wrote:
>> I wasn't actually after the printk(), but rather noticing your original
>> scsifront patch apparently consisted of only an added comment;
>> that I was wrong with actually (not being used to read non-unified
>> diffs), but your newer patch still contains a number of apparently
>> arbitrary newline insertions and removals.
> 
> is this ok now ?

Tomonari, Jun, any word on these changes?

Thanks, Jan

Re: vscsi 2TB patches

[Jan Beulich]

>>> On 04.01.11 at 14:23, Samuel Kvasnica <bugreports@list.ims.co.at> wrote:
> On 01/04/2011 02:07 PM, Jan Beulich wrote:
>> I wasn't actually after the printk(), but rather noticing your original
>> scsifront patch apparently consisted of only an added comment;
>> that I was wrong with actually (not being used to read non-unified
>> diffs), but your newer patch still contains a number of apparently
>> arbitrary newline insertions and removals.
> 
> is this ok now ?

I was about to ack this (given the lack of a response from the
original authors, and after looking over it again), when I noticed
an apparent inconsistency: {READ,WRITE}_{6,10,16} are all
un-commented now in scsiback_emulation_init(), but
{READ,WRITE}_12 remain commented. Why is that?

Thanks, Jan

Re: vscsi 2TB patches

[Samuel Kvasnica]

On 01/18/2011 12:45 PM, Jan Beulich wrote:
> ack this (given the lack of a response from the
> original authors, and after looking over it again), when I noticed
> an apparent inconsistency: {READ,WRITE}_{6,10,16} are all
> un-commented now in scsiback_emulation_init(), but
> {READ,WRITE}_12 remain commented. Why
Jan,

I'm very sorry for the long delay, too many critical issues in progress
here...

Well, I did enable (lets hope) everything, the linux scsi drivers are
apparently using. I've put debug printfs into the frontend driver,
which has lead to several commands like READ16. I did real tests using 2
LSI U320 scsi controllers with multipathing and an attached Eonstor
RaidArray +  tests using the Ultrium LTO3 Autoloader + bacula.
Additionally, I enabled several other SCSI commands found
in other scsi drivers like "sr".

I don't quite understand why the original authors excluded so many
commands (thats what I state in my patch header)
and hence I included only what was needed. Excluding makes sense only
when emulation is needed but did not want to enable too much...

Re: vscsi 2TB patches

[Jan Beulich]

>>> On 03.01.11 at 21:11, Samuel Kvasnica <bugreports@list.ims.co.at> wrote:
> Hello xen developers,
> 
> the current xen vscsi driver implementation has a nasty >2TB limitation.
> Both the
> backend and frontend driver need a patch - included in the attachments.
> 
> Basically, for the frontend, just the max_cmd_len needs to be set correctly.
> For for the backend, at least the READ_16 and WRITE_16 scsi commands
> vere missing.
> I also enabled/added some more scsi commands to allow tape drives and
> autoloader
> work properly.
> 
> Could please somebody here take care to add this to mainstream code ?
> SuSE people were not interested really and the original author is not

Sort of interesting a statement - iirc we responded that we'd take
the changes once someone knowing the code reviewed them, and
suggested that you post them here (which now you did, but you'll
need to at least one more time to get thing into proper shape as
pointed out by Pasi).

> really known, i.e. "Copyright by Fujitsu Limited". I'm really sick of

The original scsiback and scsifront commits say

Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com>
Signed-off-by: Jun Kamada <kama@jp.fujitsu.com>

Maybe you want to Cc them when you resubmit.

> patching every new kernel over and over...

Understandable.

Jan

Re: vscsi 2TB patches

[Samuel Kvasnica]

On 01/04/2011 10:47 AM, Jan Beulich wrote:
>> Could please somebody here take care to add this to mainstream code ?
>> SuSE people were not interested really and the original author is not
> Sort of interesting a statement - iirc we responded that we'd take
> the changes once someone knowing the code reviewed them, and
> suggested that you post them here (which now you did, but you'll
> need to at least one more time to get thing into proper shape as
> pointed out by Pasi).
Well, so lets say, suse was at least something like "reluctant" to
accept the code.
I mean, I invested 90% of effort needed to identify, report, fix & test
this bug.

Given the fact, I don't submit kernel patches on daily basis, I would
have welcomed
somebody who does this regularly and actually maintains the code to take
care of the rest.

You might call it lazy or sloppy approach, but its all about efficiency.
Subscribing just
another mailing list, searching for the infos, submission standards etc.
is just
much more work on my side than actually fixing the issue.
> Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com>
> Signed-off-by: Jun Kamada <kama@jp.fujitsu.com>
thanks ! How/where did you find it ?

regards,

Sam

Re: vscsi 2TB patches

[Jan Beulich]

>>> On 04.01.11 at 13:57, Samuel Kvasnica <bugreports@list.ims.co.at> wrote:
> On 01/04/2011 10:47 AM, Jan Beulich wrote:
>> Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com>
>> Signed-off-by: Jun Kamada <kama@jp.fujitsu.com>
> thanks ! How/where did you find it ?

In the 2.6.18 mercurial tree (http://xenbits.xensource.com/linux-2.6.18-xen.hg).

Jan