はじめに

　以下の予定で、2019/6/10にリリースされたNVM Express（以降NVMeと表記します）の最新仕様であるリビジョン1.4^[1]について、新機能や注目（注意）が必要な変更点、をまとめています。今回が最終回になります。

NVM Setとその関連機能 → 2019/8/28投稿の記事
新コマンドと新機能（NVM Setとその関連機能を除く） → 2019/9/11投稿の記事
既存機能に対する変更点のうち注意が必要なもの

　この記事では、NVMeリビジョン1.4における、既存機能に対する変更点のうち注意が必要なものをまとめます。

サマリ

注意（注目）が必要だと思われる変更点がある機能は以下の通り
- Controller Type
- Controller Memory Buffer (CMB)
- Flushコマンド
- Sanitizeコマンド
変更の理由と目的はおおむね理解できるものの、複雑になる方向の変更なので、注意が必要

Controller Type

　NVMe over Fabrics (NVMe-oF)仕様との整合性をとるため、などの理由により、「コントローラタイプ」が導入されました。

　具体的には、I/O Controller、Administrative Controller、Discovery Controllerの3つです。以下に、NVMe仕様書記載の図を引用します。

図1：Controller Type（NVMe仕様書より引用）

　NVMeリビジョン1.4に準拠したコントローラは、自分がどのコントローラタイプなのか、をIdentifyコマンドの結果で表明しなければなりません。

　I/O Controllerは、ReadやWriteといったコマンドをサポートし、不揮発性メディアへのアクセス手段を提供するコントローラを指します。リビジョン1.3dまでの仕様における「コントローラ」は、この「I/Oコントローラ」に相当します。

　Administrative Controllerは、管理機能に特化したコントローラです。このため、このタイプのコントローラはI/Oキュー（I/O Submission QueueとI/O Completion Queue）を作成・削除するコマンドをサポートできません。したがって、このタイプのコントローラはI/Oコマンド（ReadやWriteなど）を受信することができません。

　Discovery Controllerは、NVMe-oF環境で必要となるコントローラで、特定のログページ（Get Log Pageコマンドで取得可能なデータ）を提供するコントローラであることのみが記載されています。このタイプのコントローラに関する詳細は、NVMe-oFの仕様を参照する必要があります。

Controller Memory Buffer (CMB)

　Controller Memory Buffer (CMB) とは、NVMeドライブ（のコントローラ）が持つメモリ領域に各種キュー（I/O Submission Queueなど）やデータを配置することを可能にする機能です。

　このCMBについては、リビジョン1.4において設定項目が大幅に変更・増加され、以前と比較してCMBを有効にするまでの手順が複雑に（煩雑に）なりました。

　リビジョン1.3dまでは、ホストは以下の手順でCMBを使用することができました。

CMB領域のベースアドレスを取得する（CMBLOCレジスタ）
CMB領域のサイズを取得する（CMBSZレジスタ）

　これに対して、リビジョン1.4では、CMBを使用するためにはホストは以下の手順を踏む必要があります。

コントローラがCMBをサポートしているかを確認する（CAPレジスタのCMBSフィールド）
コントローラがCMB設定レジスタを有効にしているかどうか確認する（CMBMSCレジスタ）
CMB領域がマップされているアドレス空間上の領域を確認する（CMBLOCレジスタ）
CMB領域のサイズを確認する（CMBSZレジスタ）
コントローラにCMB領域へのアクセスを要求する時に発行するアドレス領域を設定する（CMBMSCレジスタ）
コントローラにCMB領域の有効化を要求する（CMBMSCレジスタ）
コントローラがCMBを有効にしたことを確認する（CMBSTSレジスタ）

　煩雑になっているのが一目瞭然ですね。
　仕様書を読む限り、この変更の目的は2つあると考えられます。

　ひとつは、CMBが有効になるタイミングを明確化すること、です。

　リビジョン1.3dまでの仕様では、極論すると、コントローラの設定レジスタが読めるようになったタイミングでCMBが有効である、と解釈することもできてしまいます。これは曖昧でかつコントローラにとっては大変なので、CMBが有効になるタイミングを明確に定義するとともに、CMBが有効になるタイミングをコントローラに委ねるようにしたのだと考えられます。

　もうひとつは、仮想化環境への対応、です。

　ゲストOSがCMBを利用していて、例えばReadやWriteコマンドのデータ転送先・転送元としてCMB内のアドレスを指定したとします。この時、ゲストOSが指定したアドレスがゲストOSのアドレス空間上でのアドレス（のまま）になる可能性があります。
　一方で、SSDコントローラがCMBをマップしているアドレス空間はホストOSのアドレス空間です。この結果、SSDコントローラは誤ったアドレスに対してDMA転送を要求してしまいます（図2）。

図2：仮想化環境でのCMB利用時に不具合が生じるケース（リビジョン1.3dまで）

　この間違いを防止するためには、ハイパーバイザがゲストOS間でコンテキストを切り替える際に「ホストがCMB領域へのアクセスを要求する時に発行するアドレス領域」をゲストOSに合わせて設定する、という方法が考えられます（図3）。

図3：仮想化環境でのCMB利用（リビジョン1.4）

　図3のようにすることで、コントローラは、ゲストOSがデータ転送先として指定しているアドレスはCMB領域の先頭からオフセットA-Bのアドレスだ、ということがわかりますので、正しくデータ転送できます。

　リビジョン1.4では、この「CMB領域へのアクセスを要求する時に発行するアドレス領域」のベースアドレスを設定するフィールドが新設されました。
　CMBについては、上記仕様変更の他に、CMB上に配置するデータに関する設定項目が数多く追加されていますので、注意が必要です。

