fabrics connect cmd with a non-zero reserved value

[Sagi Grimberg]

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