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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> 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 notSort 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 ofThe 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 bethis 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 lineOk, 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. WhyJan, 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... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel