From raymond.c.robles at intel.com Sun Aug 2 13:42:06 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Sun, 2 Aug 2015 20:42:06 +0000 Subject: [nvmewin] Amy way to avoid loading inbox NVMe driver in WINPE In-Reply-To: References: Message-ID: <49158E750348AA499168FD41D88983606B6EC3CF@fmsmsx117.amr.corp.intel.com> Hi Abhijit, Normally, when installing a Windows OS, there is an option to “load a driver” just before kicking off the install (on the same page as the disk partition layout). It is here that you could specify your desired driver, vs. the MS inbox driver, to load and run during an install. This was often referred to as the “F6 Install”. However, I’ve never tried this with WinPE. It may be worth investigating. Anyone else tried an “F6 Install” on WinPE? Thanks, Ray Robles From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Abhijit Khande Sent: Thursday, July 30, 2015 6:57 PM To: nvmewin Subject: [nvmewin] Amy way to avoid loading inbox NVMe driver in WINPE Hi All, Is there any way to avoid loading inbox NVMe driver in WINPE during OS installation? Currently after booting in WINPE the class/sub-class code matched and inbox NVMme claims the device and PDOs gets exposesed to class driver. Any way to avoid this stack getting buildup using by inbox driver and load our driver. Thanks, AK -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhijit.khande at gmail.com Mon Aug 3 11:02:55 2015 From: abhijit.khande at gmail.com (Abhijit Khande) Date: Mon, 3 Aug 2015 23:32:55 +0530 Subject: [nvmewin] Amy way to avoid loading inbox NVMe driver in WINPE In-Reply-To: <49158E750348AA499168FD41D88983606B6EC3CF@fmsmsx117.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606B6EC3CF@fmsmsx117.amr.corp.intel.com> Message-ID: Hi Ray, Thanks for this data. But I want to avoid loading inbox NVMe driver (StorNvme.sys) while OS installation in WINPE. Currently if we boot in WINPE during OS installation inbox NVMe gets loaded and claim NVMe drives. This I want to avoid. I want to avoid loading inbox NVMe and load our open-source driver and claim the NVMe devices Thanks, Abhijit On Mon, Aug 3, 2015 at 2:12 AM, Robles, Raymond C < raymond.c.robles at intel.com> wrote: > Hi Abhijit, > > > > Normally, when installing a Windows OS, there is an option to “load a > driver” just before kicking off the install (on the same page as the disk > partition layout). It is here that you could specify your desired driver, > vs. the MS inbox driver, to load and run during an install. This was often > referred to as the “F6 Install”. > > > > However, I’ve never tried this with WinPE. It may be worth investigating. > > > > Anyone else tried an “F6 Install” on WinPE? > > > > Thanks, > > Ray Robles > > > > *From:* nvmewin-bounces at lists.openfabrics.org [mailto: > nvmewin-bounces at lists.openfabrics.org] *On Behalf Of *Abhijit Khande > *Sent:* Thursday, July 30, 2015 6:57 PM > *To:* nvmewin > *Subject:* [nvmewin] Amy way to avoid loading inbox NVMe driver in WINPE > > > > Hi All, > > > > Is there any way to avoid loading inbox NVMe driver in WINPE during OS > installation? > > Currently after booting in WINPE the class/sub-class code matched and > inbox NVMme claims the device and PDOs gets exposesed to class driver. > > > > Any way to avoid this stack getting buildup using by inbox driver and load > our driver. > > > > Thanks, > > AK > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Mon Aug 3 13:10:26 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Mon, 3 Aug 2015 20:10:26 +0000 Subject: [nvmewin] Amy way to avoid loading inbox NVMe driver in WINPE In-Reply-To: References: <49158E750348AA499168FD41D88983606B6EC3CF@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983606B6ECC33@fmsmsx117.amr.corp.intel.com> Hi Abhijit, Understood. And the process I outline below is exactly for that. To load a third party driver during the OS install (via the “Load Drivers” option). If you do not select this option during the OS install, the MS inbox driver will claim the NVMe device. But if you load a driver during the OS install, for example our OFA driver, then the OFA driver will claim the NVMe device. Thanks, Ray From: Abhijit Khande [mailto:abhijit.khande at gmail.com] Sent: Monday, August 03, 2015 11:03 AM To: Robles, Raymond C Cc: nvmewin Subject: Re: [nvmewin] Amy way to avoid loading inbox NVMe driver in WINPE Hi Ray, Thanks for this data. But I want to avoid loading inbox NVMe driver (StorNvme.sys) while OS installation in WINPE. Currently if we boot in WINPE during OS installation inbox NVMe gets loaded and claim NVMe drives. This I want to avoid. I want to avoid loading inbox NVMe and load our open-source driver and claim the NVMe devices Thanks, Abhijit On Mon, Aug 3, 2015 at 2:12 AM, Robles, Raymond C > wrote: Hi Abhijit, Normally, when installing a Windows OS, there is an option to “load a driver” just before kicking off the install (on the same page as the disk partition layout). It is here that you could specify your desired driver, vs. the MS inbox driver, to load and run during an install. This was often referred to as the “F6 Install”. However, I’ve never tried this with WinPE. It may be worth investigating. Anyone else tried an “F6 Install” on WinPE? Thanks, Ray Robles From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Abhijit Khande Sent: Thursday, July 30, 2015 6:57 PM To: nvmewin Subject: [nvmewin] Amy way to avoid loading inbox NVMe driver in WINPE Hi All, Is there any way to avoid loading inbox NVMe driver in WINPE during OS installation? Currently after booting in WINPE the class/sub-class code matched and inbox NVMme claims the device and PDOs gets exposesed to class driver. Any way to avoid this stack getting buildup using by inbox driver and load our driver. Thanks, AK -------------- next part -------------- An HTML attachment was scrubbed... URL: From iuliur at google.com Mon Aug 3 13:36:34 2015 From: iuliur at google.com (Iuliu Rus) Date: Mon, 3 Aug 2015 13:36:34 -0700 Subject: [nvmewin] NVME fuzz test fixes Message-ID: Hello, I have attached the fixes we (Google) did for the several crashes / corruptions exposed by the Windows HCK fuzztest.exe. We have tested this on qemu/ Server 2012 R2. The password on the zip is "nvme" :) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fuzz_fixes.zip Type: application/zip Size: 2048110 bytes Desc: not available URL: From iuliur at google.com Mon Aug 3 13:39:53 2015 From: iuliur at google.com (Iuliu Rus) Date: Mon, 3 Aug 2015 13:39:53 -0700 Subject: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers In-Reply-To: <49158E750348AA499168FD41D88983606B6EA959@fmsmsx117.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606B63477F@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B656163@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6697AD@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B669C18@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6EA959@fmsmsx117.amr.corp.intel.com> Message-ID: Thank you, I have sent the first patch containing the fuzz test fixes. We really hope you will consider patch process changes. Sending zips across is error prone as somebody will have to manually merge changes. Besides the time spent, we run the risk of regressing some earlier change and negate half of the benefits of a source control. Also, dealing with code reviews is harder than it needs to be (as github has them associated with the precise code line and so on). On Thu, Jul 30, 2015 at 2:25 PM, Robles, Raymond C < raymond.c.robles at intel.com> wrote: > Hi Iuliu, > > > > I thought I responded to this email, but in case I didn’t…. > > > > For now, I would suggest separating the patch into smaller patches. The > use of SVN is not dictated by the NVMeWin group, but rather the OFA (Open > Fabrics Alliance) website, and its administrators. > > > > If there were/are enough requests to migrate to github, I could call a > meeting to discuss moving to another host website. But the process would > not be quick, especially since we are starting to get patches for the end > of year release. > > > > Thanks, > Ray > > > > *From:* Iuliu Rus [mailto:iuliur at google.com] > *Sent:* Thursday, June 25, 2015 12:06 PM > > *To:* Robles, Raymond C > *Cc:* nvmewin at lists.openfabrics.org > *Subject:* Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for > patch volunteers > > > > Raymond, we are running the windows HCK fuzz test on the driver and it > exposes several crashes. Also, on SCSIOP_START_STOP_UNIT it looks > like SntiTransitionPowerState builds an io which it never submits, causing > Windows to eventually reset the adapter. > > Given that some of these fuzz crashes are potential security issues, we > are getting ready to submit the patch next week. However it is rather big > and the current patch submission process doesn't work that well. We would > like to break it into separate changes, but with zipped thrunk this is not > possible. Is there any way to switch this over to github so we can use pull > requests instead? Or, should we do separate submissions for now? > > > > On Tue, Jun 2, 2015 at 3:35 PM, Iuliu Rus wrote: > > Raymond, given this, project we are going to wait for QEMU to accept the > virtualization extensions first ( > http://git.infradead.org/users/kbusch/qemu-nvme.git/commit/162ec6479447abbd76308f831f36703aa3acc485), > then submit our payload which includes what we previously discussed and the > windows implementation for the nvme doorbell extensions. > > > > On Fri, May 15, 2015 at 11:38 AM, Robles, Raymond C < > raymond.c.robles at intel.com> wrote: > > Hi Iuliu, > > > > The process for submitting a patch is quite simple (by design). The steps > are as follows: > > > > 1. Download the current latest trunk source via an SVN client (i.e. > TortoiseSVN). I assume you’ve already done this. > > 2. In the Releases folder, under a specific release, there are > readme.txt files that explain the build environment needed. Insure you can > compile the trunk with the recommended tool/build set. > > 3. Port your changes over to the trunk. > > 4. Unit test your changes on the trunk source. > > 5. Run the required testing outlined in the file attached in this > email and insure all tests are passing. > > 6. Send an email with the trunk source zipped (with your ported > changes) to this email distribution list. > > 7. The three reviewing companies will review your changes and also > run the tests in the file. > > 8. If all looks good, then the source maintainer will merge your > changes to the trunk, and create a tag. > > 9. If there are any question/comments that require a modifications > to you patch, then go back to step 4 after you’ve made any changes and > complete the process again. > > > > Let me know if you have any further questions. Feel free to add both > patches into a single submission. > > > > You should be able to download all tools necessary outlined in the file. > Let us know if you need assistance. > > > > Thanks, > > Ray > > > > *From:* Iuliu Rus [mailto:iuliur at google.com] > *Sent:* Thursday, May 14, 2015 11:02 PM > > > *To:* Robles, Raymond C > *Cc:* nvmewin at lists.openfabrics.org > *Subject:* Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for > patch volunteers > > > > Can you please point me to the instructions on how to send the patch? > > As for the free q list issue, we enabled driver verifier and under stress > it bugchecked in RtlpCheckListEntry. > > > > On Thu, May 14, 2015 at 10:52 PM, Robles, Raymond C < > raymond.c.robles at intel.com> wrote: > > Hello, > > > > We always welcome companies to submit patches for candidate features. No > other company has volunteered for concurrent channels at this time. We > would gladly welcome your patch at your earliest convenience. The first > release for 2015 is planned for ~August/September... would you like to > volunteer for this patch prior to this release? > > > > As for a race condition synchronization fix for FreeQList, could you > please describe the issue you were seeing and how you addressed it? > > > > Thanks, > > Ray > > > > *From:* Iuliu Rus [mailto:iuliur at google.com] > *Sent:* Thursday, May 14, 2015 7:43 PM > *To:* Robles, Raymond C > *Cc:* nvmewin at lists.openfabrics.org > *Subject:* Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for > patch volunteers > > > > Hello, > > We are the google compute engine team and we already have Concurrent > channels working. We're still figuring out how we can integrate between our > internal repo and svn. > > Do you still need this feature? > > We also have a synchronization fix for a race that corrupted FreeQList. > > > > On Thu, May 7, 2015 at 3:46 PM, Robles, Raymond C < > raymond.c.robles at intel.com> wrote: > > All, > > > > I just wanted to send out a quick update on the release plans for 2015. > We’ve had two more companies volunteer to submit patches this year: Samsung > (Suman) and HGST (Tom). Thank you to both companies for volunteering! > > > > Here is the updated release plan for 2015. Unfortunately, some of the > patch submissions will be a little later than originally planned. > Therefore, I would like to ask the question: *is everyone ok if we push > the first release out until end of August to allow for more patches to be > submitted?* You can response publicly or just to me. > > > > Other alternatives would include just having smaller releases at different > cadences. I’m open to any ideas since there are still many requests for > features that have claimed for patch submission. > > > > > > *2015 Release #1 (Q2/Q3 – 2015)* > > > > *Feature* > > *Description* > > *Submitter* > > *Date* > > Concurrent Channels > > Start I/O Concurrent Channels allows StartIo to be called in parallel > resulting in improved IOPS. > > > > > > Perf Opts > > Instead of learning cores, use perf opts. Shave off 2 seconds in init > code… using Storport initialize perf opts. No need for source core > interrupt steering code in driver. > > Samsung (Suman) > > End of June > > Win 8.1 Timers > > Storport Notification usage. Hot plug and IOCTLs, this does not work, for > Win8.1… StorportRequestTimer() function needed. > > Samsung (Suman) > > End of July > > CFS Bit Monitoring > > CFS bit monitoring and handling. Look into adding additional handling code > just to monitor CSTS.CFS. > > > > > > EOL - Read Only > > Read only support for devices at EOL. Detection at init, hot plug, or > run-time. > > Samsung (Suman) > > End of August > > Namespace Mgmt > > Namespace management - creation and deletion of namespaces. > > Intel (Carolyn) > > End of June > > WHQL > > WHQL test suite run (any bug fixes). > > > > > > > > > > *2015 Release #2 (Q4 – 2015)* > > > > *Feature* > > *Description* > > *Submitter* > > *Date* > > Multi-Path > > Multipath feature set from 1.1 spec (Multi-path I/O, Namespace Sharing, > Reservations) > > HGST (Tom) > > Mid-November > > RTD3 > > Active/idle RTD3 > > > > > > Temp Thresholds > > Temperature thresholds (Get/Set Feature and AER trigger) > > > > > > Live FW Update > > Live firmware update > > > > > > Atomicity > > Atomicity Enhancements > > > > > > Win 10 > > Win 10 support (push to Q4 release) > > > > > > SNTL > > SNTL 1.5 doc updates > > HGST (Tom) > > End of August > > WHQL > > WHQL test suite run (any bug fixes) - for each release of OFA > > > > > > > > Thanks, > > Ray > > > > *From:* nvmewin-bounces at lists.openfabrics.org [mailto: > nvmewin-bounces at lists.openfabrics.org] *On Behalf Of *Robles, Raymond C > *Sent:* Thursday, April 09, 2015 5:29 PM > *To:* nvmewin at lists.openfabrics.org > *Subject:* [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch > volunteers > > > > All, > > > > As we enter Q2, I’m happy to announce that we a have a very good feature > plan in place for both Q2 and Q4 releases in 2015 of the OFA driver. The > list of requested features is included below for final review. > > > > I would like to formally ask for volunteers for patch submissions. As of > today, there are no volunteers for any of the below patches. > > > > Intel would like to start with the volunteering… we will volunteer to > provide the namespace management patch. > > > > *2015 Release #1 (Q2/Q3 – 2015)* > > > > *Feature* > > *Description* > > *Submitter* > > *Date* > > Concurrent Channels > > Start I/O Concurrent Channels allows StartIo to be called in parallel > resulting in improved IOPS. > > > > > > Perf Opts > > Instead of learning cores, use perf opts. Shave off 2 seconds in init > code… using Storport initialize perf opts. No need for source core > interrupt steering code in driver. > > Samsung (Suman) > > End of June > > Win 8.1 Timers > > Storport Notification usage. Hot plug and IOCTLs, this does not work, for > Win8.1… StorportRequestTimer() function needed. > > Samsung (Suman) > > End of July > > CFS Bit Monitoring > > CFS bit monitoring and handling. Look into adding additional handling code > just to monitor CSTS.CFS. > > > > > > EOL - Read Only > > Read only support for devices at EOL. Detection at init, hot plug, or > run-time. > > Samsung (Suman) > > End of August > > Namespace Mgmt > > Namespace management - creation and deletion of namespaces. > > Intel (Carolyn) > > End of June > > WHQL > > WHQL test suite run (any bug fixes). > > > > > > > > > > *2015 Release #2 (Q4 – 2015)* > > > > *Feature* > > *Description* > > *Submitter* > > *Date* > > Multi-Path > > Multipath feature set from 1.1 spec (Multi-path I/O, Namespace Sharing, > Reservations) > > HGST (Tom) > > Mid-November > > RTD3 > > Active/idle RTD3 > > > > > > Temp Thresholds > > Temperature thresholds (Get/Set Feature and AER trigger) > > > > > > Live FW Update > > Live firmware update > > > > > > Atomicity > > Atomicity Enhancements > > > > > > Win 10 > > Win 10 support (push to Q4 release) > > > > > > SNTL > > SNTL 1.5 doc updates > > HGST (Tom) > > End of August > > WHQL > > WHQL test suite run (any bug fixes) - for each release of OFA > > > > > > > > > > Thanks, > > Ray > > > > *Raymond C. Robles* > > NSG ISE Host Storage Software > > Intel Corporation > > Office: 480-554-2600 > > Mobile: 480-399-0645 > > > > > _______________________________________________ > nvmewin mailing list > nvmewin at lists.openfabrics.org > http://lists.openfabrics.org/mailman/listinfo/nvmewin > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iuliur at google.com Mon Aug 3 13:41:57 2015 From: iuliur at google.com (Iuliu Rus) Date: Mon, 3 Aug 2015 13:41:57 -0700 Subject: [nvmewin] NVME fuzz test fixes In-Reply-To: References: Message-ID: To make the process smoother I will also mention that the only changes in this patch are to the nvmeSnti.c file - although i included a full zip as per the change submission process. On Mon, Aug 3, 2015 at 1:36 PM, Iuliu Rus wrote: > Hello, > I have attached the fixes we (Google) did for the several crashes / > corruptions exposed by the Windows HCK fuzztest.exe. > We have tested this on qemu/ Server 2012 R2. > The password on the zip is "nvme" :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Mon Aug 3 16:31:49 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Mon, 3 Aug 2015 23:31:49 +0000 Subject: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers In-Reply-To: References: <49158E750348AA499168FD41D88983606B63477F@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B656163@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6697AD@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B669C18@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6EA959@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983606B6ED4CE@fmsmsx117.amr.corp.intel.com> Thanks Iuliu. Your patch is third in line right now (two patches ahead of you). I’ll go ahead and schedule an OFA meeting to discuss a few times, including migrating to github. Thanks, Ray From: Iuliu Rus [mailto:iuliur at google.com] Sent: Monday, August 03, 2015 1:40 PM To: Robles, Raymond C Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers Thank you, I have sent the first patch containing the fuzz test fixes. We really hope you will consider patch process changes. Sending zips across is error prone as somebody will have to manually merge changes. Besides the time spent, we run the risk of regressing some earlier change and negate half of the benefits of a source control. Also, dealing with code reviews is harder than it needs to be (as github has them associated with the precise code line and so on). On Thu, Jul 30, 2015 at 2:25 PM, Robles, Raymond C > wrote: Hi Iuliu, I thought I responded to this email, but in case I didn’t…. For now, I would suggest separating the patch into smaller patches. The use of SVN is not dictated by the NVMeWin group, but rather the OFA (Open Fabrics Alliance) website, and its administrators. If there were/are enough requests to migrate to github, I could call a meeting to discuss moving to another host website. But the process would not be quick, especially since we are starting to get patches for the end of year release. Thanks, Ray From: Iuliu Rus [mailto:iuliur at google.com] Sent: Thursday, June 25, 2015 12:06 PM To: Robles, Raymond C Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers Raymond, we are running the windows HCK fuzz test on the driver and it exposes several crashes. Also, on SCSIOP_START_STOP_UNIT it looks like SntiTransitionPowerState builds an io which it never submits, causing Windows to eventually reset the adapter. Given that some of these fuzz crashes are potential security issues, we are getting ready to submit the patch next week. However it is rather big and the current patch submission process doesn't work that well. We would like to break it into separate changes, but with zipped thrunk this is not possible. Is there any way to switch this over to github so we can use pull requests instead? Or, should we do separate submissions for now? On Tue, Jun 2, 2015 at 3:35 PM, Iuliu Rus > wrote: Raymond, given this, project we are going to wait for QEMU to accept the virtualization extensions first (http://git.infradead.org/users/kbusch/qemu-nvme.git/commit/162ec6479447abbd76308f831f36703aa3acc485), then submit our payload which includes what we previously discussed and the windows implementation for the nvme doorbell extensions. On Fri, May 15, 2015 at 11:38 AM, Robles, Raymond C > wrote: Hi Iuliu, The process for submitting a patch is quite simple (by design). The steps are as follows: 1. Download the current latest trunk source via an SVN client (i.e. TortoiseSVN). I assume you’ve already done this. 2. In the Releases folder, under a specific release, there are readme.txt files that explain the build environment needed. Insure you can compile the trunk with the recommended tool/build set. 3. Port your changes over to the trunk. 4. Unit test your changes on the trunk source. 5. Run the required testing outlined in the file attached in this email and insure all tests are passing. 6. Send an email with the trunk source zipped (with your ported changes) to this email distribution list. 7. The three reviewing companies will review your changes and also run the tests in the file. 8. If all looks good, then the source maintainer will merge your changes to the trunk, and create a tag. 9. If there are any question/comments that require a modifications to you patch, then go back to step 4 after you’ve made any changes and complete the process again. Let me know if you have any further questions. Feel free to add both patches into a single submission. You should be able to download all tools necessary outlined in the file. Let us know if you need assistance. Thanks, Ray From: Iuliu Rus [mailto:iuliur at google.com] Sent: Thursday, May 14, 2015 11:02 PM To: Robles, Raymond C Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers Can you please point me to the instructions on how to send the patch? As for the free q list issue, we enabled driver verifier and under stress it bugchecked in RtlpCheckListEntry. On Thu, May 14, 2015 at 10:52 PM, Robles, Raymond C > wrote: Hello, We always welcome companies to submit patches for candidate features. No other company has volunteered for concurrent channels at this time. We would gladly welcome your patch at your earliest convenience. The first release for 2015 is planned for ~August/September... would you like to volunteer for this patch prior to this release? As for a race condition synchronization fix for FreeQList, could you please describe the issue you were seeing and how you addressed it? Thanks, Ray From: Iuliu Rus [mailto:iuliur at google.com] Sent: Thursday, May 14, 2015 7:43 PM To: Robles, Raymond C Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers Hello, We are the google compute engine team and we already have Concurrent channels working. We're still figuring out how we can integrate between our internal repo and svn. Do you still need this feature? We also have a synchronization fix for a race that corrupted FreeQList. On Thu, May 7, 2015 at 3:46 PM, Robles, Raymond C > wrote: All, I just wanted to send out a quick update on the release plans for 2015. We’ve had two more companies volunteer to submit patches this year: Samsung (Suman) and HGST (Tom). Thank you to both companies for volunteering! Here is the updated release plan for 2015. Unfortunately, some of the patch submissions will be a little later than originally planned. Therefore, I would like to ask the question: is everyone ok if we push the first release out until end of August to allow for more patches to be submitted? You can response publicly or just to me. Other alternatives would include just having smaller releases at different cadences. I’m open to any ideas since there are still many requests for features that have claimed for patch submission. 2015 Release #1 (Q2/Q3 – 2015) Feature Description Submitter Date Concurrent Channels Start I/O Concurrent Channels allows StartIo to be called in parallel resulting in improved IOPS. Perf Opts Instead of learning cores, use perf opts. Shave off 2 seconds in init code… using Storport initialize perf opts. No need for source core interrupt steering code in driver. Samsung (Suman) End of June Win 8.1 Timers Storport Notification usage. Hot plug and IOCTLs, this does not work, for Win8.1… StorportRequestTimer() function needed. Samsung (Suman) End of July CFS Bit Monitoring CFS bit monitoring and handling. Look into adding additional handling code just to monitor CSTS.CFS. EOL - Read Only Read only support for devices at EOL. Detection at init, hot plug, or run-time. Samsung (Suman) End of August Namespace Mgmt Namespace management - creation and deletion of namespaces. Intel (Carolyn) End of June WHQL WHQL test suite run (any bug fixes). 2015 Release #2 (Q4 – 2015) Feature Description Submitter Date Multi-Path Multipath feature set from 1.1 spec (Multi-path I/O, Namespace Sharing, Reservations) HGST (Tom) Mid-November RTD3 Active/idle RTD3 Temp Thresholds Temperature thresholds (Get/Set Feature and AER trigger) Live FW Update Live firmware update Atomicity Atomicity Enhancements Win 10 Win 10 support (push to Q4 release) SNTL SNTL 1.5 doc updates HGST (Tom) End of August WHQL WHQL test suite run (any bug fixes) - for each release of OFA Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, April 09, 2015 5:29 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers All, As we enter Q2, I’m happy to announce that we a have a very good feature plan in place for both Q2 and Q4 releases in 2015 of the OFA driver. The list of requested features is included below for final review. I would like to formally ask for volunteers for patch submissions. As of today, there are no volunteers for any of the below patches. Intel would like to start with the volunteering… we will volunteer to provide the namespace management patch. 2015 Release #1 (Q2/Q3 – 2015) Feature Description Submitter Date Concurrent Channels Start I/O Concurrent Channels allows StartIo to be called in parallel resulting in improved IOPS. Perf Opts Instead of learning cores, use perf opts. Shave off 2 seconds in init code… using Storport initialize perf opts. No need for source core interrupt steering code in driver. Samsung (Suman) End of June Win 8.1 Timers Storport Notification usage. Hot plug and IOCTLs, this does not work, for Win8.1… StorportRequestTimer() function needed. Samsung (Suman) End of July CFS Bit Monitoring CFS bit monitoring and handling. Look into adding additional handling code just to monitor CSTS.CFS. EOL - Read Only Read only support for devices at EOL. Detection at init, hot plug, or run-time. Samsung (Suman) End of August Namespace Mgmt Namespace management - creation and deletion of namespaces. Intel (Carolyn) End of June WHQL WHQL test suite run (any bug fixes). 2015 Release #2 (Q4 – 2015) Feature Description Submitter Date Multi-Path Multipath feature set from 1.1 spec (Multi-path I/O, Namespace Sharing, Reservations) HGST (Tom) Mid-November RTD3 Active/idle RTD3 Temp Thresholds Temperature thresholds (Get/Set Feature and AER trigger) Live FW Update Live firmware update Atomicity Atomicity Enhancements Win 10 Win 10 support (push to Q4 release) SNTL SNTL 1.5 doc updates HGST (Tom) End of August WHQL WHQL test suite run (any bug fixes) - for each release of OFA Thanks, Ray Raymond C. Robles NSG ISE Host Storage Software Intel Corporation Office: 480-554-2600 Mobile: 480-399-0645 _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhijit.khande at gmail.com Tue Aug 4 09:47:34 2015 From: abhijit.khande at gmail.com (Abhijit Khande) Date: Tue, 4 Aug 2015 22:17:34 +0530 Subject: [nvmewin] Amy way to avoid loading inbox NVMe driver in WINPE In-Reply-To: <49158E750348AA499168FD41D88983606B6ECC33@fmsmsx117.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606B6EC3CF@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6ECC33@fmsmsx117.amr.corp.intel.com> Message-ID: Hi Ray, Yes its correct, but Microsoft (MS) NVMe driver is part of WinPE image (Inbox Driver) and it gets loaded automatically (class/sub class matches with MS NVMe inf). When we reach to driver load screen NVMe stack will be build up, as MS NVMe driver is already loaded. After this we can load our driver, but I want to check can we avoid the loading of the MS driver in first place? Thanks, Abhijit. On Tue, Aug 4, 2015 at 1:40 AM, Robles, Raymond C < raymond.c.robles at intel.com> wrote: > Hi Abhijit, > > > > Understood. And the process I outline below is exactly for that. To load a > third party driver during the OS install (via the “Load Drivers” option). > If you do not select this option during the OS install, the MS inbox driver > will claim the NVMe device. But if you load a driver during the OS install, > for example our OFA driver, then the OFA driver will claim the NVMe device. > > > > Thanks, > > Ray > > > > *From:* Abhijit Khande [mailto:abhijit.khande at gmail.com] > *Sent:* Monday, August 03, 2015 11:03 AM > *To:* Robles, Raymond C > *Cc:* nvmewin > *Subject:* Re: [nvmewin] Amy way to avoid loading inbox NVMe driver in > WINPE > > > > Hi Ray, > > > > Thanks for this data. But I want to avoid loading inbox NVMe driver > (StorNvme.sys) while OS installation in WINPE. > > Currently if we boot in WINPE during OS installation inbox NVMe gets > loaded and claim NVMe drives. This I want to avoid. > > > > I want to avoid loading inbox NVMe and load our open-source driver and > claim the NVMe devices > > > > Thanks, > > Abhijit > > > > > > > > On Mon, Aug 3, 2015 at 2:12 AM, Robles, Raymond C < > raymond.c.robles at intel.com> wrote: > > Hi Abhijit, > > > > Normally, when installing a Windows OS, there is an option to “load a > driver” just before kicking off the install (on the same page as the disk > partition layout). It is here that you could specify your desired driver, > vs. the MS inbox driver, to load and run during an install. This was often > referred to as the “F6 Install”. > > > > However, I’ve never tried this with WinPE. It may be worth investigating. > > > > Anyone else tried an “F6 Install” on WinPE? > > > > Thanks, > > Ray Robles > > > > *From:* nvmewin-bounces at lists.openfabrics.org [mailto: > nvmewin-bounces at lists.openfabrics.org] *On Behalf Of *Abhijit Khande > *Sent:* Thursday, July 30, 2015 6:57 PM > *To:* nvmewin > *Subject:* [nvmewin] Amy way to avoid loading inbox NVMe driver in WINPE > > > > Hi All, > > > > Is there any way to avoid loading inbox NVMe driver in WINPE during OS > installation? > > Currently after booting in WINPE the class/sub-class code matched and > inbox NVMme claims the device and PDOs gets exposesed to class driver. > > > > Any way to avoid this stack getting buildup using by inbox driver and load > our driver. > > > > Thanks, > > AK > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Thu Aug 6 12:34:31 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 6 Aug 2015 19:34:31 +0000 Subject: [nvmewin] patch submission In-Reply-To: <49158E750348AA499168FD41D88983606B6EB60E@fmsmsx117.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606B6EABB6@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6EB60E@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983606B6EF6D5@fmsmsx117.amr.corp.intel.com> Hi Cheng, I have not seen a response from you on my question below. In order for your patch to be accepted, you must respond to any and all questions/comments from the reviewing companies... as well as from the reflector list. If you do not respond within a timely fashion, your patch will not be considered for integration to the OFA driver. Please respond at your earliest convenience. Reviewing Companies, Any feedback, questions, or test results on the patch submission below? The deadline for review is August 12th. Thanks! Thanks, Ray Robles From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, July 31, 2015 11:37 AM To: nvmewin at lists.openfabrics.org; Cheng Peng Subject: Re: [nvmewin] patch submission Hi Cheng, I've reviewed your code and have some questions. It looks like NVMeWaitForCtrlRDY is added in init and reset path. Previously controller ready wait is performed in passive init path. I did not see any benefit of adding NVMeWaitForCtrlRDY in init path (I feel, old passive init path wait will be right approach to have minimal processor usage). Could you please provide an explanation on why you moved wait for controller ready to init path? Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, July 30, 2015 3:24 PM To: nvmewin at lists.openfabrics.org; Cheng Peng Subject: Re: [nvmewin] patch submission Reviewing Companies, Please provide any review comments and testing results before August 12th. We also have a patch from ULINK Technology after this patch. In the meantime, Cheng could you please provide the following information about your patch: - Reason fix was needed. - Files modified and what was modified in each file. - How you unit tested your fix. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Cheng Peng Sent: Monday, July 06, 2015 10:32 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] patch submission fix: Wait for device ready when enable adapter It had been tested on Windows 2008 R2\Windows 2012 x64 platform Please review it, and if you think it OK, please merge it to SVN trunk, thank you Btw, the password of ZIP is ofa_nvme -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Thu Aug 6 12:42:31 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 6 Aug 2015 19:42:31 +0000 Subject: [nvmewin] Amy way to avoid loading inbox NVMe driver in WINPE In-Reply-To: References: <49158E750348AA499168FD41D88983606B6EC3CF@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6ECC33@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983606B6EF72C@fmsmsx117.amr.corp.intel.com> Hi Abhijit, I believe this MS technet article addresses your concern: https://technet.microsoft.com/en-us/library/hh824989.aspx Thanks, Ray From: Abhijit Khande [mailto:abhijit.khande at gmail.com] Sent: Tuesday, August 04, 2015 9:48 AM To: Robles, Raymond C Cc: nvmewin Subject: Re: [nvmewin] Amy way to avoid loading inbox NVMe driver in WINPE Hi Ray, Yes its correct, but Microsoft (MS) NVMe driver is part of WinPE image (Inbox Driver) and it gets loaded automatically (class/sub class matches with MS NVMe inf). When we reach to driver load screen NVMe stack will be build up, as MS NVMe driver is already loaded. After this we can load our driver, but I want to check can we avoid the loading of the MS driver in first place? Thanks, Abhijit. On Tue, Aug 4, 2015 at 1:40 AM, Robles, Raymond C > wrote: Hi Abhijit, Understood. And the process I outline below is exactly for that. To load a third party driver during the OS install (via the “Load Drivers” option). If you do not select this option during the OS install, the MS inbox driver will claim the NVMe device. But if you load a driver during the OS install, for example our OFA driver, then the OFA driver will claim the NVMe device. Thanks, Ray From: Abhijit Khande [mailto:abhijit.khande at gmail.com] Sent: Monday, August 03, 2015 11:03 AM To: Robles, Raymond C Cc: nvmewin Subject: Re: [nvmewin] Amy way to avoid loading inbox NVMe driver in WINPE Hi Ray, Thanks for this data. But I want to avoid loading inbox NVMe driver (StorNvme.sys) while OS installation in WINPE. Currently if we boot in WINPE during OS installation inbox NVMe gets loaded and claim NVMe drives. This I want to avoid. I want to avoid loading inbox NVMe and load our open-source driver and claim the NVMe devices Thanks, Abhijit On Mon, Aug 3, 2015 at 2:12 AM, Robles, Raymond C > wrote: Hi Abhijit, Normally, when installing a Windows OS, there is an option to “load a driver” just before kicking off the install (on the same page as the disk partition layout). It is here that you could specify your desired driver, vs. the MS inbox driver, to load and run during an install. This was often referred to as the “F6 Install”. However, I’ve never tried this with WinPE. It may be worth investigating. Anyone else tried an “F6 Install” on WinPE? Thanks, Ray Robles From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Abhijit Khande Sent: Thursday, July 30, 2015 6:57 PM To: nvmewin Subject: [nvmewin] Amy way to avoid loading inbox NVMe driver in WINPE Hi All, Is there any way to avoid loading inbox NVMe driver in WINPE during OS installation? Currently after booting in WINPE the class/sub-class code matched and inbox NVMme claims the device and PDOs gets exposesed to class driver. Any way to avoid this stack getting buildup using by inbox driver and load our driver. Thanks, AK -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheng.peng at memblaze.com Sat Aug 8 08:48:08 2015 From: cheng.peng at memblaze.com (Cheng Peng) Date: Sat, 8 Aug 2015 15:48:08 +0000 Subject: [nvmewin] =?gb2312?b?tPC4tDogcGF0Y2ggc3VibWlzc2lvbg==?= In-Reply-To: <49158E750348AA499168FD41D88983606B6EF6D5@fmsmsx117.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606B6EABB6@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6EB60E@fmsmsx117.amr.corp.intel.com>, <49158E750348AA499168FD41D88983606B6EF6D5@fmsmsx117.amr.corp.intel.com> Message-ID: Hi Ray Other colleagues take over my jobs, I have forwarded the email to them. Thanks ________________________________ 发件人: Robles, Raymond C 发送时间: 2015年8月7日 3:34 收件人: nvmewin at lists.openfabrics.org; Cheng Peng 主题: RE: patch submission Hi Cheng, I have not seen a response from you on my question below. In order for your patch to be accepted, you must respond to any and all questions/comments from the reviewing companies… as well as from the reflector list. If you do not respond within a timely fashion, your patch will not be considered for integration to the OFA driver. Please respond at your earliest convenience. Reviewing Companies, Any feedback, questions, or test results on the patch submission below? The deadline for review is August 12th. Thanks! Thanks, Ray Robles From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, July 31, 2015 11:37 AM To: nvmewin at lists.openfabrics.org; Cheng Peng Subject: Re: [nvmewin] patch submission Hi Cheng, I’ve reviewed your code and have some questions. It looks like NVMeWaitForCtrlRDY is added in init and reset path. Previously controller ready wait is performed in passive init path. I did not see any benefit of adding NVMeWaitForCtrlRDY in init path (I feel, old passive init path wait will be right approach to have minimal processor usage). Could you please provide an explanation on why you moved wait for controller ready to init path? Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, July 30, 2015 3:24 PM To: nvmewin at lists.openfabrics.org; Cheng Peng Subject: Re: [nvmewin] patch submission Reviewing Companies, Please provide any review comments and testing results before August 12th. We also have a patch from ULINK Technology after this patch. In the meantime, Cheng could you please provide the following information about your patch: - Reason fix was needed. - Files modified and what was modified in each file. - How you unit tested your fix. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Cheng Peng Sent: Monday, July 06, 2015 10:32 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] patch submission fix: Wait for device ready when enable adapter It had been tested on Windows 2008 R2\Windows 2012 x64 platform Please review it, and if you think it OK, please merge it to SVN trunk, thank you Btw, the password of ZIP is ofa_nvme -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Wed Aug 12 18:09:05 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 13 Aug 2015 01:09:05 +0000 Subject: [nvmewin] patch submission In-Reply-To: References: <49158E750348AA499168FD41D88983606B6EABB6@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6EB60E@fmsmsx117.amr.corp.intel.com>, <49158E750348AA499168FD41D88983606B6EF6D5@fmsmsx117.amr.corp.intel.com> <008401d0d1f0$f116e4b0$d344ae10$@memblaze.com> Message-ID: <49158E750348AA499168FD41D88983606B6F5298@fmsmsx117.amr.corp.intel.com> Hi, Thanks for the response. My biggest concern here is how this change will work on currently released NVMe products in the market (i.e. Intel, Samsung, etc.). Do you have a means of unit testing with other NVMe devices? This fix seems very specific to your “proprietary” NVMe device. No other IHV for NVMe devices is using a similar power methodology. Based on this alone, I’m inclined to not include it in the OFA baseline. However, please keep in mind that the OFA driver is a “reference” driver, and not a production driver (i.e. Linux NVMe driver). Therefore, your company can take this driver and modify it as you need and release under the FreeBSD license with your H/W. Many IHV vendors do this. In the end, this patch does not “need” to be in the OFA baseline… as it only resolves an issue on your company’s NVMe controller. For now, I think the next steps are: - Get feedback from rest of OFA NVMeWin reviewing companies on such a fix - Test your patch on other 3rd party NVMe drives Thanks, Ray From: Yizhong Zhang [mailto:yizhong.zhang at memblaze.com] Sent: Monday, August 10, 2015 1:21 AM To: Wenbo Wang; Robles, Raymond C Subject: 答复: patch submission Hi Ray, Thanks for your information and sorry for delayed response. My name is Yizhong and I will track this effort. I am a rookie in NVMe Windows driver, so please correct me if there is anything wrong in my statement. Cheng already left company so I can only talked with other guys for some internals. Here is the problem background: we have a special NVMe test setup. We have a self-made NVMe card slot, which separates PCIe signals from power. In such way, the NVMe card gets power with a separated power module, instead of power from PCIe slot. We found a bug in such setup. If we unplug the power cable and plug the power cable again, we observed Windows hang (no any response). So we add the patch later, and it proves the bug is fixed. I looked into code and found the passive wait in NVMe reset path (NVMeInitialize and NVMeResetAdapter), but I didn’t see NVMeWaitForCtrlRDY been called in NVMeEnableAdapter. So this fix make sense in my opinion. The side effect is driver may spends ~1s (estimated) to wait for controller ready after power recover. We only test the fix with the bug reproduce steps. There is no unit test here. As I mentioned above, it should be safe for all other functionalities except extra delay during NVMe initialization stage. Could you please let us know your further advice? Thanks in advance. Thanks, -yz 发件人: Wenbo Wang 发送时间: Saturday, August 8, 2015 11:43 PM 收件人: raymond.c.robles at intel.com 抄送: Yizhong Zhang 主题: FW: patch submission 重要性: 高 Hi Ray, Thanks for your email. Due to some changes, Cheng will not work on this OFA driver any more. I and Yizhong will be doing that. We need to take some time to understand all the history and after that we will response ASAP. Sorry for the inconvenience. Thanks, -Wenbo ________________________________ 发件人: Robles, Raymond C > 发送时间: 2015年8月7日 3:34 收件人: nvmewin at lists.openfabrics.org; Cheng Peng 主题: RE: patch submission Hi Cheng, I have not seen a response from you on my question below. In order for your patch to be accepted, you must respond to any and all questions/comments from the reviewing companies… as well as from the reflector list. If you do not respond within a timely fashion, your patch will not be considered for integration to the OFA driver. Please respond at your earliest convenience. Reviewing Companies, Any feedback, questions, or test results on the patch submission below? The deadline for review is August 12th. Thanks! Thanks, Ray Robles From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, July 31, 2015 11:37 AM To: nvmewin at lists.openfabrics.org; Cheng Peng Subject: Re: [nvmewin] patch submission Hi Cheng, I’ve reviewed your code and have some questions. It looks like NVMeWaitForCtrlRDY is added in init and reset path. Previously controller ready wait is performed in passive init path. I did not see any benefit of adding NVMeWaitForCtrlRDY in init path (I feel, old passive init path wait will be right approach to have minimal processor usage). Could you please provide an explanation on why you moved wait for controller ready to init path? Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, July 30, 2015 3:24 PM To: nvmewin at lists.openfabrics.org; Cheng Peng Subject: Re: [nvmewin] patch submission Reviewing Companies, Please provide any review comments and testing results before August 12th. We also have a patch from ULINK Technology after this patch. In the meantime, Cheng could you please provide the following information about your patch: - Reason fix was needed. - Files modified and what was modified in each file. - How you unit tested your fix. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Cheng Peng Sent: Monday, July 06, 2015 10:32 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] patch submission fix: Wait for device ready when enable adapter It had been tested on Windows 2008 R2\Windows 2012 x64 platform Please review it, and if you think it OK, please merge it to SVN trunk, thank you Btw, the password of ZIP is ofa_nvme -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.freeman at hgst.com Thu Aug 13 07:09:36 2015 From: thomas.freeman at hgst.com (Thomas Freeman) Date: Thu, 13 Aug 2015 14:09:36 +0000 Subject: [nvmewin] patch submission In-Reply-To: <49158E750348AA499168FD41D88983606B6F5298@fmsmsx117.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606B6EABB6@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6EB60E@fmsmsx117.amr.corp.intel.com>, <49158E750348AA499168FD41D88983606B6EF6D5@fmsmsx117.amr.corp.intel.com> <008401d0d1f0$f116e4b0$d344ae10$@memblaze.com> <49158E750348AA499168FD41D88983606B6F5298@fmsmsx117.amr.corp.intel.com> Message-ID: Yizhong, Thank you for the information. I’ve also been waiting for the explanation on why this is necessary. As Ray said, it seems like this only addresses a problem with your non-standard setup. So, unless there is evidence that this fixes a general problem, HGST declines to accept this fix. Regards, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Wednesday, August 12, 2015 8:09 PM To: Yizhong Zhang ; Wenbo Wang Cc: nvmewin Subject: Re: [nvmewin] patch submission Hi, Thanks for the response. My biggest concern here is how this change will work on currently released NVMe products in the market (i.e. Intel, Samsung, etc.). Do you have a means of unit testing with other NVMe devices? This fix seems very specific to your “proprietary” NVMe device. No other IHV for NVMe devices is using a similar power methodology. Based on this alone, I’m inclined to not include it in the OFA baseline. However, please keep in mind that the OFA driver is a “reference” driver, and not a production driver (i.e. Linux NVMe driver). Therefore, your company can take this driver and modify it as you need and release under the FreeBSD license with your H/W. Many IHV vendors do this. In the end, this patch does not “need” to be in the OFA baseline… as it only resolves an issue on your company’s NVMe controller. For now, I think the next steps are: - Get feedback from rest of OFA NVMeWin reviewing companies on such a fix - Test your patch on other 3rd party NVMe drives Thanks, Ray From: Yizhong Zhang [mailto:yizhong.zhang at memblaze.com] Sent: Monday, August 10, 2015 1:21 AM To: Wenbo Wang; Robles, Raymond C Subject: 答复: patch submission Hi Ray, Thanks for your information and sorry for delayed response. My name is Yizhong and I will track this effort. I am a rookie in NVMe Windows driver, so please correct me if there is anything wrong in my statement. Cheng already left company so I can only talked with other guys for some internals. Here is the problem background: we have a special NVMe test setup. We have a self-made NVMe card slot, which separates PCIe signals from power. In such way, the NVMe card gets power with a separated power module, instead of power from PCIe slot. We found a bug in such setup. If we unplug the power cable and plug the power cable again, we observed Windows hang (no any response). So we add the patch later, and it proves the bug is fixed. I looked into code and found the passive wait in NVMe reset path (NVMeInitialize and NVMeResetAdapter), but I didn’t see NVMeWaitForCtrlRDY been called in NVMeEnableAdapter. So this fix make sense in my opinion. The side effect is driver may spends ~1s (estimated) to wait for controller ready after power recover. We only test the fix with the bug reproduce steps. There is no unit test here. As I mentioned above, it should be safe for all other functionalities except extra delay during NVMe initialization stage. Could you please let us know your further advice? Thanks in advance. Thanks, -yz 发件人: Wenbo Wang 发送时间: Saturday, August 8, 2015 11:43 PM 收件人: raymond.c.robles at intel.com 抄送: Yizhong Zhang 主题: FW: patch submission 重要性: 高 Hi Ray, Thanks for your email. Due to some changes, Cheng will not work on this OFA driver any more. I and Yizhong will be doing that. We need to take some time to understand all the history and after that we will response ASAP. Sorry for the inconvenience. Thanks, -Wenbo ________________________________ 发件人: Robles, Raymond C > 发送时间: 2015年8月7日 3:34 收件人: nvmewin at lists.openfabrics.org; Cheng Peng 主题: RE: patch submission Hi Cheng, I have not seen a response from you on my question below. In order for your patch to be accepted, you must respond to any and all questions/comments from the reviewing companies… as well as from the reflector list. If you do not respond within a timely fashion, your patch will not be considered for integration to the OFA driver. Please respond at your earliest convenience. Reviewing Companies, Any feedback, questions, or test results on the patch submission below? The deadline for review is August 12th. Thanks! Thanks, Ray Robles From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, July 31, 2015 11:37 AM To: nvmewin at lists.openfabrics.org; Cheng Peng Subject: Re: [nvmewin] patch submission Hi Cheng, I’ve reviewed your code and have some questions. It looks like NVMeWaitForCtrlRDY is added in init and reset path. Previously controller ready wait is performed in passive init path. I did not see any benefit of adding NVMeWaitForCtrlRDY in init path (I feel, old passive init path wait will be right approach to have minimal processor usage). Could you please provide an explanation on why you moved wait for controller ready to init path? Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, July 30, 2015 3:24 PM To: nvmewin at lists.openfabrics.org; Cheng Peng Subject: Re: [nvmewin] patch submission Reviewing Companies, Please provide any review comments and testing results before August 12th. We also have a patch from ULINK Technology after this patch. In the meantime, Cheng could you please provide the following information about your patch: - Reason fix was needed. - Files modified and what was modified in each file. - How you unit tested your fix. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Cheng Peng Sent: Monday, July 06, 2015 10:32 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] patch submission fix: Wait for device ready when enable adapter It had been tested on Windows 2008 R2\Windows 2012 x64 platform Please review it, and if you think it OK, please merge it to SVN trunk, thank you Btw, the password of ZIP is ofa_nvme HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: From yizhong.zhang at memblaze.com Tue Aug 18 18:39:34 2015 From: yizhong.zhang at memblaze.com (Yizhong Zhang) Date: Wed, 19 Aug 2015 01:39:34 +0000 Subject: [nvmewin] =?utf-8?b?562U5aSNOiBwYXRjaCBzdWJtaXNzaW9u?= In-Reply-To: References: <49158E750348AA499168FD41D88983606B6EABB6@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6EB60E@fmsmsx117.amr.corp.intel.com>, <49158E750348AA499168FD41D88983606B6EF6D5@fmsmsx117.amr.corp.intel.com> <008401d0d1f0$f116e4b0$d344ae10$@memblaze.com> <49158E750348AA499168FD41D88983606B6F5298@fmsmsx117.amr.corp.intel.com> Message-ID: Hi Tom and Robles, Thanks for your feedback. We will only keep this patch in our private branch, as you said, this is a company specific fix for special HW setup. Thanks, -yz 发件人: Thomas Freeman [mailto:thomas.freeman at hgst.com] 发送时间: Thursday, August 13, 2015 10:10 PM 收件人: Robles, Raymond C; Yizhong Zhang; Wenbo Wang 抄送: nvmewin 主题: RE: patch submission Yizhong, Thank you for the information. I’ve also been waiting for the explanation on why this is necessary. As Ray said, it seems like this only addresses a problem with your non-standard setup. So, unless there is evidence that this fixes a general problem, HGST declines to accept this fix. Regards, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Wednesday, August 12, 2015 8:09 PM To: Yizhong Zhang >; Wenbo Wang > Cc: nvmewin > Subject: Re: [nvmewin] patch submission Hi, Thanks for the response. My biggest concern here is how this change will work on currently released NVMe products in the market (i.e. Intel, Samsung, etc.). Do you have a means of unit testing with other NVMe devices? This fix seems very specific to your “proprietary” NVMe device. No other IHV for NVMe devices is using a similar power methodology. Based on this alone, I’m inclined to not include it in the OFA baseline. However, please keep in mind that the OFA driver is a “reference” driver, and not a production driver (i.e. Linux NVMe driver). Therefore, your company can take this driver and modify it as you need and release under the FreeBSD license with your H/W. Many IHV vendors do this. In the end, this patch does not “need” to be in the OFA baseline… as it only resolves an issue on your company’s NVMe controller. For now, I think the next steps are: - Get feedback from rest of OFA NVMeWin reviewing companies on such a fix - Test your patch on other 3rd party NVMe drives Thanks, Ray From: Yizhong Zhang [mailto:yizhong.zhang at memblaze.com] Sent: Monday, August 10, 2015 1:21 AM To: Wenbo Wang; Robles, Raymond C Subject: 答复: patch submission Hi Ray, Thanks for your information and sorry for delayed response. My name is Yizhong and I will track this effort. I am a rookie in NVMe Windows driver, so please correct me if there is anything wrong in my statement. Cheng already left company so I can only talked with other guys for some internals. Here is the problem background: we have a special NVMe test setup. We have a self-made NVMe card slot, which separates PCIe signals from power. In such way, the NVMe card gets power with a separated power module, instead of power from PCIe slot. We found a bug in such setup. If we unplug the power cable and plug the power cable again, we observed Windows hang (no any response). So we add the patch later, and it proves the bug is fixed. I looked into code and found the passive wait in NVMe reset path (NVMeInitialize and NVMeResetAdapter), but I didn’t see NVMeWaitForCtrlRDY been called in NVMeEnableAdapter. So this fix make sense in my opinion. The side effect is driver may spends ~1s (estimated) to wait for controller ready after power recover. We only test the fix with the bug reproduce steps. There is no unit test here. As I mentioned above, it should be safe for all other functionalities except extra delay during NVMe initialization stage. Could you please let us know your further advice? Thanks in advance. Thanks, -yz 发件人: Wenbo Wang 发送时间: Saturday, August 8, 2015 11:43 PM 收件人: raymond.c.robles at intel.com 抄送: Yizhong Zhang 主题: FW: patch submission 重要性: 高 Hi Ray, Thanks for your email. Due to some changes, Cheng will not work on this OFA driver any more. I and Yizhong will be doing that. We need to take some time to understand all the history and after that we will response ASAP. Sorry for the inconvenience. Thanks, -Wenbo ________________________________ 发件人: Robles, Raymond C > 发送时间: 2015年8月7日 3:34 收件人: nvmewin at lists.openfabrics.org; Cheng Peng 主题: RE: patch submission Hi Cheng, I have not seen a response from you on my question below. In order for your patch to be accepted, you must respond to any and all questions/comments from the reviewing companies… as well as from the reflector list. If you do not respond within a timely fashion, your patch will not be considered for integration to the OFA driver. Please respond at your earliest convenience. Reviewing Companies, Any feedback, questions, or test results on the patch submission below? The deadline for review is August 12th. Thanks! Thanks, Ray Robles From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, July 31, 2015 11:37 AM To: nvmewin at lists.openfabrics.org; Cheng Peng Subject: Re: [nvmewin] patch submission Hi Cheng, I’ve reviewed your code and have some questions. It looks like NVMeWaitForCtrlRDY is added in init and reset path. Previously controller ready wait is performed in passive init path. I did not see any benefit of adding NVMeWaitForCtrlRDY in init path (I feel, old passive init path wait will be right approach to have minimal processor usage). Could you please provide an explanation on why you moved wait for controller ready to init path? Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, July 30, 2015 3:24 PM To: nvmewin at lists.openfabrics.org; Cheng Peng Subject: Re: [nvmewin] patch submission Reviewing Companies, Please provide any review comments and testing results before August 12th. We also have a patch from ULINK Technology after this patch. In the meantime, Cheng could you please provide the following information about your patch: - Reason fix was needed. - Files modified and what was modified in each file. - How you unit tested your fix. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Cheng Peng Sent: Monday, July 06, 2015 10:32 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] patch submission fix: Wait for device ready when enable adapter It had been tested on Windows 2008 R2\Windows 2012 x64 platform Please review it, and if you think it OK, please merge it to SVN trunk, thank you Btw, the password of ZIP is ofa_nvme HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: From raymond.c.robles at intel.com Mon Aug 24 14:14:14 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Mon, 24 Aug 2015 21:14:14 +0000 Subject: [nvmewin] Zero Length for Security Receive and Security Send command In-Reply-To: <49158E750348AA499168FD41D88983606B6EABCD@fmsmsx117.amr.corp.intel.com> References: <00b101d0c675$3de1b5e0$b9a521a0$@wang@ulinktech.com> <49158E750348AA499168FD41D88983606B6EABCD@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983606B71B10B@fmsmsx117.amr.corp.intel.com> Yun, Your patch is now in line to be reviewed. Reviewing Companies, Please review Yun's patch for zero length Secure Send/Receive commands and provide feedback on or before September 4th. Thanks! Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, July 30, 2015 3:25 PM To: Yun Wang Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Thank you for your patch submission. There is one patch in front of yours. Once that patch has been reviewed and approved, your patch will be reviewed next. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Yun Wang Sent: Friday, July 24, 2015 6:00 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Zero Length for Security Receive and Security Send command Hi: Current OFA driver doesn't allow zero length for Security Receive and Security Send command. Per NVMe spec., "Security Receive command with the Security Protocol field set to 00h shall return information about the security protocols supported by the controller. This command is used in the security discovery process and is not associated with a Security Send command. Refer to SPC-4 for the details of Security Protocol 00h and the SP Specific field". Per SPC-4 spec., "a transfer length of zero specifies that no data transfer shall take place. This condition shall not be considered an error", zero length of data transfer for Security Protocol 00h should be allowed. On the other hand, for some practices with other Security Protocol, zero length will be needed, too. This patch is to allow zero length of data transfer for Security Receive and Security Send command. It has been tested over Win8.1 x64 platform and works as expected. Please review and help merge it into the trunk. The password for the attachment is nvme_sec. Best Regards, Yun Wang ULINK Technology, Inc. Website: www.ulinktech.com Office: +1(408) 446-8455 Email: yun.wang at ulinktech.com [ulink logo 2] DISCLAIMER: The information contained in this message is confidential and may be legally privileged. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1628 bytes Desc: image001.jpg URL: From raymond.c.robles at intel.com Mon Aug 24 14:15:03 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Mon, 24 Aug 2015 21:15:03 +0000 Subject: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers References: <49158E750348AA499168FD41D88983606B63477F@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B656163@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6697AD@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B669C18@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6EA959@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983606B71B12F@fmsmsx117.amr.corp.intel.com> Hi Iuliu, Your patch is now next in queue to be reviewed. Once the patch from ULINK Technology has been reviewed, your patch will be next. Thanks for your patience. Thanks Ray From: Robles, Raymond C Sent: Monday, August 03, 2015 4:32 PM To: 'Iuliu Rus' Cc: nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers Thanks Iuliu. Your patch is third in line right now (two patches ahead of you). I’ll go ahead and schedule an OFA meeting to discuss a few times, including migrating to github. Thanks, Ray From: Iuliu Rus [mailto:iuliur at google.com] Sent: Monday, August 03, 2015 1:40 PM To: Robles, Raymond C Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers Thank you, I have sent the first patch containing the fuzz test fixes. We really hope you will consider patch process changes. Sending zips across is error prone as somebody will have to manually merge changes. Besides the time spent, we run the risk of regressing some earlier change and negate half of the benefits of a source control. Also, dealing with code reviews is harder than it needs to be (as github has them associated with the precise code line and so on). On Thu, Jul 30, 2015 at 2:25 PM, Robles, Raymond C > wrote: Hi Iuliu, I thought I responded to this email, but in case I didn’t…. For now, I would suggest separating the patch into smaller patches. The use of SVN is not dictated by the NVMeWin group, but rather the OFA (Open Fabrics Alliance) website, and its administrators. If there were/are enough requests to migrate to github, I could call a meeting to discuss moving to another host website. But the process would not be quick, especially since we are starting to get patches for the end of year release. Thanks, Ray From: Iuliu Rus [mailto:iuliur at google.com] Sent: Thursday, June 25, 2015 12:06 PM To: Robles, Raymond C Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers Raymond, we are running the windows HCK fuzz test on the driver and it exposes several crashes. Also, on SCSIOP_START_STOP_UNIT it looks like SntiTransitionPowerState builds an io which it never submits, causing Windows to eventually reset the adapter. Given that some of these fuzz crashes are potential security issues, we are getting ready to submit the patch next week. However it is rather big and the current patch submission process doesn't work that well. We would like to break it into separate changes, but with zipped thrunk this is not possible. Is there any way to switch this over to github so we can use pull requests instead? Or, should we do separate submissions for now? On Tue, Jun 2, 2015 at 3:35 PM, Iuliu Rus > wrote: Raymond, given this, project we are going to wait for QEMU to accept the virtualization extensions first (http://git.infradead.org/users/kbusch/qemu-nvme.git/commit/162ec6479447abbd76308f831f36703aa3acc485), then submit our payload which includes what we previously discussed and the windows implementation for the nvme doorbell extensions. On Fri, May 15, 2015 at 11:38 AM, Robles, Raymond C > wrote: Hi Iuliu, The process for submitting a patch is quite simple (by design). The steps are as follows: 1. Download the current latest trunk source via an SVN client (i.e. TortoiseSVN). I assume you’ve already done this. 2. In the Releases folder, under a specific release, there are readme.txt files that explain the build environment needed. Insure you can compile the trunk with the recommended tool/build set. 3. Port your changes over to the trunk. 4. Unit test your changes on the trunk source. 5. Run the required testing outlined in the file attached in this email and insure all tests are passing. 6. Send an email with the trunk source zipped (with your ported changes) to this email distribution list. 7. The three reviewing companies will review your changes and also run the tests in the file. 8. If all looks good, then the source maintainer will merge your changes to the trunk, and create a tag. 9. If there are any question/comments that require a modifications to you patch, then go back to step 4 after you’ve made any changes and complete the process again. Let me know if you have any further questions. Feel free to add both patches into a single submission. You should be able to download all tools necessary outlined in the file. Let us know if you need assistance. Thanks, Ray From: Iuliu Rus [mailto:iuliur at google.com] Sent: Thursday, May 14, 2015 11:02 PM To: Robles, Raymond C Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers Can you please point me to the instructions on how to send the patch? As for the free q list issue, we enabled driver verifier and under stress it bugchecked in RtlpCheckListEntry. On Thu, May 14, 2015 at 10:52 PM, Robles, Raymond C > wrote: Hello, We always welcome companies to submit patches for candidate features. No other company has volunteered for concurrent channels at this time. We would gladly welcome your patch at your earliest convenience. The first release for 2015 is planned for ~August/September... would you like to volunteer for this patch prior to this release? As for a race condition synchronization fix for FreeQList, could you please describe the issue you were seeing and how you addressed it? Thanks, Ray From: Iuliu Rus [mailto:iuliur at google.com] Sent: Thursday, May 14, 2015 7:43 PM To: Robles, Raymond C Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers Hello, We are the google compute engine team and we already have Concurrent channels working. We're still figuring out how we can integrate between our internal repo and svn. Do you still need this feature? We also have a synchronization fix for a race that corrupted FreeQList. On Thu, May 7, 2015 at 3:46 PM, Robles, Raymond C > wrote: All, I just wanted to send out a quick update on the release plans for 2015. We’ve had two more companies volunteer to submit patches this year: Samsung (Suman) and HGST (Tom). Thank you to both companies for volunteering! Here is the updated release plan for 2015. Unfortunately, some of the patch submissions will be a little later than originally planned. Therefore, I would like to ask the question: is everyone ok if we push the first release out until end of August to allow for more patches to be submitted? You can response publicly or just to me. Other alternatives would include just having smaller releases at different cadences. I’m open to any ideas since there are still many requests for features that have claimed for patch submission. 2015 Release #1 (Q2/Q3 – 2015) Feature Description Submitter Date Concurrent Channels Start I/O Concurrent Channels allows StartIo to be called in parallel resulting in improved IOPS. Perf Opts Instead of learning cores, use perf opts. Shave off 2 seconds in init code… using Storport initialize perf opts. No need for source core interrupt steering code in driver. Samsung (Suman) End of June Win 8.1 Timers Storport Notification usage. Hot plug and IOCTLs, this does not work, for Win8.1… StorportRequestTimer() function needed. Samsung (Suman) End of July CFS Bit Monitoring CFS bit monitoring and handling. Look into adding additional handling code just to monitor CSTS.CFS. EOL - Read Only Read only support for devices at EOL. Detection at init, hot plug, or run-time. Samsung (Suman) End of August Namespace Mgmt Namespace management - creation and deletion of namespaces. Intel (Carolyn) End of June WHQL WHQL test suite run (any bug fixes). 2015 Release #2 (Q4 – 2015) Feature Description Submitter Date Multi-Path Multipath feature set from 1.1 spec (Multi-path I/O, Namespace Sharing, Reservations) HGST (Tom) Mid-November RTD3 Active/idle RTD3 Temp Thresholds Temperature thresholds (Get/Set Feature and AER trigger) Live FW Update Live firmware update Atomicity Atomicity Enhancements Win 10 Win 10 support (push to Q4 release) SNTL SNTL 1.5 doc updates HGST (Tom) End of August WHQL WHQL test suite run (any bug fixes) - for each release of OFA Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, April 09, 2015 5:29 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers All, As we enter Q2, I’m happy to announce that we a have a very good feature plan in place for both Q2 and Q4 releases in 2015 of the OFA driver. The list of requested features is included below for final review. I would like to formally ask for volunteers for patch submissions. As of today, there are no volunteers for any of the below patches. Intel would like to start with the volunteering… we will volunteer to provide the namespace management patch. 2015 Release #1 (Q2/Q3 – 2015) Feature Description Submitter Date Concurrent Channels Start I/O Concurrent Channels allows StartIo to be called in parallel resulting in improved IOPS. Perf Opts Instead of learning cores, use perf opts. Shave off 2 seconds in init code… using Storport initialize perf opts. No need for source core interrupt steering code in driver. Samsung (Suman) End of June Win 8.1 Timers Storport Notification usage. Hot plug and IOCTLs, this does not work, for Win8.1… StorportRequestTimer() function needed. Samsung (Suman) End of July CFS Bit Monitoring CFS bit monitoring and handling. Look into adding additional handling code just to monitor CSTS.CFS. EOL - Read Only Read only support for devices at EOL. Detection at init, hot plug, or run-time. Samsung (Suman) End of August Namespace Mgmt Namespace management - creation and deletion of namespaces. Intel (Carolyn) End of June WHQL WHQL test suite run (any bug fixes). 2015 Release #2 (Q4 – 2015) Feature Description Submitter Date Multi-Path Multipath feature set from 1.1 spec (Multi-path I/O, Namespace Sharing, Reservations) HGST (Tom) Mid-November RTD3 Active/idle RTD3 Temp Thresholds Temperature thresholds (Get/Set Feature and AER trigger) Live FW Update Live firmware update Atomicity Atomicity Enhancements Win 10 Win 10 support (push to Q4 release) SNTL SNTL 1.5 doc updates HGST (Tom) End of August WHQL WHQL test suite run (any bug fixes) - for each release of OFA Thanks, Ray Raymond C. Robles NSG ISE Host Storage Software Intel Corporation Office: 480-554-2600 Mobile: 480-399-0645 _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Thu Aug 27 11:03:41 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 27 Aug 2015 18:03:41 +0000 Subject: [nvmewin] Zero Length for Security Receive and Security Send command In-Reply-To: <49158E750348AA499168FD41D88983606B71B10B@fmsmsx117.amr.corp.intel.com> References: <00b101d0c675$3de1b5e0$b9a521a0$@wang@ulinktech.com> <49158E750348AA499168FD41D88983606B6EABCD@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B71B10B@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983606B71D689@fmsmsx117.amr.corp.intel.com> Hi Yun, Intel has reviewed and tested your patch and approves your patch. Just need to hear back from the other reviewing companies. Reviewing Company Status Samsung Review In Progress PMC-Sierra Review In Progress HGST Review In Progress Intel Approved Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, August 24, 2015 2:14 PM To: Yun Wang; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Yun, Your patch is now in line to be reviewed. Reviewing Companies, Please review Yun's patch for zero length Secure Send/Receive commands and provide feedback on or before September 4th. Thanks! Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, July 30, 2015 3:25 PM To: Yun Wang Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Thank you for your patch submission. There is one patch in front of yours. Once that patch has been reviewed and approved, your patch will be reviewed next. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Yun Wang Sent: Friday, July 24, 2015 6:00 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Zero Length for Security Receive and Security Send command Hi: Current OFA driver doesn't allow zero length for Security Receive and Security Send command. Per NVMe spec., "Security Receive command with the Security Protocol field set to 00h shall return information about the security protocols supported by the controller. This command is used in the security discovery process and is not associated with a Security Send command. Refer to SPC-4 for the details of Security Protocol 00h and the SP Specific field". Per SPC-4 spec., "a transfer length of zero specifies that no data transfer shall take place. This condition shall not be considered an error", zero length of data transfer for Security Protocol 00h should be allowed. On the other hand, for some practices with other Security Protocol, zero length will be needed, too. This patch is to allow zero length of data transfer for Security Receive and Security Send command. It has been tested over Win8.1 x64 platform and works as expected. Please review and help merge it into the trunk. The password for the attachment is nvme_sec. Best Regards, Yun Wang ULINK Technology, Inc. Website: www.ulinktech.com Office: +1(408) 446-8455 Email: yun.wang at ulinktech.com [ulink logo 2] DISCLAIMER: The information contained in this message is confidential and may be legally privileged. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1628 bytes Desc: image001.jpg URL: From thomas.freeman at hgst.com Mon Aug 31 11:41:08 2015 From: thomas.freeman at hgst.com (Thomas Freeman) Date: Mon, 31 Aug 2015 18:41:08 +0000 Subject: [nvmewin] Zero Length for Security Receive and Security Send command In-Reply-To: <49158E750348AA499168FD41D88983606B71D689@fmsmsx117.amr.corp.intel.com> References: <00b101d0c675$3de1b5e0$b9a521a0$@wang@ulinktech.com> <49158E750348AA499168FD41D88983606B6EABCD@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B71B10B@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B71D689@fmsmsx117.amr.corp.intel.com> Message-ID: Hi Yun, HGST approves your patch. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, August 27, 2015 1:04 PM To: Yun Wang ; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Intel has reviewed and tested your patch and approves your patch. Just need to hear back from the other reviewing companies. Reviewing Company Status Samsung Review In Progress PMC-Sierra Review In Progress HGST Review In Progress Intel Approved Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, August 24, 2015 2:14 PM To: Yun Wang; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Yun, Your patch is now in line to be reviewed. Reviewing Companies, Please review Yun's patch for zero length Secure Send/Receive commands and provide feedback on or before September 4th. Thanks! Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, July 30, 2015 3:25 PM To: Yun Wang Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Thank you for your patch submission. There is one patch in front of yours. Once that patch has been reviewed and approved, your patch will be reviewed next. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Yun Wang Sent: Friday, July 24, 2015 6:00 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Zero Length for Security Receive and Security Send command Hi: Current OFA driver doesn't allow zero length for Security Receive and Security Send command. Per NVMe spec., "Security Receive command with the Security Protocol field set to 00h shall return information about the security protocols supported by the controller. This command is used in the security discovery process and is not associated with a Security Send command. Refer to SPC-4 for the details of Security Protocol 00h and the SP Specific field". Per SPC-4 spec., "a transfer length of zero specifies that no data transfer shall take place. This condition shall not be considered an error", zero length of data transfer for Security Protocol 00h should be allowed. On the other hand, for some practices with other Security Protocol, zero length will be needed, too. This patch is to allow zero length of data transfer for Security Receive and Security Send command. It has been tested over Win8.1 x64 platform and works as expected. Please review and help merge it into the trunk. The password for the attachment is nvme_sec. Best Regards, Yun Wang ULINK Technology, Inc. Website: www.ulinktech.com Office: +1(408) 446-8455 Email: yun.wang at ulinktech.com [ulink logo 2] DISCLAIMER: The information contained in this message is confidential and may be legally privileged. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 4274 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1628 bytes Desc: image003.jpg URL: