On 1/13/21 4:34 PM, Sagi Grimberg wrote:

quoted

Hello,
We see that when executing nvme connect cmd (Opcode: 0x7f Fabric Cmd)
The host is submitting the cmd with reserved filed set to non-zero 
value - which is out of spec.
Seems like this issue is not only for connect but also for other 
fabrics cmds.

Here is a packet capture for nvme connect :

     NVM Express Fabrics (Cmd)
         Opcode: 0x7f Fabric Cmd
         [Fabric Cqe in: 302]
         Reserved: 0x40
         Command ID: 0x0000
         Fabric Cmd Type: Connect (0x01)
         Reserved: 00000000000000000000000000000000000000
         SGL1
         Record Format: 0x0000
         Queue ID: 0x0000
         SQ Size: 0x001f
         Connect Attributes: 0x00
         Reserved: 00
         Keep Alive Timeout: 15000ms
         Reserved: 000000000000000000000000
     Data
         Host Identifier: f1aa9784-195b-4814-893d-44f90a6a92d9
         Controller ID: 0xffff
         Reserved: 
000000000000000000000000000000000000000000000000000000000000000000000000... 

         Subsystem NQN: 
nqn.2015-10.com.dell:dellemc-powerstore-23b5145591975EDFF2FE
         Host NQN: nqn.2014-08.org.nvmexpress:uuid:nc5199007
         Reserved: 
000000000000000000000000000000000000000000000000000000000000000000000000... 


0x40 value is corresponding to PSDT, in a normal (non-fabric) nvme 
cmd, PSDT field exists.
Do we expect for the same for fabric cmd?
If so, the spec can't mark the second byte of connect cmd as reserved.
Based on nvme spec:
"A reserved bit, byte, word, field, or register shall be cleared to 
0h, or in accordance with a future extension to this specification"

Is this a real bug or a spec bug?

We shouldn't be setting reserved bits. But from what I see, we zero the 
nvme commands before setting it so this is strange to me..

OK, now I see the issue.

This appears to me this would be an issue with the spec. As the connect
data (like any command payload) is coming in the form of an sgl.

Adding Fred for this question.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme