1

We are developing an application to manage NVME Devices in Windows 10. We are not supposed to use our own driver to talk to drives, so for sending most of the commands, we have to rely on whatever is available from Windows 10.

For commands like Security Receive and Security Send, we are using their support of SCSI-NVME Translation, in which a SCSI command is sent from the host and is translated to NVME command by the SCSI kernel stack, and then sent to the drive.

We can see the commands are reaching the drive, but the translation is not able to send the correct namespace identifier to the drive in case of the Security Receive command, and therefore, SCSI is returning a error in sense data as Access denied, Invalid LU Identifier.

SCSI-NVME translation does not allow setting a namespace identifier field in its CDB. Is there any other way for setting this namespace identifier in the SCSI command that we are sending from the host side? Or is this a driver error that its sending incorrect data to the drive?

Other APIs of Microsoft (like Storage Query Property) set this namespace ID by themselves, and we don't have to set this from user side.

If anybody who has worked in similar kind of environment, can help us out, it will be very helpful.

Insane Skull
  • 9,220
  • 9
  • 44
  • 63
Ravi
  • 41
  • 5
  • Just to rephrase the question again, I want to know how a namespace Identifier is set via SCSI Command whenever we use SCSI-NVME Translation approach to send Commands to NVME Drive. The SCSI-NVME Translation Spec that I am using does not talk about how NameSpace Identifier is set in CDB. Namespace Identifier is an important field in NVME Command Structure. – Ravi Apr 19 '16 at 09:00
  • Improved formatting and wording. – CodeMouse92 Apr 20 '16 at 03:44
  • Ok! I will take care next time. – Ravi Apr 20 '16 at 06:49
  • I'm not sure why this is downvoted. At least the way it stands now, it seems relatively clear - though I don't have an answer for you! – Mike Andrews Apr 20 '16 at 19:01

2 Answers2

0

This is an interesting question, I'm not entirely sure how the Windows 10 driver works on the inside but in terms of how the specification intends for this translation to work, you shouldn't need to explicitly specify a NSID in userspace.

On all Windows NVMe drivers I've worked with, the controller is exposed by it's adapter handle and the namespaces are exposed by physical drive handles. The intention is that SCSI commands go to physical drive handles and native NVMe commands go to the adapter. If you send the SCSI command to the physical drive handle, the intended namespace is implicit as each one of those handles is directly connected to a namespace and therefore should be set be the driver during the translation. This is definitely how it works on the OFA (OpenFabrics Alliance) Driver and on all derivatives.

If you are sending the SCSI command to the physical drive and the namespace isn't filled in, it sounds like a driver bug. If you are sending the SCSI command to the adapter, (and it doesn't get rejected by the OS/driver), try sending it to the physical drive corresponding with the desired namespace id.

csm10495
  • 569
  • 6
  • 12
0

I lost the track of this, apologies :(. Yes, you are right that for sending scsi commands, it should be sent to physical drive handles. In Windows 10, even for sending commands which are meant for adapter too, like Identify Controller, we use the same handle (Physicaldrive handle) and there is a separate field to mention that this is meant for adapter. Coming back to the original question, this was firmware bug related to namespace management. Windows drivers reads a lot of stuffs from NVME drives when system is booting up and they maintain that inside themselvs and read from that source whenever a particular command is sent.Your assumption of physicaldrive handles strictly attached to Namespaces is correct because of this behaviour of Windows 10 drivers.Because of firmware bug, what was reaching to drive, was namespace 0, which is invalid namespaceId and hence rejected. With the fixed firmware, this issue was gone and command was responding correctly!

Cheers!

Ravi
  • 41
  • 5