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.
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!