我们正在开发一个应用程序来管理Windows 10中的NVME设备。我们不应该使用自己的驱动程序与驱动器通信，因此，为了发送大多数命令，我们必须依赖于任何可用的来自Windows 10。
对于Security Receive和Security Send等命令，我们使用他们对SCSI-NVME Translation的支持，其中SCSI命令从主机发送并转换为NVME命令由SCSI内核堆栈，然后发送到驱动器。
我们可以看到命令到达驱动器，但是在Security Receive命令的情况下，转换无法将正确的命名空间标识符发送到驱动器，因此，SCSI在检测数据中返回错误为Access denied, Invalid LU Identifier。
SCSI-NVME转换不允许在其CDB中设置命名空间标识符字段。是否有其他方法可以在我们从主机端发送的SCSI命令中设置此命名空间标识符？或者这是一个驱动程序错误，它将不正确的数据发送到驱动器？
Microsoft的其他API（如存储查询属性）自行设置此命名空间ID，我们不必从用户端设置此名称空间ID。
如果有人在类似的环境中工作过，可以帮助我们，那将会非常有帮助。
答案 0 :(得分：0)
这是一个有趣的问题，我不完全确定Windows 10驱动程序如何在内部工作，但就规范打算如何使用此转换而言，您不应该明确指定用户空间中的NSID。
在我使用过的所有Windows NVMe驱动程序上，控制器都通过它的适配器句柄公开，命名空间由物理驱动器句柄公开。目的是SCSI命令转到物理驱动器句柄，本机NVMe命令转到适配器。如果将SCSI命令发送到物理驱动器句柄，则预期的命名空间是隐式的，因为每个句柄都直接连接到命名空间，因此应在转换期间将其设置为驱动程序。这绝对是它在OFA（OpenFabrics Alliance）驱动程序和所有衍生品上的工作原理。
如果要将SCSI命令发送到物理驱动器并且命名空间未填写，则听起来像是驱动程序错误。如果要将SCSI命令发送到适配器（并且它不会被OS /驱动程序拒绝），请尝试将其发送到与所需命名空间ID相对应的物理驱动器。
答案 1 :(得分：0)
我失去了这个道路，道歉:(。是的，你说对于发送scsi命令是正确的，它应该被发送到物理驱动器句柄。在Windows 10中，即使是发送适用于适配器的命令，也就是识别控制器，我们使用相同的句柄（Physicaldrive句柄），并且有一个单独的字段提到这是适用于适配器。 回到最初的问题，这是与名称空间管理相关的固件错误。当系统启动时，Windows驱动程序从NVME驱动器中读取大量内容，并且只要发送特定命令，它们就会在内部维护并从该源读取。由于Windows的这种行为，您认为严格附加到命名空间的物理驱动句柄是正确的10个驱动程序。由于固件错误，到达驱动器的是命名空间0，这是无效的namespaceId因此被拒绝。 使用固定固件，此问题已消失，命令正确响应！
干杯！