　なお、図2に示した不具合はPersistent Memory Region (PMR)でも発生し得ますので、PMRについても同様の設定項目が存在します。

Flushコマンド

　Flushコマンドは、NVMe仕様におけるVolatile Write Cache (VWC)に格納されていて不揮発化されていないデータを不揮発化することを要求するコマンドです。ReadコマンドやWriteコマンドの次に発行頻度が高そうなコマンドでしょうか。

　このFlushコマンドでは、以前よりNamespace ID (NSID)フィールドに処理対象のNamespaceを指定する必要がありましたが、0xFFFFFFFFが指定された場合の挙動が未定義でした。

　そこでリビジョン1.4では、対象のNamespaceとして0xFFFFFFFFを指定した場合の挙動が定義されました。

　具体的には、FlushコマンドのNSIDとして0xFFFFFFFFが指定された時に「エラーにする」か「全Namespaceが対象と解釈する」かを、コントローラが選択します。
　そしてコントローラは、NSIDに0xFFFFFFFFを指定されたFlushコマンドに対して前記2つのどちらの対応をするかについて、Identifyコマンドに対するレスポンスであるIdentify Controller Data Structureで表明します（図4）。

図4：Identify Controller Data StructureのVolatile Write Cache (VWC)フィールド

　つまり、リビジョン1.4準拠を謳うコントローラは、上記VWCフィールドのビット[2:1]を10bか11bにしなければなりません。

　この仕様変更はリビジョン1.3dまでと互換性がありませんので、NVMeドライバソフトウェアには注意が必要です。

　なぜなら、リビジョン1.3dまではNSIDフィールドが0xFFFFFFFFでもFlushコマンドはエラーにならなかった可能性が高いですが、リビジョン1.4ではエラーになってしまう可能性があるからです。
　これを回避するためには、NVMeデバイスドライバは、接続しているNVMeデバイスが準拠するバージョンをきちんとチェックするか、もしくはNSIDに0xFFFFFFFFを指定しないようにしなければなりません。

　試しに、qemuを使用して、Windows 10 Home Build 18950（Insider Programで入手）に同梱されているMicrosoftのinboxデバイスドライバ(stornvme.sys)の挙動を調べてみました。デバイスドライバのバージョンは10.0.18950.1000 (WinBuild 160101.0800)です。

　ベンチマークソフトウェアを動かしたり、再起動を行ったりしましたが、その実験中に限って言えば、このデバイスドライバは、ドライブが準拠するNVMeのリビジョンが1.4でなくても、FlushコマンドのNSIDフィールドに0xFFFFFFFFを入れることはなく、実在するNamespaceのIDを入れていました（図4）。

図4：Windows 10 Home (Build 18950)同梱NVMeドライバのFlushコマンドに関する挙動調査結果

　これだけでは「NSIDに0xFFFFFFFFを入れることは絶対にない」とは断定できませんが、この挙動であれば、NVMeリビジョン1.4準拠のNVMeドライブを接続してもこのFlushコマンドの仕様変更に関する問題を起こす可能性は低そうです。

Sanitizeコマンド

　Sanitizeコマンドとは、ドライブ内のデータを破棄する（読めなくする）機能です。ユーザデータを記録しているNANDフラッシュメモリのブロックを消去(Erase)する方法(Block Erase)、データを上書きする方法(Overwrite)、そして暗号化に使用している鍵を変える方法(Crypto Erase)、の3種類が定義されています。

　リビジョン1.3dまでの仕様は、コントローラが上記3つの方法のうちどれをサポートしているのかを表明し、ホストがSanitizeコマンドで、Sanitizeコマンドが成功した後にSanitizeしたLBAに対してDeallocateするかどうかを指定する、というものでした。

　これに対してリビジョン1.4の仕様では、Sanitizeコマンドに関する設定項目が増えて、動作が複雑になりました。複雑になったのは（仕様変更の目的は）、以下の2点をより明確にするためだと思われます。

Sanitizeコマンドの処理においてDeallocateするかどうか
Sanitizeコマンド処理の「残り所要時間」（Get Log Pageコマンドで取得できる）にメディア（例：NANDフラッシュメモリ）を変更する処理（仕様書には具体的な処理の内容は記載されていない）にかかる時間がふくまれているかどうか

　言葉で説明するのは難しいので、フローチャート（図5）にまとめました。

図5：Sanitizeコマンドに関する設定項目の関係

　結局Deallocateするのかしないのか、フローチャートを最後まで辿らないと決まらないことがわかります。

　そもそも、"No Deallocate Inhibit"とか"No Deallocate Response Mode"など、否定形の設定項目がいくつも重なっていることがわかりにくくなっている原因に見えます。"No Deallocate Inhibit"に至っては二重否定ですし。

　Sanitizeコマンドはそうそう頻繁に使うコマンドではないでしょうし、図5で示した場合分けのうち実際に用いられるパターンは限られるでしょうから、実用上問題にはならないのかもしれません。SanitizeコマンドをサポートするSSDベンダは大変ですが。

まとめ

　この記事では、2019年6月10日に発行されたNVMeの最新仕様であるリビジョン1.4について、既存機能に対する変更点のうち注意が必要なものについて、その概要を説明しました。

　記事内でも触れたように、リビジョン1.4で既存機能に加えられたいくつかの変更については、エンタープライズやデータセンター環境だけでなくクライアント環境にも関係があり、またSSDとホストのデバイスドライバの間での相性問題を引き起こし兼ねないため、注意が必要です。

リファレンス

[1] NVM Express, "NVM Express^TM Base Specification", Revision 1.4, June 10, 2019

ライセンス

この記事はクリエイティブ・コモンズ表示 - 継承 4.0 国際ライセンスの下に提供されています。

NVMe Revision 1.4: Other changes