[nvmewin] New Patch From PMC Ready For Review/Test

[Judy Brock-SSI]

Hi Alex,

>> In order to pass Inquiry command, Device Identification VPD Page (part of NVMe SCSI Compliance test), the driver
needs to report SCSI Name String Designation Descriptor (Type 8). For the time being, I added reporting the string
as "SCSINVMe". You may change it to whatever strings as you wish. Judy from Samsung is working
on definition of the string as well.

As you know, there is a v1.4 draft proposal of the NVMe-to-SCSI translation reference under development in NVMe committee right now. We hope to have a vote for 30 day approval within the next couple of weeks.  Below is the Samsung-proposed section on SCSI Name String Designator Descriptor which has been through several rounds of review  – maybe the patch should sync up with this definition in anticipation of ratification over the next couple of months:
1.1.1.1       SCSI Name String Designator

Table 6‑8: SCSI name string Designation Descriptor
SCSI Name String Descriptor Field

Notes and References

PROTOCOL IDENTIFIER

Shall be set to 0h.  PIV field shall indicate this field is reserved as no specific protocol to be identified.

CODE SET

Shall be set to 3h indicating associated fields are in UTF-8 format.

PIV

Shall be set to 0b indicating PROTOCOL IDENTIFIER field is reserved.

ASSOCIATION

Shall be set to 00b indicating DESIGNATOR field is associated with logical unit.

DESIGNATOR TYPE

Shall be set to 8h indicating SCSI name string format and assignment authority.

DESIGNATOR LENGTH

Shall be set to size of SCSI NAME STRING field.

SCSI NAME STRING

See section  6.1.4.4.1.

1.1.1.1.1                                         SCSI NAME STRING field
For  NVMe devices compliant with revision 1.1 or later:

If the 64 bit EUI64 field in the NVMe Identify Namespace data structure is used to specify a globally unique namespace identifier when the namespace is created:
Shall  be set to a 20 byte UTF-8 character field comprised of the four UTF-8 characters 'eui.' concatenated with UTF-8 representation of the 16 hexadecimal digits corresponding to the 64 bit EUI64 field of the Identify Namespace Data Structure. The first hexadecimal digit shall be the most significant four bits of the first byte (i.e., most significant byte) of the EUI-64 field.

If the 128 bit NGUID field in the Identify Namespace data structure is used to specify a globally unique namespace identifier when the namespace is created:
Shall  be set to a 36 byte UTF-8 character field  comprised of the four UTF-8 characters 'eui.' concatenated with UTF-8 representation of the 32 hexadecimal digits corresponding to the 128 bit NGUID field of the Identify Namespace Data Structure. The first hexadecimal digit shall be the most significant four bits of the first byte (i.e., most significant byte) of the NGUID field.

For NVMe devices compliant with revision 1.0:
Shall be set to a 68 byte UTF-8 character field comprised of 4 bytes of UTF-8 representation of 2 byte PCI Vendor ID, plus 40 bytes of Model Number, plus 4 bytes of UTF-8 representation of Namespace ID, plus 20 bytes of Serial Number. Note: the start of the string (MSB) is at the lowest byte offset and the end of the string (LSB) is at the highest byte offset:

·        Bytes 67:48: 20 bytes of Serial Number(bytes 23:04 of Identify Controller data structure)

·        Bytes 47:44: 4 bytes of Namespace ID (UTF-8 representation)

·        Bytes 43:04: 40 bytes of Model Number(bytes 63:24 of Identify Controller data structure)

·        Bytes 03:00:  4 bytes of PCI Vendor ID (UTF-8 representation) (bytes 01:00 of Identify Controller converted to 4 UTF-8 characters

Thanks,
Judy

From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, November 18, 2014 3:31 PM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] New Patch From PMC Ready For Review/Test

Dear all,

Please find the attached patch from PMC. Password is pmc123.
The following tests had been completed on Windows 7, 8,  8.1, Windows Server 2012, 2012 R2.
- Disk Formats (Quick and Full formats)
- IOMeter read/write accesses
- SDStress
- NVMe SCSI Compliance
- Install/Uninstall driver
- Disable/Enable driver
- All WHQL tests passed with HCK 8.100.26795 on Windows Server 2012 R2, except the following tests exempted via Errata ID 4693:
1. NVMe Device Capabilities
2. NVMe Queue Pause-Resume
3. NVMe Queue Utilization

The changes of this patch includes two portions: WHQL related changes and Format NVM changes.
< WHQL related changes >
1. For "Static Tools Logo test" on server systems, it requires Driver Verification Logs.
Most current WDK bundled with VS2013 has a known issue that has a conflict in function
prototype definition for StorPortReadRegisterUlong64. Due to the conflict, Code Analysis fails
and can't generate Code Analysis log. Therefore, we have to fall back to use
StorPortReadRegisterUlong for the time being in nvmeInit.c and nvmestd.c

2. Added function type declarations in nvmeStd.h in order to pass Static Driver Verifier and
generate SDV log.

3. In order to pass Inquiry command, Device Identification VPD Page (part of NVMe SCSI Compliance test), the driver
needs to report SCSI Name String Designation Descriptor (Type 8). For the time being, I added reporting the string
as "SCSINVMe". You may change it to whatever strings as you wish. Judy from Samsung is working
on definition of the string as well.

< Format NVM Changes >
1. Added storportdebugprints in nvmesnti.c.

2. In nvmestd.c and nvmestd.h :
- Added NVMeIsReadWritCmd
- In NVMeBuildIo, block Read/write commands while Format NVM is in progress.
- Added one parameter of NVMeIsNamespaceVisible to allow specifying the target namespaceID.
- Added NVMeFormatNVMHotRemoveNamespace and NVMeFormatNVMHotAddNamespace
- Changed the state machine transitions/processes in NVMeIoctlFormatNVMCallback

Please review/test the patch and provide your feedback at your earliest convenience. Thank you very much.

Regards,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20141120/89125586/attachment.html>