Bug 1003158 - vioscsi.sys doesn't return scsi status codes correctly to guest OS
vioscsi.sys doesn't return scsi status codes correctly to guest OS
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virtio-win (Show other bugs)
7.0
Unspecified Windows
unspecified Severity medium
: rc
: 7.0
Assigned To: Vadim Rozenfeld
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-31 05:56 EDT by Corinna Vinschen
Modified: 2015-03-18 05:10 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-11-09 05:43:22 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
WIndows test case for READ POSITION LONG (4.26 KB, application/indir)
2013-08-31 05:56 EDT, Corinna Vinschen
no flags Details
HCKX log file (2.68 MB, application/zip)
2013-10-12 07:02 EDT, Mike Cao
no flags Details
win2k8-R2-scsi-hck-log (8.47 MB, application/zip)
2014-02-24 03:53 EST, lijin
no flags Details

  None (edit)
Description Corinna Vinschen 2013-08-31 05:56:50 EDT
Created attachment 792398 [details]
WIndows test case for READ POSITION LONG

Description of problem:

  Consider using a host SCSI tape drive from a Windows guest, which
  doesn't understand the READ POSITION LONG command.  When checking the
  current tape position (Win32 API call GetTapePosition), the guest tape
  driver tries to use this command.   If it works (the returned SCSI
  status is 0) it uses the information.  Otherwise it falls back to READ
  POSITION without the LONG flag and uses that information.

  This works fine when using the SCSI controller emulation "lsisas1078"
  aka "megasas.sys" in Windows, but it fails when using the "virtio-scsi"
  emulation aka "vioscsi.sys" in  Windows.

  The problem is, that for some reason the vioscsi driver returns an
  SCSI status of 0, even if READ POSITION LONG failed, and thus the tape
  driver accidentally uses the sense information as if it is position
  information.

  A Windows test application (attached) using SCSI passthrough commands
  shows that the SCSI status after calling READ POSITION LONG is, in
  fact, 2.  So the SCSI status gets lost at some point, and the only
  component which is between the tape drive and the tape driver is the
  SCSI controller driver.

Version-Release number of selected component (if applicable):

  virtio-win-1.6.6-1.el6.noarch

How reproducible:

  Connect a tape drive which doesn't understand READ POSITION LONG to the
  host, add virtio-scsi controller and hostdev entry matching the tape
  drive to the guest.  Install vioscsi.sys.  Fetch position information
  from the drive.  Observe strange values.

Actual results:

  Wrong position information returned by Win32 API call GetTapePosition.

Expected results:

  Correct position information returned by Win32 API call GetTapePosition.

Additional info:

  The attached testcase can be compiled with Cygwin or Mingw-w64 gcc.

  It prints the info given by GetTapePosition and it tries to read
  the position info using READ POSITION LONG.  With a tape drive not
  supporting READ POSITION LONG, the GetTapePosition should still
  return the correct information.  The SCSI passthrough attempt should
  result in sense informatioṅ.  This works with the megasas driver.
  With the vioscsi driver, the information returned by GetTapePosition
  is broken, and it also prints the broken position information from
  the SCSI passthrough command, because the SCSI status code is 0.
Comment 6 lijin 2013-09-04 05:54:45 EDT
Try to reproduce this issue with following steps:
1.Connect to an iscsi disk:/dev/sdf
2.Boot win7-32 guest with:
/usr/libexec/qemu-kvm -drive file=/dev/sdf,if=none,cache=none,media=disk,format=raw,id=drive-ide0-0-1 -device virtio-scsi-pci,id=scsi0 -device scsi-hd,drive=drive-ide0-0-1,bus=scsi0.0,id=scsi1,bootindex=0 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -usb -device usb-tablet -vnc :22 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:7f:f9:F6,bus=pci.0 -monitor stdio -chardev file,path=/root/console.log,id=serial1 -device isa-serial,chardev=serial1,id=s1 -cpu Penryn,hv_relaxed,family=0xe -M rhel6.4.0 -smp 2,maxcpus=2,cores=2,threads=1,sockets=1 -m 2G -enable-kvm -chardev socket,id=111a,path=/tmp/test,server,nowait -mon chardev=111a,mode=readline
3.Update the scsi driver to build 68
4.Run  get_tape.exe in windows cmd

Actual result:
after step4: it always display in cmd "CreateFile:2"

