SCSI到NVME翻译

Question

我们正在开发一个应用程序来管理Windows10中的NVME设备，我们不应该使用我们自己的驱动程序与驱动器对话，所以在发送大部分命令时，我们必须依赖于从Windows 10中获得的任何可用的命令。

对于像Security Receive和Security Send这样的命令，我们使用它们对SCSI-NVME转换的支持，其中SCSI命令从主机发送，然后由SCSI内核堆栈转换成NVME命令，然后发送到驱动器。

我们可以看到命令正在到达驱动器，但是转换不能在Security Receive命令的情况下向驱动器发送正确的命名空间标识符，因此，SCSI以Access denied, Invalid LU Identifier的形式返回一个错误的数据。

SCSI-NVME转换不允许在其CDB中设置命名空间标识符字段。在我们从主机端发送的SCSI命令中，还有其他方法来设置这个命名空间标识符吗？或者这是一个驱动程序错误，它发送不正确的数据到驱动器？

Microsoft的其他API(如Storage属性)自行设置此命名空间ID，我们不必从用户端设置此名称空间ID。

如果任何在类似环境中工作过的人都能帮助我们，那将是非常有帮助的。

Answer 1

我搞不懂这件事，抱歉：是的，对于发送scsi命令，应该将它发送到物理驱动器句柄，这是正确的。在Windows 10中，即使是发送用于适配器的命令，比如标识控制器，我们也使用相同的句柄(Physicaldrive句柄)，并且有一个单独的字段来说明这是用于适配器的。回到最初的问题，这是与命名空间管理相关的固件错误。Windows驱动程序在系统启动时会从NVME驱动器读取大量内容，并且他们认为，只要有特定命令，只要某个特定命令是sent.Your，就会从它们的内部读取。物理驱动器句柄严格连接到命名空间的假设是正确的，因为Windows 10 drivers.Because的固件错误(即将到达驱动的位置)的行为是命名空间0，这是无效的namespaceId，因此被拒绝。与固定固件，这个问题已经消失，命令是正确的响应！

干杯!

Answer 2

这是一个有趣的问题，我不完全确定Windows 10驱动程序是如何内部工作的，但就规范如何实现此转换而言，您不需要在用户空间中显式指定NSID。

在我使用过的所有Windows驱动程序中，控制器由适配器句柄公开，命名空间由物理驱动器句柄公开。目的是让SCSI命令转到物理驱动器句柄，而本机NVMe命令转到适配器。如果将SCSI命令发送到物理驱动器句柄，则将隐含预期的命名空间，因为这些句柄中的每个句柄都直接连接到命名空间，因此在转换期间应该设置为驱动程序。这无疑是它在OFA (OpenFabrics联盟)驱动程序和所有衍生品上的工作方式。

如果要将SCSI命令发送到物理驱动器，而命名空间未被填充，则听起来像是驱动程序错误。如果要将SCSI命令发送到适配器(并且它不会被OS/驱动程序拒绝)，请尝试将它发送到与所需的命名空间id相对应的物理驱动器。