Corinna,Dmitry,could you tell me how to reproduce this issue.
Comment 7 Vadim Rozenfeld 2013-09-05 07:33:06 EDT
(In reply to lijin from comment #6)
> Try to reproduce this issue with following steps:
> 1.Connect to an iscsi disk:/dev/sdf
> 2.Boot win7-32 guest with:
> /usr/libexec/qemu-kvm -drive
> file=/dev/sdf,if=none,cache=none,media=disk,format=raw,id=drive-ide0-0-1
> -device virtio-scsi-pci,id=scsi0 -device
> scsi-hd,drive=drive-ide0-0-1,bus=scsi0.0,id=scsi1,bootindex=0 -global
> PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -usb -device usb-tablet
> -vnc :22 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device
> e1000,netdev=hostnet0,id=net0,mac=52:54:00:7f:f9:F6,bus=pci.0 -monitor stdio
> -chardev file,path=/root/console.log,id=serial1 -device
> isa-serial,chardev=serial1,id=s1 -cpu Penryn,hv_relaxed,family=0xe -M
> rhel6.4.0 -smp 2,maxcpus=2,cores=2,threads=1,sockets=1 -m 2G -enable-kvm
> -chardev socket,id=111a,path=/tmp/test,server,nowait -mon
> chardev=111a,mode=readline
> 3.Update the scsi driver to build 68
> 4.Run  get_tape.exe in windows cmd
> 
> Actual result:
> after step4: it always display in cmd "CreateFile:2"
> 
> Corinna,Dmitry,could you tell me how to reproduce this issue.

It can be tricky. I have no idea what get_tape does, if it sends READ POSITION - it should be fine to use it as a quick test tool. 
For more comprehensive testing I would probably try running HCK against SCSI tape device.
Comment 8 Paolo Bonzini 2013-09-05 13:13:21 EDT
Even running HCK against an emulated SCSI disk device should fail some tests.  Vadim, perhaps you can run the SCSI test from the command-line and find a test that fails?  There are many tests there that are not part of the logo program.
Comment 9 Vadim Rozenfeld 2013-09-06 05:19:16 EDT
(In reply to Paolo Bonzini from comment #8)
> Even running HCK against an emulated SCSI disk device should fail some
> tests.  Vadim, perhaps you can run the SCSI test from the command-line and
> find a test that fails?  There are many tests there that are not part of the
> logo program.

Yes, we can run scsi complains test manually. The problem is that it didn't reveal any problem during WHQL'ing 6.4 drivers. Maybe HCK 8.0/8.1 have more comprehensive set of tests.
Comment 10 Mike Cao 2013-09-06 08:02:31 EDT
(In reply to Vadim Rozenfeld from comment #9)
> (In reply to Paolo Bonzini from comment #8)
> > Even running HCK against an emulated SCSI disk device should fail some
> > tests.  Vadim, perhaps you can run the SCSI test from the command-line and
> > find a test that fails?  There are many tests there that are not part of the
> > logo program.
> 
> Yes, we can run scsi complains test manually. The problem is that it didn't
> reveal any problem during WHQL'ing 6.4 drivers. Maybe HCK 8.0/8.1 have more
> comprehensive set of tests.
Do you mean HCK2.1 ? the matrix of certification test should be same 
Mike
Comment 12 Paolo Bonzini 2013-09-06 11:12:51 EDT
I was using this one with Xen:

http://msdn.microsoft.com/en-us/library/gg607509%28v=vs.85%29.aspx

This test could detect the bug:

Title: ASSERTION: INQUIRY Test for error when PAGE CODE field is nonzero and EVPD=0
Description: Checking that an error is returned when PAGE CODE field is nonzero and EVPD=0.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x2, CHECK CONDITION 

But IIRC this test is only done as part of the disk logo program, not the controller logo program.  That's why WHQL'ing the driver didn't detect the problem.  The SCSI compliance test executable has to be run manually to pick the appropriate testcase.
Comment 13 Vadim Rozenfeld 2013-09-07 05:46:56 EDT
Mike, could you please share or check cpk file from the latest virtio-scsi
submission. I might be wrong, but it definitely should have "StorHDD" logoprogram SCSI compliance tests.

Thanks,
Vadim.
Comment 14 Mike Cao 2013-09-08 22:53:24 EDT
(In reply to Vadim Rozenfeld from comment #13)
> Mike, could you please share or check cpk file from the latest virtio-scsi
> submission. I might be wrong, but it definitely should have "StorHDD"
> logoprogram SCSI compliance tests.
> 
> Thanks,
> Vadim.

Do you mean PCI Hardware Compliance Test For a Single Device (PCIHCT) ? 
you can find previous testing results from https://docspace.corp.redhat.com/docs/DOC-107342 .
Attention that we run virtio-scsi certification as "Stroage Controller "product type instead of "StroHDD" product type or "Optioncal Drive" product type.

Best Regards,
Mike
Comment 15 Mike Cao 2013-10-12 04:58:32 EDT
(In reply to Paolo Bonzini from comment #12)
> I was using this one with Xen:
> 
> http://msdn.microsoft.com/en-us/library/gg607509%28v=vs.85%29.aspx
> 
> This test could detect the bug:
> 
> Title: ASSERTION: INQUIRY Test for error when PAGE CODE field is nonzero and
> EVPD=0
> Description: Checking that an error is returned when PAGE CODE field is
> nonzero and EVPD=0.
> Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published)
> specification Section 6.4.2.
> http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
> Expectation: ScsiStatus == 0x2, CHECK CONDITION 
> 
> But IIRC this test is only done as part of the disk logo program, not the
> controller logo program.  That's why WHQL'ing the driver didn't detect the
> problem.  The SCSI compliance test executable has to be run manually to pick
> the appropriate testcase.

No. Actually I think QE hit this issue.
The reason we did not detect it due to https://sysdev.microsoft.com/en-US/Hardware/EC/FilterDetail.aspx?id=2225 that MSFT would like us to workaound it 

Mike
Comment 16 Mike Cao 2013-10-12 07:02:22 EDT
Created attachment 811556 [details]
HCKX log file
Comment 17 Mike Cao 2013-10-12 07:03:28 EDT
Sorry ,ignore my last comment 
QE tried it on virtio-win-prewhql-71 SCSI Compliance Test Failed 

Re-assigned this issue
Comment 18 Ronen Hod 2014-01-02 05:34:06 EST
Probably fixed on build 74
Comment 19 lijin 2014-02-24 03:50:25 EST
with virtio-win-1.6.8-4.el7.noarch,run "SCSI Compliance Test (LOGO)‎" and "SCSI Compliance Test 2.0" on win2k8-R2 && win8-64 guests,both jobs failed.
I will upload the hck log later.
Comment 20 lijin 2014-02-24 03:53:32 EST
Created attachment 866898 [details]
win2k8-R2-scsi-hck-log
Comment 21 Mike Cao 2014-02-28 01:26:32 EST
re-assigned according to comment #19
Comment 25 Ronen Hod 2014-08-07 03:46:58 EDT
QE, Probably fixed. Can you check?
Comment 26 Vadim Rozenfeld 2014-11-03 03:18:49 EST
I suggest to close this bug as fixed.
Let's create a new one for the problem
mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1003158#c19.

Thanks,
Vadim.
Comment 27 Mike Cao 2014-11-03 22:31:55 EST
(In reply to Vadim Rozenfeld from comment #26)
> I suggest to close this bug as fixed.
> Let's create a new one for the problem
> mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1003158#c19.

OK from QE's side 
But Is it worthy to report a new bug as HCK did not detect SCSI compliance tests automately ?

Mike
> 
> Thanks,
> Vadim.
Comment 28 Vadim Rozenfeld 2014-11-04 03:42:49 EST
(In reply to Mike Cao from comment #27)
> (In reply to Vadim Rozenfeld from comment #26)
> > I suggest to close this bug as fixed.
> > Let's create a new one for the problem
> > mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1003158#c19.
> 
> OK from QE's side 
> But Is it worthy to report a new bug as HCK did not detect SCSI compliance
> tests automately ?

I think yes.
8 out of 107 tests failed last time. Can re-run it again on the most recent rhel 7.1 host?

Cheers,
Vadim.

> 
> Mike
> > 
> > Thanks,
> > Vadim.
Comment 29 Mike Cao 2014-11-04 06:43:24 EST
(In reply to Vadim Rozenfeld from comment #28)
> (In reply to Mike Cao from comment #27)
> > (In reply to Vadim Rozenfeld from comment #26)
> > > I suggest to close this bug as fixed.
> > > Let's create a new one for the problem
> > > mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1003158#c19.
> > 
> > OK from QE's side 
> > But Is it worthy to report a new bug as HCK did not detect SCSI compliance
> > tests automately ?
> 
> I think yes.
> 8 out of 107 tests failed last time. Can re-run it again on the most recent
> rhel 7.1 host?
> 
Sure

dengmin ,pls retest SCSI Compliance Test with win2k8-R2 and Win8-64 bit guest on virtio-win-prewhql-93 on RHEL7.1 host ,feel free to report a new bug w/ the log attached if the test still failed 

Mike
Comment 30 Min Deng 2014-11-07 02:27:33 EST
(In reply to Mike Cao from comment #29)
> (In reply to Vadim Rozenfeld from comment #28)
> > (In reply to Mike Cao from comment #27)
> > > (In reply to Vadim Rozenfeld from comment #26)
> > > > I suggest to close this bug as fixed.
> > > > Let's create a new one for the problem
> > > > mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1003158#c19.
> > > 
> > > OK from QE's side 
> > > But Is it worthy to report a new bug as HCK did not detect SCSI compliance
> > > tests automately ?
> > 
> > I think yes.
> > 8 out of 107 tests failed last time. Can re-run it again on the most recent
> > rhel 7.1 host?
> > 
> Sure
> 
> dengmin ,pls retest SCSI Compliance Test with win2k8-R2 and Win8-64 bit
> guest on virtio-win-prewhql-93 on RHEL7.1 host ,feel free to report a new
> bug w/ the log attached if the test still failed 
> 
> Mike

  According to Mike's comments QE tried the bug with build 93,fortunately the job (SCSI Compliance Test) still failed on win2008R2 and win8-64 Platform.
  Notes,the job isn't included in "Certification" category by default but need me to add additional features and then it could be selected and executed.I will report a new bug about these failures,thanks. 
  Build info,
  kernel-3.10.0-186.el7.x86_64
  qemu-kvm-rhev-2.1.2-1.el7.x86_64u
Comment 31 Mike Cao 2014-11-07 02:31:17 EST
(In reply to dengmin from comment #30)
> (In reply to Mike Cao from comment #29)
> > (In reply to Vadim Rozenfeld from comment #28)
> > > (In reply to Mike Cao from comment #27)
> > > > (In reply to Vadim Rozenfeld from comment #26)
> > > > > I suggest to close this bug as fixed.
> > > > > Let's create a new one for the problem
> > > > > mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1003158#c19.
> > > > 
> > > > OK from QE's side 
> > > > But Is it worthy to report a new bug as HCK did not detect SCSI compliance
> > > > tests automately ?
> > > 
> > > I think yes.
> > > 8 out of 107 tests failed last time. Can re-run it again on the most recent
> > > rhel 7.1 host?
> > > 
> > Sure
> > 
> > dengmin ,pls retest SCSI Compliance Test with win2k8-R2 and Win8-64 bit
> > guest on virtio-win-prewhql-93 on RHEL7.1 host ,feel free to report a new
> > bug w/ the log attached if the test still failed 
> > 
> > Mike
> 
>   According to Mike's comments QE tried the bug with build 93,fortunately
> the job (SCSI Compliance Test) still failed on win2008R2 and win8-64
> Platform.
>   Notes,the job isn't included in "Certification" category by default but
> need me to add additional features and then it could be selected and
> executed.I will report a new bug about these failures,thanks. 
>   Build info,
>   kernel-3.10.0-186.el7.x86_64
>   qemu-kvm-rhev-2.1.2-1.el7.x86_64u

Pls report a new bug for it according to comment #28
Mike
Comment 32 Min Deng 2014-11-07 03:38:10 EST
(In reply to dengmin from comment #30)
> (In reply to Mike Cao from comment #29)
> > (In reply to Vadim Rozenfeld from comment #28)
> > > (In reply to Mike Cao from comment #27)
> > > > (In reply to Vadim Rozenfeld from comment #26)
> > > > > I suggest to close this bug as fixed.
> > > > > Let's create a new one for the problem
> > > > > mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1003158#c19.
> > > > 
> > > > OK from QE's side 
> > > > But Is it worthy to report a new bug as HCK did not detect SCSI compliance
> > > > tests automately ?
> > > 
> > > I think yes.
> > > 8 out of 107 tests failed last time. Can re-run it again on the most recent
> > > rhel 7.1 host?
> > > 
> > Sure
> > 
> > dengmin ,pls retest SCSI Compliance Test with win2k8-R2 and Win8-64 bit
> > guest on virtio-win-prewhql-93 on RHEL7.1 host ,feel free to report a new
> > bug w/ the log attached if the test still failed 
> > 
> > Mike
> 
>   According to Mike's comments QE tried the bug with build 93,fortunately
> the job (SCSI Compliance Test) still failed on win2008R2 and win8-64
> Platform.
>   Notes,the job isn't included in "Certification" category by default but
> need me to add additional features and then it could be selected and
> executed.I will report a new bug about these failures,thanks. 
>   Build info,
>   kernel-3.10.0-186.el7.x86_64
>   qemu-kvm-rhev-2.1.2-1.el7.x86_64u

   New bug,Bug 1161453 - [whql][vioscsi]Job named by SCSI Compliance Test (LOGO) failed on win2k8-R2 and win8-64 guest

Note You need to log in before you can comment on or make changes to this bug.