NVMe Admin Command Set

섹션 4.2에서는 Submission Queue Entry(SQE) 구조 및 모든 Admin 명령어에 공통되는 필드를 정의한다. 섹션 4.6에서는 CQE(Complement Queue Entry) 구조 및 모든 Admin command에 공통되는 필드를 정의한다. 이 섹션에서는 Admin 명령 집합에 대한 SQE 및 CQE 구조의 command 특정 필드(즉, SQE Command Dwords 10 ~ 15 및 CQE Dword 0)를 정의한다.

Admin command는 I/O Queue Status에 영향을 받지 않아야 한다(예: 전체 I/O CQ는 I/O SQ삭제 command을 지연시키거나 지연시켜서는 안 됩니다).

그림 141은 Admin Command를 정의하고, 그림 142는 NVM command set에 특정한 I/O command set 특정 Admin Command(즉, NVM command set 특정 admin command)을 정의한다. 다양한 컨트롤러 유형에 대한 필수 command, 선택 command 및 금지 command은 섹션 7.1을 참조하십시오.

5.1 Abort Command

Abort command은 이전에 Admin SQ 또는 I/O SQ에 제출된 특정 command을 중단하는 데 사용된다. Abort command은 Best Effort command로, 중단할 command가 이미 완료되었거나, 현재 실행 중이거나, queue에 너무 깊게 들어가 있을 수 있다.

많은 수의 command(예: ACL 필드에 나열된 제한보다 많은 수의 command)를 중단하려면 host가 섹션 7.3.3에 설명된 절차를 따라 I/O SQ를 삭제하고 I/O SQ를 다시 생성해야 한다.

Abort command는 Command Dword 10 필드를 사용한다. 다른 모든 command 특정 필드는 reserved 되어있다.
Identify Controller data structure(Controller data structure, 그림 251 참조)의 Abort Command Limit 필드는 Abort command의 동시 실행에 대한 컨트롤러 제한을 나타낸다. Host는 미결된 Abort command의 수가 이 값을 초과하도록 허용해서는 안 된다. 컨트롤러는 Abort Command Limit Exceed 상태로 초과된 Abort command을 완료할 수 있다.

5.1.1 Command Completion

Abort command가 완료되면, 컨트롤러는 Abort command의 status를 나타내고, command가 중단되었는지 여부를 나타내는 CQ Entry를 Admin CQ에 게시한다.
CQ Entry의 Dword 0은 Command가 Abort되었는지 여부를 나타낸다.
Abort Command가 성공적으로 중단된 경우 aborted command에 대한 CQ Entry이 Admin CQ에 게시되기 전에 Abort Command에 대한 CQ Entry가 Command Abort Requested 상태로 해당 Admin 또는 I/O CQ에 게시되어야 하며, Abort command에 대한 CQ Entry에서 Dword 0의 비트 0이 '0'으로 지워진 Abort command가 어떤 이유로든 중단되지 않은 경우에는 Abort command에 대한 CQ Entry에서 Dword 0의 비트 0이 '1'로 설정되어야 한다.
Abort command과 관련된 command별 status 값은 그림 144에 정의되어 있다.

Aborted Command
Command는 항상 중단시킬 수 없다.
중단시킬 command가 이미 완료되었거나
현재 실행중인 command이거나
Queue에 너무 깊게 들어가 있을 수 있다.

Submission Queue Identifier <SQ>[DW10][15:00] :
Command가 발행된 SQ의 ID
Command Identifier <SQ>[DW10][31:16] :
중단시킬 Command 의 ID (CDW0.CID)

Identify Controller Data Structure에 있는 Abort Command Limit(ACL)필드 :
컨트롤러가 동시에 실행할 수 있는 Abort command의 최대 수

5.2 Asynchronous Event Request command

Asynchronous Event는 이러한 Event가 발생할 때 host SW에 status, error 및 health 정보를 알리기 위해 사용된다.

Asynchronous Event가 컨트롤러에 의해 보고되도록 하려면 host SW는 하나 이상의 비동기 이벤트 request command를 컨트롤러에 제출해야 한다.

컨트롤러는 Asynchronous Event Request command를 완료하여 host에 이벤트를 지정한다. Host SW는 컨트롤러가 command를 즉시 실행할 수 없다고 예상해야 하며 보고할 이벤트가 있을 때 command를 완료해야 한다.

Asynchronous Event Request Command는 컨트롤러에서 Asynchronous Event를 보고할 수 있도록 host SW에서 제출된다. 이 command는 TimeOut이 없다. 컨트롤러는 host에 보고할 비동기 이벤트가 있을 때 이 command에 대한 CQ Entry를 게시한다. 컨트롤러가 Reset될 때 비동기 이벤트 request command가 완료되지 않은 경우 각 command는 중단되고 CQE를 반환하지 않아야 한다.
모든 command별 필드가 reserved되어 있다.

Host SW는 이벤트 보고 지연 시간을 줄이기 위해 여러 개의 Asynchronous Event Request Command를 제출할 수 있다. 동시에 해결되지 않은 Asynchronous Event Request Command의 총 수는 그림 251의 Identify Controller Data Structrue에 지정된 Asynchronous Event Request Limit에 의해 제한된다.

Asynchronous Event는 Event Type으로 그룹화된다. 이벤트 유형은 비동기 이벤트 request command에 대한 CQ Entry의 Dword 0에 있는 비동기 이벤트 유형 필드에 표시된다. 컨트롤러가 해결되지 않은 비동기 이벤트 request command에 대한 CQ Entry를 게시하여 비동기 이벤트를 보고하면 해당 이벤트 유형의 후속 이벤트는 host가 해당 이벤트를 지울 때까지 컨트롤러에 의해 자동으로 masking된다.

Get Log Page command를 사용하여 해당 이벤트와 관련된 로그 페이지를 읽음으로써 이벤트가 지워진다(섹션 참조) 5.14).
정의된 이벤트 유형은 다음과 같다:

a) Error Event : 특정 command와 관련이 없는 일반적인 오류를 나타낸다(그림 147 참조). 이 event를 지우기 위해 host SW는 Get Log Page command를 사용하여 오류 정보 로그(섹션 5.14.1.1 참조)를 읽으며 Retain Asynchronous Event 비트를 '0'으로 지운다;
b) SMART/Health Status Event :SMART 또는 Health Status 이벤트를 나타낸다(그림 148 참조). 이 이벤트를 지우기 위해 host SW는 Retain Asynchronous Event Bit를 0으로 지운 상태에서 Get Log Page Command을 사용하여 SMART/Health Information 로그를 읽는다(섹션 5.14.1.2 참조). 비동기 이벤트를 트리거하는 SMART/Health 조건은 Set Features command를 사용하여 비동기 이벤트 구성 기능에서 설정할 수 있다(섹션 5.21 참조);
c) Notice event : 일반적인 이벤트를 나타낸다(그림 149 참조). 이 이벤트를 지우기 위해 host SW는 그림 149에 설명된 대로 적절한 로그 페이지를 읽는다. 비동기 이벤트를 트리거하는 조건은 Set Features command를 사용하여 비동기 이벤트 구성 기능에서 설정할 수 있다(섹션 5.21.1.11 참조). 이러한 알림 이벤트는 다음을 포함한다:
```
	A. Namespace 속성이 변경됨;    
	B. 펌웨어 활성화 시작;   
	C. 변경된 원격 측정 로그;
	D. 비대칭 Namespace access 변경;   
	E. 예측 가능한 지연 시간 이벤트 집계 로그 변경;
	F. LBA 상태 정보 경보 및           
	G. 내구성 그룹 이벤트 집계 로그 페이지 변경;
```

d) NVM Command Set Specific events : I/O command set에 의해 정의되는 이벤트:

A. Reservation Log Page Available event: 하나 이상의 예약 알림 로그 페이지(섹션 5.14.1.16.1 참조)를 사용할 수 있음을 나타낸다. 이 이벤트를 지우려면 host SW가 로그 페이지 가져오기 command를 사용하여 예약 알림 로그 페이지를 읽고 비동기 이벤트 비트를 `0`으로 유지한다;

B. Sanitize Operation Completed event: 모든 논리 블록의 예기치 않은 할당 해제 없이 Sanitize 작업이 완료되었음을 나타낸다(관련 추가 미디어 수정 포함, 그림 251의 Sanitize 후 미디어 수정 없음 필드 참조). Sanitize Status 로그 페이지(섹션 5.21.1.23 참조)에서 상태를 확인할 수 있다(섹션 5.14.1.16.2 참조). 이 이벤트를 해제하려면 host SW가 Get Log Page command를 사용하여 Sanitize Status 로그 페이지를 읽으며 Retain Asynchronous Event 비트를 '0'으로 해제한다.

C. Sanitize Operation Completed With Unexpected Deallocation event: 모든 LBA가 예기치 않게 할당 해제되어 Sanitize 작업이 완료되었음을 나타낸다(섹션 5.21.1.23 참조). Sanitize Status 로그 페이지(섹션 5.14.1.16.2 참조). 이 이벤트를 지우기 위해 host SW는 Get Log Page Command를 사용하여 Sanitize Status 로그 페이지를 읽으며 Retain Asynchronous Event 비트를 `0`으로 지운다.

그리고.

e) Vender Specific event : 벤더 특정 이벤트를 나타낸다. 이 이벤트를 지우려면 host SW가 Get Log Page Command를 사용하여 표시된 벤더 특정 로그 페이지를 읽으며 Retain Asynchronous Event 비트를 0으로 지운다.
컨트롤러가 Sanitize Config 기능을 지원하는 경우 Sanitize Operation Complete With Unexpected Dallocation 비동기 이벤트가 지원된다(섹션 5.21.1.23 참조).

컨트롤러가 Sanitize Config 기능을 지원하는 경우 Sanitize Operation Complete With Unexpected Dallocation 비동기 이벤트가 지원된다.(섹션 5.21.1.23 참조).

비동기 이벤트는 새로운 Entry가 Log Page(예를 들어, 오류 정보 로그)에 추가되거나 상태 업데이트(예를 들어, SMART/Health 로그의 상태)로 인해 보고된다. status 변경은 영구적(예를 들어, 미디어가 읽기 전용이 되었음)이거나 일시적(예를 들어, 온도가 일정 기간 동안 임계값에 도달했거나 초과됨)일 수 있다. Host SW는 비동기 이벤트의 반복 보고를 피하기 위해 다른 비동기 이벤트 요청 명령을 발행하기 전에 이벤트 임계 값을 수정하거나 일시적 및 영구적 Status 변경에 대해 이벤트를 마스킹해야 한다.

보고가 활성화된 이벤트가 발생하고 미결된 비동기 이벤트 request command가 없으면 컨트롤러는 해당 비동기 이벤트 유형의 이벤트 정보를 유지하고 해당 정보를 수신된 다음 비동기 이벤트 request command에 대한 응답으로 사용해야 한다. Get Log Page command가 비동기 이벤트 request command를 수신하기 전에 이벤트를 지웠거나 전원 끄기 조건이 발생하면 알림이 전송되지 않는다. 비동기 이벤트 request command에 대한 응답이 동일한 유형의 이벤트가 여러 개 발생하면 해당 이벤트가 비동기 이벤트 요청 명령에 대한 단일 응답으로 보고될 수 있다. 다른 유형의 이벤트가 여러 개 발생하면 컨트롤러는 해당 이벤트의 queue를 유지하여 후속 Asynchronous Event Request command에 대한 응답으로 보고해야 한다.

Asynchronous Event Request Command :
컨트롤러로부터 Asynchronous event status를 확인하는 방법
비동기 이벤트 후 그 다음 event는 host가 해당 log page를 읽을 때까지 동일한 유형의 event는 자동으로 making된
※ Submission Queue에서 별도의 구간 없음

Type <CQ>[DW0][02:00] :

Identify Controller Data Structure에 있는 Asynchronous Event Request Limit(AERL)필드 :
동시에 해결되지 않은 Asynchronous Event Request command의 총 개수

Async Event Info <CQ>[DW0][15:08] : Error type details
Log Page <CQ>[DW0][23:16] :
비동기 이벤트와 연관되는 Log page ID
이벤트를 지우기 위해 Host가 Log Page를 읽어야한다.

5.2.1 Command Completion

호스트에 보고할 비동기 이벤트가 있는 경우 CQ Entry가 Admin CQ에 게시된다. 비동기 이벤트 request와 관련된 command별 status 값은 그림 145에 정의되어 있다.
CQ Entry의 Dword 0은 비동기 이벤트에 대한 정보를 포함한다. CQ Entry의 Dword 0의 정의는 그림 146에 있다. 비동기 이벤트 유형에 따라 그림 147, 그림 148, 그림 149 또는 그림 150의 정보가 비동기 이벤트 정보 필드에 반환된다.

Asynchronous Event Information – Error Status

Asynchronous Event Information – SMART/Health Status

Asynchronous Event Information – NVM Command Set Specific Status

Asynchronous Event Information – Notice

5.3 Create I/O Completion Queue Command

Create I/O CQ command는 Admin CQ를 제외한 모든 I/O CQ를 생성하는 데 사용된다. Admin CQ는 ACQ 레지스터에 base address를 지정하여 생성된다. CQ를 설명하기 위해 PRP List가 제공되는 경우 PRP List는 host SW에 의해 host 물리 메모리의 동일한 위치에 유지되어야 하며 PRP List의 값은 이 CQ에 대한 해당 Delete I/O Complete Queue command가 성공적으로 완료되거나 컨트롤러가 재설정될 때까지 수정되지 않는다. PRP List 값이 수정되면 동작이 정의되지 않는다.
Create I/O CQ command는 PRP Entry 1, Command Dword 10, Command Dword 11 필드를 사용하며, 다른 모든 command 고유 필드는 reserved 된다.

[31:16] DW10 Queue Size (QSIZE)
이 필드는 생성할 Complete Queue의 크기를 나타낸다. 크기가 0h이거나 컨트롤러가 지원하는 것보다 크다면 컨트롤러는 Invalid Queue Size의 오류를 반환해야 한다. 섹션 4.1.3을 참조하십시오. 이 값은 0의 기준 값이다.

[15:00] DW10 Queue Identifier (QID)
이 필드는 생성할 CQ에 할당할 식별자를 나타낸다. 이 식별자는 이 command에 사용되는 CQ Head Doorbell(즉, 섹션 3.1.26의 값 y)에 해당한다. 이 값은 I/O CQ의 Queue 수 기능(섹션 5.21.1.7 참조)에 보고된 값을 초과할 수 없다. 지정된 값이 0h이거나 보고된 Queue 수를 초과하거나 이미 사용 중인 식별자에 해당할 경우 컨트롤러는 Invalid Queue Identifier의 오류를 반환해야 한다.

[00] DW11 Physically Contiguous (PC)
1 로 설정되면 CQ는 물리적으로 연속되고 PRP Entry 1(PRP1)은 연속된 물리적 버퍼의 주소이다.
0 으로 지워지면 CQ는 물리적으로 연속되지 않고 PRP Entry 1(PRP1)은 PRP List 포인터이다. 이 비트가 0 으로 지워지고 CAP.CQR이 1 로 설정되면 컨트롤러는 Invalid Field in Command의 오류를 반환해야 한다.
다음과 같은 경우:
• 큐는 컨트롤러 메모리 버퍼에 있다.
• PC가 0 으로 지워진다.
• CMBLOC.CQPDS가 0 으로 삭제되었다.
그러면 컨트롤러는 잘못된 컨트롤러 메모리 버퍼 사용 상태로 command를 중단해야 한다.

5.3.1 Command Completion

Command가 완료되면 컨트롤러는 command status를 나타내는 CQ Entry를 Admin CQ에 게시해야 한다.
Create I/O Complete Queue command별 상태 값은 그림 154에 정의되어 있다.

Create I/O Compleiton Queue Command

Physically Contiguous(PC) <CQ>[DW11][00]
0 : SQ가 물리적으로 연속적이지 않고 PRP Entry1은 PRP List Pointer를 가리킴
1 : SQ가 host memory에 물리적으로 연속적이고
PRP Entry1은 연속된 물리적 버퍼의 주소임

PC가 0으로 지워지고 CAP.CQR이 1로 설정되면 오류 발생

잘못된 컨트롤러 메모리 버퍼 사용 상태로 command를 중단해야 함

Queue가 Controller Memory Buffer에 있는 경우
PC가 0으로 clear된 경우
CMBLOC.CQPDS가 0 으로 clear된 경우

5.4 Create I/O Submission Queue Command

I/O Submission Queue Create command는 I/O Submission Queue를 생성하는 데 사용된다.
Admin Submission Queue는 ASQ 레지스터에 base Address를 지정하여 생성된다. 생성할 SQ를 설명하기 위해 PRP List를 제공하는 경우 PRP List는 host 물리 메모리의 동일한 위치에서 host SW에 의해 유지 관리되며 PRP List의 값은 해당 SQ에 대한 Delete I/O Submission Queue command가 완료되거나 컨트롤러가 재설정될 때까지 수정되지 않는다. PRP List 값이 수정되면 동작이 정의되지 않는다.

Create I/O Submission Queue Command는 PRP Entry 1, Command Dword 10, Command Dword 11, Command Dword 12 필드를 사용하며 다른 모든 command 고유 필드는 reserved 된다.

[63:00] DW6-7 PRP Entry1(PRP1)
CDW11.PC가 1 로 설정되어 있는 경우, 이 필드는 물리적으로 연속되는 Submission Queue의 64비트 기본 메모리 주소 포인터를 지정한다. 주소 포인터는 달리 지정되지 않는 한 (CC.MPS의 값을 기준으로) 메모리 페이지 정렬이다.

CDW11.PC가 0 으로 지워진 경우, 이 필드는 SQ를 구성하는 Page List를 기술하는 PRP List Pointer를 지정한다. Page List는 달리 지정되지 않는 한 (CC.MPS의 값을 기준으로) 메모리 페이지 정렬이다. 두 경우 모두 PRP Entry는 0h의 오프셋을 가져야 한다. 연속되지 않는 SQ에서 PRP List의 각 PRP Entry는 0h의 오프셋을 가져야 한다. 오프셋이 0이 아닌 PRP Entry가 있는 경우, 컨트롤러는 PRP Offset Invalid의 오류를 반환해야 한다.

[31:16] DW11 Completion Queue Identifier (CQID)

이 필드는 이 SQ와 관련된 command completion Entry에 사용할 I/O CQ Identifier를 나타낸다.
값이 지정된 경우:

a) 0h (즉, Admin CQ)이면 컨트롤러는 Invalid Queue Identifier 오류를 반환해야 한다;
b) 컨트롤러가 지원하는 범위를 벗어나면 컨트롤러가 Invalid Queue Identifier 오류를 반환해야 한다.
c) 컨트롤러에서 지원하는 범위 내에 있으며 생성된 I/O CQ를 식별하지 않으면 컨트롤러에서 CQ 무효 오류를 반환해야 한다.

[02:01] DW11 Queue Priority (QPRIO) :
이 필드는 이 Submission Queue 내의 command에 사용할 우선 순위 클래스를 나타낸다. 이 필드는 urgent 우선 순위 클래스가 있는 WRR이 선택된 중재 메커니즘인 경우에만 사용되며 urgent 우선 순위 클래스가 있는 WRR 사용하지 않는 경우에는 필드가 무시된다. 섹션 4.13을 참조하십시오.

[00] DW11 Physically Contiguous (PC)
1 로 설정되면 CQ는 물리적으로 연속되고 PRP Entry 1(PRP1)은 연속된 물리적 버퍼의 주소이다. 0 으로 지워지면 CQ는 물리적으로 연속되지 않고 PRP Entry 1(PRP1)은 PRP List 포인터이다. 이 비트가 0 으로 지워지고 CAP.CQR이 1 로 설정되면 컨트롤러는 Invalid Field in Command의 오류를 반환해야 한다.
다음과 같은 경우:
• 큐는 컨트롤러 메모리 버퍼에 있다.
• PC가 0 으로 지워진다.
• CMBLOC.CQPDS가 0 으로 삭제되었다.

그러면 컨트롤러는 잘못된 컨트롤러 메모리 버퍼 사용 상태로 command를 중단해야 한다

[15:00] DW12 NVM Set Identifier (NVMSETID)
이 필드는 이 Submission Queue와 연결될 NVM 세트의 식별자를 나타낸다.
이 필드가 0h로 지워지거나 SQ 연결 기능이 지원되지 않는 경우(섹션 8.23 참조), 이 SQ는 특정 NVM 집합과 연결되지 않는다. 이 필드가 NVM Set List(그림 254 참조)에 지정되지 않은 0이 아닌 값으로 설정되고 SQ Associations 기능이 지원되는 경우(섹션 8.23 참조), 컨트롤러는 Invalid Field in Command 상태 코드로 command를 중단해야 한다. Host는 이 SQ의 다른 NVM Set와 관련된 Namespace에 대한 command을 제출해서는 안 된다(섹션 8.23 참조).

5.4.1 Command Completion

Create I/O Submission Queue command가 완료되면 컨트롤러는 CQ Entry를 Admin CQ에 게시한다. Create I/O Submission Queue Command 특정 Status 값은 그림 159에 정의되어 있다.

Create I/O Submission Queue Command

Physically Contiguous(PC) <SQ>[DW11][00]
0 SQ가 물리적으로 연속적이지 않고 PRP Entry1은 PRP List Pointer를 가리킴
1 SQ가 host memory에 물리적으로 연속적이고 PRP Entry1은 연속된 물리적 버퍼의 주소임

PC가 0으로 지워지고 CAP.CQR이 1로 설정되면 오류 발생

잘못된 컨트롤러 메모리 버퍼 사용 상태로 command를 중단해야 함

Queue가 Controller Memory Buffer에 있는 경우
PC가 0으로 clear된 경우
CMBLOC.CQPDS가 0 으로 clear된 경우

Physically Contiguous(PC) <SQ>[DW11][00]
0 : SQ가 물리적으로 연속적이지 않고 PRP Entry1은 PRP List Pointer를 가리킴
1 : SQ가 host memory에 물리적으로 연속적이고 PRP Entry1은 연속된 물리적 버퍼의 주소임

PC가 0으로 지워지고 CAP.CQR이 1로 설정되면 오류 발생

잘못된 컨트롤러 메모리 버퍼 사용 상태로 command를 중단해야 함

Queue가 Controller Memory Buffer에 있는 경우
PC가 0으로 clear된 경우
CMBLOC.CQPDS가 0 으로 clear된 경우

Interrupts Enabled (IEN) <SQ>[DW11][01]
0 Interrupt 불가능
1 Interrupt 가능

NVM Set Identifier (NVMSETID) <SQ>[DW12][15:00]
SQ와 연결될 NVM Set의 식별자
필드 값이 0h 이거나 SQ 연결 기능이 지원되지 않는 경우
SQ는 특정 NVM Set과 연결되지 않음

5.5 Delete I/O Completion Queue Command

I/O Complete Queue command는 I/O Complete Queue를 삭제하는 데 사용된다. I/O Complete Queue command 삭제는 Command Dword 10 필드를 사용한다. 다른 모든 command 특정 필드는 reserved된다. 이 command가 완료된 후에는 host SW에 의해 Complete Queue를 설명하는 PRP List가 할당 해제될 수 있다.
host SW는 CQ를 삭제하기 전에 관련 I/O SQ가 삭제되는지 확인해야 한다. 관련 I/O SQ가 있는 경우 I/O CQ Delete command는 Invalid queue delete 상태 값으로 중단된다.
참고: Admin CQ는 삭제할 수 없다.

5.5.1 Command Completion

컨트롤러는 Delete I/O command가 완료되면 Admin Complete Queue에 CQ Entry를 게시한다. Delete I/O Complete Queue command별 상태값은 그림 161에 정의되어 있다.

Delete I/O Completion Queue Command

※ Admin CQ는 삭제할 수 없음

Queue Identifier <CQ>[DW10][15:00] : CQ ID Number

이 커맨드가 실행 완료되면, host SW가 이 CQ를 묘사하고 있던 PRP List의 메모리 할당을 해제 시킬 수 있음 (Deallocation)
CQ를 지우기 전 연관된 SQ가 지워져 있나 반드시 확인을 해야 함.

5.6 Delete I/O Submission Queue Command

I/O Submission Queue command는 I/O SQ를 삭제하는 데 사용된다. I/O SQ Command 삭제는 Command Dword 10 필드를 사용한다. 다른 모든 command reserved된다. 이 command가 완료된 후, Submission Queue를 기술하는 PRP List는 host SW에 의해 할당 해제될 수 있다.

Delete I/O Submission Queue Command가 성공적으로 완료되면 이전에 지정된 SQ에 제출된 모든 I/O Command는 명시적으로 완료되거나 암묵적으로 완료된다. Delete I/O Submission Queue Command에 대한 CQ Entry를 반환하기 전에 삭제할 I/O Submission Queue에 이전에 제출된 다른 command는 적절한 상태로 완료될 수 있다(Successful Complete, SQ Delete로 인해 Command Aborted). 컨트롤러는 Delete I/O SQ Command가 성공적으로 완료된 후 삭제된 I/O SQ에 제출된 I/O Command에 대해 완료 상태를 게시하지 않는다. Delete I/O SQ Command가 성공적으로 완료되었다는 것은 컨트롤러가 CQ Entry를 게시하지 않은 이전에 제출된 I/O CQ에 대해 SQ Delete로 인해 Command Aborted가 암묵적으로 완료되었음을 나타낸다.
참고: Admin SQ를 삭제할 수 없다.

5.6.1 Command Completion

표시된 I/O Submission Queue에 제출된 모든 command가 완료되거나 중단된 후, Queue가 삭제되면 CQ Entry가 Admin Complete Queue에 게시된다. Delete I/O Submission Queue command 별 상태 값은 그림 163에 정의되어 있다.

Delete I/O Submission Queue Command

※ Admin SQ는 삭제할 수 없음

`Queue Identifier < SQ>[DW10][15:00] : SQ ID Number

이 커맨드가 실행 완료되면, host SW가 이 SQ를 묘사하고 있던 PRP List의 메모리 할당을 해제 시킬 수 있음 (Deallocation)

삭제하려고 지정된 SQ의 모든 command는 abort되거나 완료된 상태여야 함 (Successful Complete, SQ Delete로 인해 Command Aborted)

5.7 Doorbell Buffer Config Command

Doorbell Buffer Config command는 제3항에 정의된 컨트롤러의 Doorbell Register를 미러링하는 두 개의 개별 메모리 버퍼를 제공하는 데 사용된다.
이 command는 경쟁하는 컨트롤러를 대상으로 하며 일반적으로 물리적 NVMe 컨트롤러에서 지원되지 않는다. 두 개의 버퍼는 각각 "Shadow Doorbell" 및 "EventIdx"로 알려져 있다. 이러한 버퍼가 사용되는 방법의 예는 섹션 7.13을 참조하십시오.

Doorbell Buffer Config Command는 PRP Entry 1 및 PRP Entry 2 필드를 사용한다. 다른 모든 command 지정 필드는 reserved된다.
Command는 Namespace 특정이 아니며 Metadata를 지원하지 않으며 SGL을 지원하지 않는다. 설정은 컨트롤러 Level Reset 설정 전체에서 유지되지 않는다.
Doorbell Buffer Config Command과 함께 제공되는 각 버퍼는 CC.MPS 필드에 정의된 대로 단일 물리 메모리 페이지여야 한다. 컨트롤러는 다음 조건을 만족하는지 확인해야 한다:

(4 << CAP.DSTRD) * (max(NSQA, NCQA)+1) <= (2^(12+CC.MPS))

5.7.1 Command Completion

Command가 완료되면 컨트롤러는 command의 상태를 나타내는 CQ Entry를 Admin CQ에 게시한다. Shadow Doorbell Buffer 또는 EventIdx Buffer Memory Addresss가 유효하지 않은 경우 Command 내의 Invalid Field의 상태 코드를 반환해야 한다.

5.8 Device Self-Test Command

Device Self-test 명령은 Device Self-test 작업을 시작하거나 Device Self-test 작업을 중단하는 데 사용된다(섹션 8.11 참조). Device Self-test 명령은 특별히 다음과 같은 용도로 사용된다:

a) 짧은 장치 self-test를 시작합니다;
b) 확장 장치 self-test를 시작합니다
c) vendor별 기기 self-test를 시작합니다
d) 이미 진행 중인 self-test를 중단합니다

Device Self-test동작은 Device Self-test command를 제출한 컨트롤러에 의해 수행된다. Namespace Identifier 필드는 Figure 167에 명시된 바와 같이 Device Self-test동작에 포함되는 Namespace를 제어한다.
Device Self-test Command의 처리 및 이미 진행 중인 Device Self-test 작업과의 상호 작용은 그림 169에 정의되어 있다.

5.8.1 Command Completion

그림 169에 명시된 대로 적절한 조치를 취한 후 CQ Entry가 Admin CQ에 게시된다. Device Self-test 명령 특정 상태 값은 그림 170에 정의되어 있다.

Device Self-Test Command

사용목적
Short device, Extended device, Vendor specific device Self-test 시작, 이미 진행 중인 self-test 중단
Device Self-test Namespace Test Action

Self-test Code(STC) [DW10][03:00] :

5.9 Directive Receive Command

Directive Receive command는 Directive Type에 의존하는 데이터 버퍼를 반환합니다. 섹션 9를 참조하십시오.
Directive Receive command는 Data Pointer, Command Dword 10 및 Command Dword 11 필드를 사용한다. Command Dword 12 및 Dword 13은 Directive Type 필드 및 Directive Operation 필드를 기반으로 사용될 수 있다. 다른 모든 command 특정 필드는 reserved 되어 있다.

NUMD(Number of Dwords) 필드가 반환할 데이터 구조의 크기보다 작은 길이에 해당하면 해당 데이터 구조의 지정된 부분만 전송된다. NUMD 필드가 해당 데이터 구조의 크기보다 큰 길이에 해당하면 데이터 구조의 전체 내용이 전송되고 추가적인 데이터는 전송되지 않는다.

5.9.1 Command Completion

Command가 완료되면, 컨트롤러는 command에 대한 상태를 나타내는 CQ Entry를 Admin CQ에 게시하고, 반환될 수 있는 Command별 상태 값은 Directive Type, 섹션 9를 참조하십시오.
Directive Receive 명령별 상태 값은 그림 174에 정의되어 있다.

5.10 Directive Send Command

Directive Send command는 Directive Type에 의존하는 데이터 버퍼를 컨트롤러로 전송한다. 섹션 9를 참조하십시오.

**Directive Send command는 Data Pointer, Command Dword 10 및 Command Dword 11 필드를 사용한다. Command Dword 12 및 Command Dword 13은 Directive Type 필드 및 Directive Operation 필드를 기반으로 사용될 수 있다. 다른 모든 Command 특정 필드는 reserved된다.

5.10.1 Command Completion

Command가 완료되면, 컨트롤러는 command에 대한 상태를 나타내는 CQ Entry를 Admin CQ에 게시하고, 반환될 수 있는 명령별 상태 값은 Directive Type, 섹션 9를 참조하십시오.

5.11 Firmware Commit Command

참고: 이 command는 NVM Express 버전 1.0 및 1.1에서 "Firmware Activate"로 알려져 있다
펌웨어 commit command는 펌웨어 이미지 또는 부팅 파티션을 수정하는 데 사용된다.
펌웨어 이미지를 수정할 때 Firmware Commit command는 유효한 펌웨어 이미지가 다운로드되었는지 확인하고 특정 펌웨어 슬롯에 대한 revision을 커밋한다.

Host는 이 command의 일부로 다음 Controller Level Reset 시 활성화할 Firmware Image를 선택할 수 있다.
Host는 그림 251의 Identify Controller data structure의 펌웨어 revision 필드를 조사하여 현재 실행 중인 펌웨어 revision을 결정할 수 있다.
Host는 Firmware Slot 정보 Log Page를 조사하여 다음 Controller Level Reset 시 실행할 Firmware Revision을 결정할 수 있다. NVM subsystem의 모든 컨트롤러는 Firmware Slot을 공유하며 모든 컨트롤러에 동일한 Firmware Image가 적용된다.

Firmware Image를 활성화하면 host가 예상하지 못한 컨트롤러 동작의 변경(예: UUID 목록의 호환되지 않는 변경(섹션 8.24.2 참조)이 발생할 수 있다. 이 경우 Commit Action 필드가 011b로 설정되어 있으면, 컨트롤러는 command를 Firmware Activation Required Conventional Reset(펌웨어 활성화에는 기존 리셋이 필요함) 상태로 중단해야 한다.

Boot 파티션을 수정할 때 host는 Boot 파티션을 선택하여 활성으로 표시하거나 교체할 수 있다. Boot 파티션은 잠금이 해제될 때만 쓸 수 있다(섹션 8.13 참조).

Firmware Commit command는 Command Dword 10 필드를 사용한다. 다른 모든 command 특정 필드는 reserved되어 있다.

5.11.1 Command Completion

Firmware Commit command가 완료되면 컨트롤러는 명령의 상태를 나타내는 CQ Entry를 CQ에 게시한다.

다음 컨트롤러 레벨 재설정 시 새 펌웨어 이미지의 활성화를 지정하는 Firmware Commit command의 경우(즉, CA 필드가 001b 또는 010b로 설정됨) 상태 코드 값이 0h(즉, 성공 완료)이고 섹션 7.3.2에 정의된 방법 중 하나로 시작되는 컨트롤러 레벨 재설정이 지정된 펌웨어를 활성화한다.

Firmware Commit command별 상태 값은 그림 179에 정의되어 있다.

Firmware Commit(Active) Command
Firmware Image 또는 Boot 파티션을 수정하는데 사용
다운로드한 Firmware Image를 확인하고 Firmware Slot에 로드한다.

Boot Partition ID(BPID) [DW10][31] :
해당되는 경우 commit Action에 사용할 Boot Partition을 지정
Commit Action (CA) [DW10][05:03] :
다운로드 한 Firmware Image / 다운로드하기 전에 배치한 Firmware Image에서 수행할 Action

Firmware Slot(FS) [DW10][02:00] :
Commit Action에 사용할 Firmware Slot을 지정한다.
0h : 컨트롤러는 작업에 사용할 slot(slot 1~slot 7)을 선택해야 한다.

5.12 Firmware Image Download Command

Firmware Image Download Command는 향후 업데이트를 위한 이미지의 전체 또는 일부를 컨트롤러에 다운로드하는 데 사용된다.

Firmware Image Download Command는 Admin SQ 또는 I/O SQ의 다른 command가 미결인 상태에서 제출될 수 있다. Firmware Image Download Command는 (전체 또는 부분적으로) 새로운 이미지를 컨트롤러에 다운로드한다.

이미지는 별도의 Firmware Image Download Command로 개별적으로 다운로드 되는 여러 조각으로 구성될 수 있다.

각 Firmware Image Download Command에는 dword 범위를 지정하는 Dword Offset 및 Numd 필드와 OFST 필드가 중복되는 dword 범위를 갖지 않도록 해야 한다(그림 251 참조). Host SW는 이미지 조각이 중복되는 dword 범위를 갖지 않도록 하고 NUMD 필드와 OFST 필드가 FWUG 필드에 표시된 정렬 및 세분성 요구 사항을 충족하도록 해야 한다(그림 251 참조). 펌웨어 부분이 순서에 맞지 않게 컨트롤러에 제출될 수 있다. Host SW는 Boot 파티션을 업데이트할 때 이미지 부분을 순서에 맞게 제출해야 한다. 범위가 중복되는 경우 컨트롤러는 Overlapping Range의 오류를 반환할 수 있다.

Firmware Image Download Command의 일부로 새 펌웨어 이미지가 활성화되지 않는다. Firmware Update Process에 대한 자세한 내용은 섹션 8.1을 참조하십시오. Firmware Update Process는 부팅 파티션의 내용을 수정하지 않는다. Firmware Partition Update Process에 대한 자세한 내용은 섹션 8.13.2를 참조하십시오.

Host SW는 Boot Partition과 Firmware Image를 동시에 업데이트해서는 안 된다. 이미지를 다운로드한 후 host SW가 다른 이미지를 다운로드하기 전에 펌웨어 commit command를 실행한다. 펌웨어 commit command가 완료된 후 첫 Firmware Image Downolad Command를 처리하면 컨트롤러는 다운로드 된 이미지 중 나머지 부분(있는 경우)을 모두 삭제해야 한다. 펌웨어 다운로드와 펌웨어 commit command Completion 사이에 리셋이 발생하면 컨트롤러는 다운로드 된 이미지 중 모든 부분(있는 경우)을 폐기해야 한다.

Fimeware Image Download Command는 Data Pointer, Command Dword 10, Command Dword 11 필드를 사용한다. 다른 모든 command별 필드는 reserved되어 있다.

5.12.1 Command Completion

Firmware Image Download Command가 완료되면 컨트롤러는 CQ Entry를 Admin CQ에 게시한다. Firmware Image Download Command 특정 상태 값은 그림 183에 정의되어 있다.

Firmware Image Download Command

Firmware Image는 여러 개로 구성될 수 있으며
부분마다 순서대로 다운로드 할 필요는 없고 서로 겹치면 안된다.
PRP Entry1, PRP Entry 2 [DW6-9][31:00]
Firmware 조각이 있는 PRP Entry / List Pointer
Number of Dwords(NUMD) [DW10][31:00]
다운로드 중인 Firmware Image부분에 포함된 Dwords의 수
Offset(OFST) [DW11][31:00] :
Firmware 조각과 관련된 0(시작)에서 Dword offset
0(시작)에서의 offset은 0h를 가져야 함

Host SW는 부트 파티션을 업데이트 할 때 Firmware Image 부분을 순서에 맞게 전송해야 한다.

※ Firmware Image를 Download했다고 해서 새로운 Firmware Image가 활성화되지는 않는다.

새로운 Firmware Image 활성화 시키는 것은 Firmware Image Commit command의 역할

5.13 Get Features Command

Get Features Command는 지정된 Features의 특성을 검색한다.
Get Features Command는 Data Pointer, 명령 Dword 10 및 명령 Dword 14 필드를 사용한다. 명령 Dword 11 필드의 사용은 기능별이다. 기능별로 사용되지 않으면 특별한 언급이 없는 한 명령 Dword 11이 reserved된다. 다른 모든 명령별 필드는 reserved된다.
컨트롤러가 Get Features command에 의한 UUID의 선택을 지원하고(그림 275 및 섹션 8.24 참조), 컨트롤러가 지정된 vendor feature Identifier에 대한 UUID의 선택을 지원하는 경우(그림 275 참조), Command Dword 14는 UUID Index 값을 지정하는 데 사용된다(그림 186 참조). 컨트롤러가 Get Features command에 의한 UUID의 선택을 지원하지 않거나 컨트롤러가 지정된 vendor feature Identifier에 대한 UUID의 선택을 지원하지 않는 경우, Command Dword 14는 UUID Index 값을 지정하지 않는다.
그림 187은 Get Features command를 사용해 속성을 검색할 수 있는 Feature Identifier를 설명한다. 반환되는 속성 및 관련 형식의 정의는 표시된 섹션에 명시되어 있다.

5.13.1 Select Field

식별자가 지정되었다. Select(선택) 필드가 001b(즉, 기본값)로 설정되면 지정한 Feature Identifier의 기본 속성 값이 반환된다.
Select 필드가 010b로 설정되면(즉, 저장됨) 지정된 Feature Identifier에 대해 마지막으로 저장된 특성 값(즉, Feature Identifier에 대해 저장 비트가 1 로 설정된 상태에서 오류 없이 완료된 마지막 Set Feature command)이 반환된다.
Select(선택) 필드가 011b(즉, 지원되는 기능)로 설정되면 이 Feature Identifier에 지원되는 기능이 반환된다. 지원되는 기능은 Get Feature(기능 가져오기) command의 Completion Entry의 Dword 0에서 반환된다. (그림 188 참조)

5.13.2 Command Completion

Get Features command가 완료되면 컨트롤러는 Admin Complete Queue에 CQ Entry를 게시한다. 만약 Select가 11b 로 설정되어 있지 않다면 CQ Entry의 Dword 0은 특징에 의존적인 정보를 포함할 수 있다(섹션 5.21.1 참조). Select(선택) 필드가 11b 로 설정되어 있는 경우 그림 188은 CQ Entry의 Dword 0의 내용을 설명한다.

Get Features Command

PRP / CQ Entry의 DWord0에서 반환되는 Feature Value!

PRP Entry1 [DW6-7][31:00]
Feature Data를 작성해야 하는 위치의 시작 주소 (일부 features에서 사용됨)
PRP Entry 2 [DW8-9][31:00]
나머지 Feature Data를 작성해야 하는 위치의 시작 주소 (일부 features에서 사용됨)
Feature Identifier(FID) [DW10][07:00] :
데이터를 제공할 Feature ID Number

UUID Index [DW14][06:00] <Select Option> :
컨트롤러가 Get Features command에 대한 UUID 선택을 지원 && 지정된 vendor feature Identifier에 대한 UUID의 선택을 지원
--> UUID Index 값을 지정하는데 사용됨

Select (SEL) [DW10][10:08] :
제공된 데이터에서 반환할 특성 값을 지정한다.
Identify Controller Data Structure의 Optional NVM Command Support필드의 [4]bit에서 이 필드의 지원여부를 표시한다.

Completion Queue Entry DW0 when Select = 11b

Changeable [DW0][2] :
1 : Feature Value 변경 가능
0 : Feature Value 변경 불가능

NS Specific [DW0][1] :
1 : Feature Identifier는 Namespace에 따라 다르며 setting은 개별 Namespace에 적용됨
0 : Feature Identifier는 Namespace에 따라 다르며 setting은 전체 컨트롤러에 적용됨
Saveable [DW0][0] :
1 : Feature 값 저장 가능
0 : Feature 값 저장 불가능

5.14 Get Log Page Command

Get Log Page command는 요청된 Log Page가 들어 있는 데이터 버퍼를 반환한다.
Get Log Page command는 Data Pointer, Command Dword 10, Command Dword 11, Command Dword 12, Command Dword 13 및 Command Dword 14 필드를 사용한다. 다른 모든 command 특정 필드는 reserved 된다.

그림 195 및 그림 196에는 필수 및 옵션 Log Identifier가 정의되어 있다. 지원되지 않는 Log Identifier를 지정하는 Get Log Page command가 처리된 경우, 컨트롤러는 command의 상태가 Invalid Field인 command를 중단해야 한다.

컨트롤러는 Identify Controller 데이터 구조의 Log Page Attributes 필드에 Log Page Offset 및 지정된 Dword 수(12비트가 아닌 32비트)를 지원함을 나타낸다. 확장된 데이터가 지원되지 않는 경우 Number of Dwords Lower 필드의 27:16 비트에서 전송할 Dwords 수를 지정한다.

5.14.1 Log Specific Information

그림 195와 그림 196는 Get Log Page command로 검색할 수 있는 로그 페이지와 해당 로그 페이지에서 반환되는 정보의 범위를 정의한다. 다양한 컨트롤러 유형에 대한 필수, 선택 및 금지 로그 페이지는 섹션 7.1을 참조하십시오.

NVM Subsystem의 범위를 나타내는 Log Page는 NVM Subsystem에 대해 전역적인 정보를 반환한다. 컨트롤러 범위를 나타내는 Log Page는 command를 처리하는 컨트롤러에 고유한 정보를 반환한다. 지정된 namespace에 고유한 namespace 반환 정보의 범위를 나타내는 Log Page이다.

여러 범위를 나타내는 Log Page의 경우 지정된 namespace 식별자가 반환되는 정보를 결정한다. 로그 페이지 내의 임의의 개별 필드의 정의는 해당 개별 필드에 고유한 다른 범위를 나타낼 수 있다.
NVM Subsystem 또는 컨트롤러의 범위가 있는 Log Page(그림 195 및 그림 196에 표시됨)의 경우 컨트롤러는 0h 또는 FFFFFFh 이외의 Namespace Identifier를 지정하는 command를 중단해야 한다. 그렇지 않은 경우에는 그림 106의 namespace Identifier 사용에 대한 규칙이 적용된다.

Get Log Page Command
지정된 Log Page에서 최대 4KB의 데이터를 검색한다.

PRP Entry1 [DW6-7] : Log Page를 쓸 공간의 시작주소
PRP Entry2 [DW6-7] : 4KB Log Page의 데이터 중 남은 부분을 쓸 공간의 시작주소
Number of Dwords Lower (NUMDL)[DW10][27:16] :
전송할 Dword 개수 중 하위 16비트를 지정함
hostSW가 요청한 Log Page보다 큰 크기를 지정하면
그 크기를 넘어간 Dword에 대해 정의되지 않은 결과가 나타날 수 있음
NUMLD NUMDU필드를 결합하여 사용함

Retain Asynchronous Event(RAE) [DW10][15] :
0 : command가 성공적으로 완료된 후 해당 비동기 이벤트가 삭제됨
1 : command가 성공적으로 완료된 후 해당 비동기 이벤트가 유지됨
hostSW는 비동기 이벤트와 함께 사용되지 않는 Log Page의 경우
이 비트를 0으로 수정해야 함
Log Specific Field (LSP) [DW10][11:08] :
LID필드가 정의되지 않은 경우 사용하지 않음
Log Page Identifier (LID) [DW10][07:00] :
추출할 Log Page의 ID
Number of Dwords Upper(NUMDU) [DW11][15:00]
추출할 Dwords 개수의 상위 16비트
Log Page Offset Lower (LPOL) [DW12][31:00]
Log Page내에서 데이터 반환을 시작할 위치를 지정함
Log Page Offset의 하위 32비트를 지정함
Log Page Offset Upper (LPOU) [DW12][31:00]
Log Page Offset의 상위 32비트를 지정함

5.14.1.1 Error Information(Log Identifier 01h)

이 Log Page는 오류로 완료된 command에 대한 확장 오류 정보를 설명하거나 특정 command에 고유하지 않은 오류를 보고하는 데 사용된다. 오류로 완료된 command와 관련된 CQ Entry의 상태 필드에 추가(M) 비트를 1 로 설정하거나 오류 상태 유형의 비동기 이벤트의 일부로 지정하면 확장 오류 정보가 제공된다. 이 로그 페이지는 컨트롤러에 대해 전역적이다.

이 Error Log는 마지막 n개의 오류를 반환할 수 있다. Host SW가 n개의 Error Log 크기의 데이터 전송을 지정하면 가장 최근 n개의 오류에 대한 Error Log가 반환된다. Entry의 순서는 오류가 발생한 시간을 기준으로 하며 가장 최근 오류는 첫 번째 Log Entry로 반환된다.
반환되는 Log Page의 각 Entry는 그림 197에 정의되어 있다. Log Page는 64byte의 Entry들의 집합이며 지원되는 최대 Entry 수는 Identify Controller Data Structure의 ELPE Field에 표시된다(그림 251 참조). 새로운 Entry가 생성될 때 Log Page가 꽉 차면 컨트롤러는 Log에 새로운 Entry를 삽입하고 가장 오래된 Entry는 폐기해야 한다.
컨트롤러는 전원 주기 및 컨트롤러 Level Reset의 모든 Entry를 제거하여 이 Log Page로그 페이지를 지워야 한다.

5.14.1.2 SMART / Health Information(Log Identifier 02h)

이 Log Page는 SMART 및 일반 상태 정보를 제공하는 데 사용된다. 제공된 정보는 컨트롤러의 수명에 걸쳐 있으며 전력 사이클 전반에 걸쳐 유지된다. 컨트롤러 Log Page를 요청하기 위해 지정된 Namespace Identifier는 FFFFFFh 또는 0h이다. 본 명세서의 리비전 1.4 이전 버전과의 호환성을 위해 호스트는 FFFFFFh의 Namespace Identifier를 사용하여 컨트롤러 Log Page를 요청해야 한다. 컨트롤러는 또한 그림 251의 Identify Controller Data Structure에서 LPA Field의 비트 0으로 표시된 것과 같이 Namespace 단위로 Log Page를 요청하는 것을 지원할 수 있다.

Namespace 단위로 Log Page를 지원하지 않는 경우 0h 또는 FFFFFh 이외의 Namespace Identifier를 지정하면 command에 잘못된 필드 상태로 command를 중단해야 한다. 컨트롤러가 command를 중단하지 않으면 이 개정판 및 이 사양의 이전 개정판을 준수하는 구현에서 컨트롤러 Log Page를 반환한다. 이 사양의 개정판에는 SMART / Health Log Page에 정의된 Namespace 특정 정보가 없으므로 컨트롤러 Log Page와 Namespace 특정 로그 페이지에 동일한 정보가 포함된다.

NVM subsystem의 상태에 관한 중대한 경고는 호스트에 대한 비동기 이벤트 통지를 통해 표시될 수 있다. 호스트에 대한 비동기 이벤트 통지를 초래하는 경고는 Set Features command를 사용하여 구성된다. 섹션 5.21.1.11을 참조하십시오.

SMART/Health Information Log의 일부로 반환되는 파라미터를 사용하여 성능을 계산할 수 있다. 구체적으로, Read 또는 Write command의 수, 읽거나 쓴 데이터의 양, 컨트롤러 비지 시간의 양은 초당 I/O 및 대역폭을 모두 계산할 수 있게 한다.
반환되는 Log Page는 그림 198에 정의되어 있습니다.

Get Log Page command – Error Information Log Entry (Log Identifier 01h)

5.14.1.2 SMART / Health Information (Log Identifier 02h)

이 Log Page는 SMART 및 일반 상태 정보를 제공하는 데 사용된다. 제공된 정보는 컨트롤러의 수명에 걸쳐 있으며 power cycle 전반에 걸쳐 유지된다. 컨트롤러 Log Page를 요청하기 위해 지정된 Namespace Identifier는 FFFFFFh 또는 0h이다. 본 명세서의 리비전 1.4 이전 버전과의 호환성을 위해 호스트는 FFFFFFh의 Namespace Identifier를 사용하여 컨트롤러 Log Page를 요청해야 한다.
컨트롤러는 또한 그림 251의 Identify Controller Data Structure에서 LPA Field의 비트 0으로 표시된 것과 같이 Namespace 단위로 Log Page를 요청하는 것을 지원할 수 있다.

Namespace 단위로 Log Page를 지원하지 않는 경우 0h 또는 FFFFFh 이외의 Namespace Identifier를 지정하면 command에 잘못된 필드 상태로 command를 중단해야 한다. 컨트롤러가 command를 중단하지 않으면 이 개정판 및 이 사양의 이전 개정판을 준수하는 구현에서 컨트롤러 Log Page를 반환한다. 이 사양의 개정판에는 SMART / Health Log Page에 정의된 Namespace 특정 정보가 없으므로 컨트롤러 Log Page와 Namespace 특정 로그 페이지에 동일한 정보가 포함된다.

NVM subsystem의 상태에 관한 중대한 경고는 호스트에 대한 비동기 이벤트 통지를 통해 표시될 수 있다. 호스트에 대한 비동기 이벤트 통지를 초래하는 경고는 Set Features command를 사용하여 구성된다. 섹션 5.21.1.11을 참조하십시오.
SMART/Health Information Log의 일부로 반환되는 파라미터를 사용하여 성능을 계산할 수 있다. 구체적으로, Read/Write command의 수, 읽거나 쓴 데이터의 양, 컨트롤러 비지 시간의 양은 초당 I/O 및 대역폭을 모두 계산할 수 있게 한다.
반환되는 Log Page는 그림 198에 정의되어 있습니다.

Get Log Page command - SMART / Health Information Log

5.14.1.3 Firmware Slot Information (Log Identifier 03h)

이 Log Page는 지원되는 각 Firmware Slot에 저장된 Firmware Revision을 설명하는 데 사용된다. Firmware Revision은 ASCII 문자열로 표시된다. Log Page는 또한 활성 슬롯 번호를 나타낸다. 반환되는 Log Page는 그림 200에 정의되어 있다.

Get Log Page command – Firmware Slot Information Log

5.14.1.4 Changed Namespace List (Log Identifier 04h)

이 Log Page는 컨트롤러에 연결된 namespace를 설명하는 데 사용된다:

a) Log Page를 마지막으로 읽은 이후로 Identify Namespace 데이터 구조에서 변경된 정보;
b) 추가됨; 및
c) 삭제되었습니다.

Log Page에는 최대 1,024개의 항목이 포함된 namespace List가 포함된다. Log Page를 마지막으로 읽은 이후 1,024개 이상의 Namespace에서 속성이 변경된 경우 Log Page의 첫 번째 Entry는 FFFFFFh로 설정하고 나머지 Entry는 0으로 채워야 한다.

5.14.1.5 Commands Supported and Effects (Log Identifier 05h)

이 Log Page는 컨트롤러가 지원하는 command 및 해당 command가 NVM subsystem의 상태에 미치는 영향을 설명하는 데 사용된다. Log Page의 크기는 4,096byte이다. Admin command 당 지원되는 command 및 효과 데이터 구조가 하나 있고 I/O command당 지원되는 command 및 Effects data structure가 하나 있다(CC.CSS에서 선택한 I/O command set을 기준으로 함).

지원되는 command 및 Effect Data Structure는 command의 모든 옵션 기능을 포함하여 command의 가능한 전체 효과를 설명한다.
Host SW는 command를 제출하는 방법과 command가 완료된 후 취해야 할 조치를 결정할 때 command 효과를 고려할 수 있다.

command가 host SW가 command가 완료된 후 관련 기능을 다시 열거 및/또는 초기화하는 특정 기능을 변경할 수 있는 경우 권장된다.

예를 들어 namespace 기능 변경이 발생할 수 있는 경우 host SW는 관련 namespace 사용을 일시 중지하고 namespace 기능 변경을 유발할 수 있는 command를 제출하고 완료를 기다린 후 Identify command를 다시 발행하는 것이 좋다.

Namespace가 여러 컨트롤러에 연결되어 있는 경우 해당 컨트롤러와 관련된 host는 command 제출 및 실행 요구사항을 충족하도록 command를 조정해야 한다(그림 202 참조). 이 조정의 세부 사항은 본 명세서의 범위를 벗어납니다.

Get Log Command - Commands Supported and Effects Structure

5.14.1.6 Device Self-Test (Log Identifier 06h)

이 로그 페이지는 다음을 나타내는 데 사용됩니다:

a) 진행 중인 장치 자체 시험 작동 상태 및 해당 작동 완료 비율
b) 지난 20번의 장치 자체 테스트 작업의 결과이다.

최신 self-test result Data Structure Field에 포함된 self-test result Data Structure는 항상 마지막으로 완료되거나 중단된 self-test의 결과이다.

Device Self-test Log의 다음 self-test Result Data Structure Field에는 두 번째 최신 self-test의 결과 등이 포함된다.
20개 미만의 self-test가 완료되거나 중단된 경우 사용되지 않은 self-test Result Data Structure Field에서 Device Self-test Status Field를 Fh로 설정하고 해당 self-test Result Data Structure가 무시된다.

Get Log Page - Device Self-test Log

5.14.1.7 Telemetry Host-Initialted (Log Identifier 07h)

이 로그는 로그를 설명하는 header와 0이상의 telemetry Data Block으로 구성된다(섹션 8.14 참조). 모든 telemetry Data Block의 크기는 512byte이다. 컨트롤러가 이 Log에 대한 Get Log Page command를 Log Specific 필드에 1로 설정된 Create Telemetry Host-Initiated Data Bit로 처리하면 컨트롤러는 이 로그에 대한 컨트롤러의 내부 Controller Status Capture를 시작해야 한다. 호스트가 이 로그에 대한 Get Log Page command에서 512byte의 배수가 아닌 Log Page Offset Lower(Log Page Offset의 하위 32bit)값을 지정하면 컨트롤러는 Invalid Field in Command의 오류를 반환해야 한다.
이 Log Page는 컨트롤러에 대해 global이다.

Command Dword 10 - Log Specific Field

Telemetry Host Initiated Data는

Telemetry Host Initiated Data Area 1
Telemetry Host Initiated Data Area 2
Telemetry Host Initiated Data Area 3
세 가지 영역으로 구성된다.

세 영역 모두 Telemetry Host Initiated Data Area 1에서 시작된다. 각 영역의 마지막 블록은 각각 Telemetry Host Initiated Data Area y Last Block에 표시된다. 캡처된 Telemetry Data와 그 크기는 구현에 따라 달라진다. Log Page의 크기는 가변적이며, Telemetry Host Initiated Data Area 3 Last block Field를 사용하여 계산될 수 있다.

컨트롤러는 요청된 모든 블록에 대해 데이터를 반환해야 한다. Telemetry Host Initiated Data Area 3 Last Block의 Last Block을 넘어서는 데이터는 정의되지 않았다. host가 512byte의 배수가 아닌 데이터 전송을 요청하면 컨트롤러는 command에 잘못된 필드의 오류를 반환해야 한다.

Get Log Page - Telemetry Host-Initiated Log(Log Identifier 07h)

5.14.1.8 Telemetry Controller-Initiated (Log Identifier 08h)

이 로그는 로그를 설명하는 header와 0 이상의 Telemetry Data Blocks(섹션 8.14 참조)로 구성된다. 모든 Telemetry Data Blocks는 512바이트 크기이다. 이 로그는 컨트롤러가 시작하여 컨트롤러 내부 상태를 캡처한다. Telemetry Controller-Initiated Data는 모든 reset에서 지속된다. host가 이 Log에 대해 Get Log Page command에서 512바이트의 배수가 아닌 Log Page Offset Lower 값을 지정하면 컨트롤러는 Invalid Field in Command의 오류를 반환해야 한다. 이 Log Page는 컨트롤러에 대해 global이다.
Telemetry Controller-Initiated Data는

Telemetry Controller-Initiated Data Area 1
Telemetry Controller-Initiated Data Area 2
Telemetry Controller-Initiated Data Area 3
의 세 가지 영역으로 구성된다.

세 영역 모두 Telemetry Controller-Initiated Data Area Block 1에서 시작한다. 각 영역의 Last Block은 Telemetry Controller-Initiated Data Area y Last Block에 각각 표시된다. 캡처된 원격측정 데이터와 그 크기는 구현에 따라 달라진다.
Log Page의 크기는 가변적이며 Telemetry Controller-Initiated Data Area 3 Last Block Field를 사용하여 계산할 수 있다.
컨트롤러는 요청된 모든 블록에 대해 데이터를 반환해야 한다. Telemetry Controller Initiated Data Area 3 Last Block의 Last Block을 넘어서는 데이터는 정의되지 않았다. Host가 512byte의 배수가 아닌 데이터 전송을 요청하면 컨트롤러는 commnad에 잘못된 필드의 오류를 반환해야 한다.

Get Log Page - Telemetry Host-Initiated Log(Log Identifier 08h)

5.14.1.9 Endurance Group Information (Log Identifier 09h)

이 Log Page는 Endurance Group을 기준으로 Endurance Information을 제공하는 데 사용된다(섹션 8.17 참조). Endurance Group은 0 또는 그 이상의 NVM set로 구성된다. 제공되는 정보는 Endurance Group의 수명에 걸쳐 제공된다. Endurance Group Identifier는 Get Log Page command의 command Dword 11의 로그 특정 식별자 필드에 지정됩니다. Log Page의 크기는 512byte이다.

Get Log Page - Endurance Group Log(Log Identifier 09h)

5.14.1.10 Predicatable Latency Per NVM Set (Log Identifier 0Ah)

이 Log Page는 Predictable Latency Mode가 활성화된 경우 지정된 NVM Set에 대한 현재 Window 및 지정된 NVM Set에 대해 발생한 모든 이벤트를 결정하는 데 사용될 수 있다. Predictable Latency Mode가 지원되는 경우 각 NVM Set에는 하나의 Log Page가 있다. Command Dword 11(그림 191 참조)은 Log Page를 반환할 NVM Set을 지정한다. Log Page의 크기는 512byte이다.
Log Page에는 지정된 NVM Set의 Deterministic Window과 Non- Deterministic Window와 관련된 속성에 대한 일반적인 값과 신뢰할 수 있는 estimate가 표시된다. Typical, 최대값 및 최소값은 NVM subsystem의 Lifetime에 걸친 static 및 worst의 경우 값이다.

컨트롤러가 비동기 이벤트 비트 유지를 0으로 지운 상태에서 이 Log Page의 Read를 성공적으로 완료한 후, 보고된 이벤트는 지정된 NVM Set에 대해 0으로 지우고 지정된 NVM Set에 해당하는 필드는 Predictable Latency Event Aggregate Log Page에서 0으로 지운다. 둘 이상의 Host 간의 조정은 이 사양의 범위를 벗어난다.

Get Log Page - Predictable Latency Per NVM Set Log

5.14.1.11 Predictable Latency Event Aggregate Log Page (Log Identifier 0Bh)

이 Log Page는 특정 NVM Set에 대한 Predictable Latency Event(섹션 8.18 참조)가 발생했는지 여부를 나타낸다.

Predictable Latency Event가 발생한 경우 해당 NVM Set에 대한 Predictable Latency Per NVM Set Log Page에 특정 이벤트의 세부 정보가 포함된다. 이 로그 페이지에 NVM Set에 대한 Entry가 새로 추가되면 비동기 이벤트가 발생한다.

NVM Set에 대해 활성화된 Predictable Latency Event가 보류 중인 경우 Predictable Latency Event Aggregate Log Page에는 해당 NVM Set에 대한 Entry가 포함된다. 로그 페이지는 NVM Set Identifier에 의해 순서대로 나열된다.

예를 들어 NVM Set 27, 13 및 17에 대해 Predictable Latency Event가 보류 중인 경우 Log Page에는 숫자 순서가 13, 17 및 27이어야 한다.

Get Log Page가 성공적으로 완료된 후 해당 NVM Set의 Predictable Latency Per NVM Set Log Page에 대해 0으로 삭제된 상태에서 특정 NVM Set이 이 로그 페이지에서 제거된다.

로그 페이지 크기는 Identify Controller Data Structure에 보고된 NVM Set Identifier Maximum 값에 의해 제한된다(그림 251 참조). 호스트가 로그 페이지의 끝을 넘어서면 0이 반환된다. 로그 페이지는 그림 210에 정의되어 있다.

Get Log Page – Predictable Latency Event Aggregate Log Page

5.14.1.12 Asymmetric Namespace Access (Log Identifier 0Ch)

이 로그는 command를 처리하는 컨트롤러에 연결된 namespace를 포함하는 ANA group(섹션 8.20.2 참조)에 대한 asymmetric namespace access 정보를 포함하는 descriptor와 로그를 설명하는 header로 구성된다. ANA Reporting(섹션 8.20 참조)이 지원되는 경우 이 Log Page가 지원된다. ANA group descriptor는 오름차순 ANA group Identifier 순서로 반환된다.

command Dword 10에서 RGO 비트가 0으로 지워지면 command Dword 12의 LPOL 필드와 Get Log Page command의 command Dword 13의 LPOU 필드가 0h로 지워진다.

호스트가 ANA Log Page를 읽기 위해 여러 Get Log Page Command를 수행하는 경우(예: LPOL 필드 또는 LPOU 필드 사용), 호스트는 Log Page의 header를 다시 읽고 asymmetric namespace access log의 변경 횟수 필드가 원래 읽은 값과 일치하는지 확인해야 한다.
일치하지 않으면 캡처된 데이터가 일관되지 않고 ANA log page를 다시 읽어야 한다.

Asymmetric Namespace Access (Log Identifier 0Ch)

ANA group descriptor의 format은 그림 213에 정의되어 있다. namespace Identifier는 NSID 오름차순으로 나열된다.

ANA Group Descriptor Format

5.14.1.13 Presistent Event Log (Log Identifier 0Dh)

Persistent Event Log Page에는 특정 command에 특정하지 않은 중요한 이벤트에 대한 정보가 포함되어 있다. 이 Log Page의 정보는 power cycles 및 resets 전반에 걸쳐 유지되어야 한다. NVM subsystem은 정전 시 이벤트 정보 손실을 최소화하도록 설계되어야 한다. 이 로그는 로그와 0개 이상의 Persistent Events를 설명하는 header로 구성된다(섹션 5.14.1.13.1 참조).

이 Log Page는 NVM subsystem에 대해 global하다.
Sanitize operation은 이 Log Page를 변경할 수 있다 (예: Log Page정보에서 사용자 데이터의 파생을 방지하기 위한 이벤트 제거 또는 수정, 섹션 8.15 참조). Sanitize operation에 의해 이 Log Page에서 제거된 이벤트는 지정되지 않는다.

이 섹션에 명시된 Persistent Event Log Event는 더 최근 이벤트가 이전 이벤트보다 일반적으로 Log Data에서 더 일찍 보고되도록 순서대로 보고되어야 한다.
NVM subsystem이 이벤트가 발생한 순서를 결정하는 방법은 vendor별이다.

지원되는 이벤트 수는 vendor별로 다르다. Persistent Event Log에 대해 지원되는 최대 크기는 Identifier Controller의 PELS Filed에 표시된다. 지원되는 Event 수와 지원되는 최대 크기는 NVM subsystem의 usable life동안 이벤트 수 또는 Persistent Event Log data의 크기가 지원되는 최대 크기에 도달하지 못할 정도로 커야 한다.

컨트롤러는 동일한 이벤트가 이벤트 생성 빈도에 대한 vendor 특정 임계 값을 초과하는 빈도로 발생한다고 컨트롤러가 결정하지 않는 한 각 이벤트 발생 시 지원되는 모든 이벤트를 기록해야 한다.

vendor 특정 임계 값을 초과하는 빈도로 동일한 이벤트가 발생하는 경우 vendor는 동일한 이벤트에 대한 추가 입력을 억제할 수 있다. 컨트롤러는 vendor 특정 이벤트 데이터에서 이벤트가 억제되었는지 여부를 나타낼 수 있다.

다음과 같은 경우, 향후 이벤트를 위한 공간을 확보하기 위해 삭제되는 이벤트(예: 중요 이벤트가 유지될 수 있고 유지되었던 중요 이벤트보다 최신 이벤트가 삭제될 수 있음)는 vendor이다:

a) Persistent Event Log Data의 크기가 지원되는 최대 크기에 도달한다;
b) Evnet 수가 가장 많은 보고 가능한 이벤트 수에 도달한다. 또는
c) Event Category는 해당 카테고리에 대해 가장 많은 보고 가능한 Event 수에 도달한다(예: timestamp 변경의 1,000건 발생에 대한 정보는 내부 데이터 구조에 저장되고 Persistent Event Log의 timestamp Change Event와 1,000건 이상의 timestamp Change Event가 발생함에 따라 보고하기 위해 추출된다).

여러 컨트롤러에 영향을 미치는 이벤트(예: NVM subsystem reset)는 vendor가 선택한 컨트롤러가 한 번 기록하고 다른 컨트롤러는 기록하지 않아야 한다.

Log Specific Field(Log Specific Field)의 Action 필드(그림 214 참조)는 다음을 지정한다:

a) 이 Get Log Page Command를 처리할 때 Persistent Event Log reporting Context가 생성되고 Log Page 데이터가 있는 경우 해당 Log reporting Context와 연관된 Log Page Data에서 읽힌다;
b) Log Page Data는 기존 Log reportin Context와 연관된 LoG Page Data에서 읽는다.
c) Persistent Event Log reporting Context가 있는 경우)가 해제된다.

Persistent Event Report Context는 컨트롤러가 Persistent Event Log Page Data에 포함된 정보를 결정하기 위해 생성하는 vendor이다(예를 들어, Persistent Event Log Report Context는 Persistent Event Log Page Data일 수 있거나 보고할 이벤트에 대한 Pointer Set를 포함할 수 있다.)
컨트롤러는 Persistent Event Report Context를 유지해야 한다:

1) 컨트롤러가 처리할 때까지:

a) Action 필드가 02h(즉, Release Context)로 설정된 Persistent Event Log Page를 요청하는 Get Log Page command;
b) NVM subsystem reset 또는
c) Controller Level reset;
또는
2) vendor 별 특정 시간 동안 Persistent Event Log Page Data를 검색할 수 있을 정도로
Persistent Event log reporting context가 존재하는 동안 발생하는 Persistent Event Log Event는 기존 reporting context서 보고하지 않고 기록해야 한다.
Host는 Persistent Event Log Page Data를 읽은 후 Persistent Event reporting Log Context를 해제하기 위해 action field를 02h로 설정한 상태에서 Get Log Page command를 실행할 것으로 예상된다.

Command Dword 10 – Log Specific Field

Get Log Page - Persistent Event Log(Log Identifier 0Dh)

Persistent Event Format

5.14.1.13.1Persistent Event Log Events

Persistent Event Log의 이벤트에 대한 Event Header의 Event Type Field(섹션 5.14.1.13 참조)에 보고될 수 있는 값은 그림 217에 정의되어 있다.

5.14.1.13.1.1 SMART/Health Log Snapshot Event(Event Type 01h)

Persistent Event Log를 지원하는 NVM subsystem은 SMART/Health Log Snapshot Event를 생성해야 한다:

a) virtualization management가 구현되지 않은 경우 NVM subsystem의 모든 컨트롤러에 대해
b) virtualization management가 구현되면 모든 기본 컨트롤러에 대해, 컨트롤러가 결정한 시간에 24시간마다 한 번 이상 전원을 켭니다.

SMART / Health Log Snapshot Event는 Persistent Event Log Event Header를 설정한다:

a) Event Type Field에서 01h
b) Event Type Revision Field가 01h

SMART/Health Log Snapshot Event(Event Type 01h)

5.14.1.13.1.2 Firmware Commit Event(Event Type 02h)

Firmware Commit command가 완료되면 Persistent Event Log에 Firmware Commit Event를 기록한다.
Firmware Commit Event는 Persistent Event Log Event Format Header를 설정한다:

a) Event Type Field에서 02h
b) Event Type Revision Field가 01h

Firmware Commit Event(Event Type 02h)

5.14.1.13.1.3 Timestamp Change Event (Event Type 03h)

Timestamp change event(그림 220 참조)에는 event header에 보고된 현재 timestamp와 timestamp가 변경된 시간(즉, 이전 timestamp)의 timestamp가 포함된다.
Timestamp Change Event는 Persistent Event Log Event Format Header를 설정한다:

a) Event Type Field에서 03h
b) Event Type Revision Field가 01h

5.14.1.13.1.4 Power-on or Reset Event (Event Type 04h)

Power-on or Reset Event는 NVM subsystem reset(예: 전원 켜기로 인한) 또는 controller level reset이 완료되면 Persistent Event Log에 기록된다.

Power-on or Reset Event는 Power-on or Reset을 유발하는 기타 이벤트로 인한 reset에 대한 정보를 보고하고(섹션 7.3 참조), descriptor는 reset이 발생한 시점의 컨트롤러에 대한 정보를 보고하며(섹션 7.3 참조), descriptor는 컨트롤러 간 timestamp 값 동기화에 사용할 모든 controller에 대한 timestamp 값을 포함한다.

컨트롤러는 Persistent Event Log Event Format Header를 설정해야 한다:

a) Event Type Field에서 04h
b) Event Type Revision Field가 01h

Power-on or Reset Event (Event Type 04h)

Controller Reset Information Descriptor

5.14.1.13.1.5 NVM Subsystem Hardware Error Event (Event Type 05h)

NVM subsystem HW Error Event는 지원되는 NVM subsystem HW Error Event가 감지되면 Persistent Event Log에 기록된다. 지원되는 NVM subsystem HW Error Event는 vendor이다. NVM subsystem HW Error Event는 Persistent Event Log Event Format Header를 설정해야 한다:

Event Type Field에서 05h
Event Type Revision Field를 01h

NVM subsystem이 지원하는 감지된 모든 NVM subsystem HW Error Event는 달리 명시되지 않는 한 기록되어야 한다(예: 재발 빈도(reoccurrence frequency)로 인해 억제됨(섹션 5.14.1.13 참조). 사용할 수 없는 정보(예: 구현되지 않은 PCIe 옵션 기능으로 인해)를 보고하는 NVM subsystem HW Error Event Field는 NVM subsystem HW Error Event 코드 설명에 달리 명시되지 않는 한 0h로 설정되어야 한다.

NVM subsystem HW Error Event Data

NVM Subsystem HW Error Event Codes

Additional HW Error Information for correctable and uncorrectable PCIe Errors

5.14.1.13.1.6 Change Namespace Event(Event Type 06h)

Change Namespace Event(그림 226 참조)는 성공적인 Namespace Management Command에 사용되는 Host 매개변수를 유지한다.

Event에는 Persistent Event Log Event Header와 Change Namespace Event Data가 포함된다.
Change Namespace Event는 Persistent Event Log Event Format Header를 설정한다:

Event Type Field에서 06h
Event Type Revision Field 를 01h

Change Namespace Event(Event Type 06h)

5.14.1.13.1.7 Format NVM Start Event(Event Type 07h)

Format NVM Start Event는 Format NVM Command의 Command 매개 변수를 성공적으로 검증한 후(제5.23절 참조) NVM의 내용을 수정하기 전에 Persistent Event Log에 기록해야 한다.
Format NVM Start Event는 Persistent Event Log Event Format Header를 설정한다:

Event Type Field를 07h
Event Type Revision Field를 01h

Format NVM Start Event(Event Type 07h)

5.14.1.13.1.8 Format NVM Completion Event (Event Type 08h)

Format NVM Completion Event는 Format NVM command가 완료되면 Persistent Event Log에 기록되어 내용을 수정해야 한다.
Format NVM Complete Event는 Persistent Event Log Event Format Header를 설정한다:

Event Type Field에서 08h
Event Type Revision Field가 01h

Format NVM Completion Event (Event Type 08h)

5.14.1.13.1.9 Sanitize Start Event (Event Type 09h)

Sanitize Start Event는 Sanitize Operation을 시작할 때 Persistent Event Log에 기록된다.
Sanitize Start Event는 Persistent Event Log Event Format Header를 설정한다:

Event Type Field에서 09h
Event Type Revision Field가 01h

Sanitize Start Event (Event Type 09h)

5.14.1.13.1.10 Sanitize Completion Event (Event Type 0Ah)

Sanitize Start Event는 Sanitize Operation이 완료될 때 Persistent Event Log에 기록된다.
Sanitize Start Event는 Persistent Event Log Event Format Header를 설정한다:

Event Type Field에서 0Ah
Event Type Revision Field가 01h

Sanitize Completion Event (Event Type 0Ah)

5.14.1.13.1.11 Set Feature Event (Event Type 0Bh)

Set Feature Event는 성공적인 Set Feature Command의 Data를 유지한다. Event는 Persistent Event Log Event Header와 Set Feature Event Data를 포함한다(그림 231 참조).
Set Feature Event는 Persistent Event Log Event Format Header를 설정한다:

Event Type Field를 0Bh
Event Type Revision Field가 01h로 변경한다.

Set Feature Event는 다음 기준을 충족하는 경우 Persistent Event Log에 기록된다:

a) Set Features Command가 성공적으로 완료된다;
b) Set Features Command의 Feature Identifier는 Persistent Event Log에 기록되도록 지원된다.
c) Set Features에서 Function Identifier에 대한 Controller Set이 변경되었다(즉, 동일한 설정이 다시 설정되지 않음).

Set Feature Event는 다음 기준을 충족하는 경우 해당 Set Features Command의 Feature Identifier에 대한 Controller 설정에 변경이 없는 경우 Persistent Event Log에 기록될 수 있다:

a) Set Features Command가 성공적으로 완료된다
b) Set Features Command의 Feature Identifier는 Persistent Event Log에 기록되도록 지원된다.

Set Feature Event Data에 기록된 Command Dwords 및 Memory Buffer는 Set Features 및 Get Features Command에 의해 정의된 Format과 동일한 Format을 사용한다.

Set Feature Event Data Format

5.14.1.13.1.12 Telemetry Log Create Event (Event Type 0Ch)

컨트롤러가 Host-initiated telemetry log(섹션 5.14.1.7 참조) 또는 Controller-initiated telemetry log(섹션 5.14.1.8 참조)가 생성되었다고 판단하는 경우 Telemetry Log Create event가 생성될 수 있다.
Telemetry Log Create event는 Persistent Event Log Event Format Header를 설정한다:

Event Type Field를 0Ch로 설정한다
Event Type Revision Field에서 01h로 변경한다.

Telemetry Log Create Event (Event Type 0Ch)

5.14.1.13.1.13 Thermal Excursion Event (Event Type 0Dh)

Composite Excursion(복합 온도)가 다음보다 낮은 온도에서 전환된 경우 Persistent Event Log에 Thermal Excursion Event가 기록된다:

a) WCTEMP(있는 경우), WCTEMP 이상의 온도(그림 251 참조), 또는 WCTEMP 이상의 온도(있는 경우)
b) CCTEMP(있는 경우, 그림 251 참조)는 CCTEMP 이상의 온도, 있는 경우,
event의 기록으로 인해 이 threshold에 대한 threshold 보고서의 vendor 별 빈도가 초과되지 않는 한.
Composite Excursion(복합 온도)가 온도에서 전환된 경우 Thermal Excursion Event가 Persistent Event Log에 기록될 수 있다:

a)	이는 TMT1보다 작다
	(있는 경우 TMT1보다>= 온도(가벼운 조절이 시작된 경우);

b)	이는 TMT2보다 작다
	(있는 경우 TMT2보다>= 온도, 있는 경우 무거운 조절이 시작된 경우);

c) vendor 고유 온도보다 높은 온도
	(즉, self-throttling이 시작됨)로 인해 열 조절이 발생하는 
	vendor 고유 온도 미만이다;

d) 온도 threshold를 벗어나 모든 온도 threshold 내에 있는 값 
	(즉, 온도가 정상으로 되돌아감);

e) 열 조절이 정지된 온도까지 열 조절이 발생하는 경우, 또는

```
f) 저온 threshold(섹션 5.21.1.4 참조)보다> 저온 임계값 보다<= 온도
```
Event의 기록으로 인해 이 임계 값에 대한 임계 값 보고서의 vendor 빈도가 초과되지 않는 한.
Thermal Excursion Event는 Persistent Event Log Event Format Header를 설정해야 한다;
Event Type Field를 0Dh로 설정한다.
Event Type Revision Field가 01h이다.

Thermal Excursion Event (Event Type 0Dh)

5.14.1.13.1.14 Vendor Specific Event (Event Type DEh)

Vendor Specific Event(그림 234 참조)에는 Vendor Specific Event Descriptor Set가 포함되어 있으며, 이 Set에는 Vendor Specific Event Descriptor가 포함되어 있으며, 이 Event는 Persistent Event Log의 Host에 보고되어야 하며, 다른 Persistent Event Log Event에서는 설명되지 않는다.

Vendor Specific Event Descriptor는 그림 235에 표시된 형식을 따르며 Vendor Specific Event Descriptor의 Vendor Specific Event Data Type Field에 표시된 유형의 Vendor Specific Data를 포함한다.
Get Log Page Command(섹션 5.14 참조)에서 UUID Index가 지정된 경우 컨트롤러는 다음을 반환해야 한다:

a) 지정된 UUID 인덱스에 의해 식별된 vendor에 의해 정의된 vendor 특정 이벤트; 및
b) NVM subsystem 제조업체가 정의한 vendor 별 Event이다.

컨트롤러는 vendor specific Event Format Header를 설정해야 한다:

a) Event Type Field에서 DEh로 이동한다
b) Event Type Revision Field가 01h이다.

Vendor Specific Event (Event Type DEh)

5.14.1.13.1.15 TCG Defined Event (Event Type DFh)

TCG Defined Event는 Persistent Event Log Event Format Header를 설정합니다:

Event Type Field를 DFh로 이동한다.
Event Type Revision Field 및 TCG Defined EventData는 TCG용으로 reserved된다.

5.14.1.14 LBA Status Information (Log Identifier 0Eh)

이 Log Page는 컨트롤러에 연결된 Namespace의 어떤 Logic Block을 읽을 때 더 이상 복구할 수 없는지 Host가 후속 조치를 취할 수 있는 정보를 제공하는 데 사용된다.LBA Status Log Namespace Element가 0개 이상 포함되어 있다(그림 238 참조).

컨트롤러에 연결된 지정된 Namespace에서 잠재적으로 복구할 수 없는 Logic Block을 Controller가 인식하지 못하는 경우 이 Log Page는 해당 Namespace에 대한 LBA Status Log Namespace Element를 반환하지 않는다.

이 Log Page는 컨트롤러에 연결되지 않은 Namespace에 대한 LBA Status Log Namespace Element를 반환하지 않는다.
각 LBA Status Log Namespace Element에는 0개 이상의 LBA Range Descriptor가 포함되어 있다(그림 239 참조).

각 LBA Range Descriptor는 복구할 수 없는 것으로 감지된 LBA Range를 설명하며, Host는 subsequent Get LBA Status Command에서 해당 LBA Status Log Namespace Element의 Recommended Action Type Field(그림 237 참조)에 지정된 메커니즘을 사용하여 검사해야 한다.

Host는 하나 이상의 Get LBA Status Command의 subsequent 발행을 통해 더 이상 복구 가능하지 않을 수 있는 Logic Block들을 식별할 수 있다. 식별되면, Host는 대체 소스로부터 사용자 데이터를 복구하고 Namespace의 원래 Logical block에 해당 데이터를 쓸 수 있다.

사용자 데이터가 성공적으로 기록되면, subsequent reads는 unrecoverable read errors를 야기해서는 안된다
(예를 들어, 사용자 데이터의 물리적 위치를 변경한 write의 결과).

LBA Status Information Alert asynchronous event를 수신하면 Host는 전체 Log Page를 읽을 때까지 Retain asynchronous Event bit가 1로 설정된 Log Identifier 0Eh에 대한 하나 이상의 Get Log Page Command를 보내야 한다.

Event를 지우기 위해 Host는 Retain Asynchronous Event Bit가 0으로 지워진 Log Identifier 0Eh에 대한 Get Log Page Command를 보낸다.

Host는 Host가 Event를 지웠을 때와 비교하여 Get LBA Status Command를 보낼 시기와 Get LBA Status Command로 식별된 LBA를 복구할 시기를 결정한다.
섹션 8.22.1에서는 호스트 implementations 예를 설명한다.

Event를 지우면 LBA Status Information Report Interval가 다시 시작되고 Log Page의 내용이 update된다.

LBA Status Information Log

LBA Status Log Namespace Element

LBA Range Descriptor

주어진 LBA Status Log Namespace Element의 경우 RATYPE(Recommended Action Type 권장 작업 유형) 필드의 값이 10h인 경우 추가로 추적되지 않은 LBA를 생성했을 수 있는 additional component failure가 발생하지 않는 한 host가 0으로 삭제된 상태에서 Log Identifier 0Eh에 대한 Get Log Page Command를 실행하면 컨트롤러가 동일한 LBA Status Log Namespace Element를 보고하지 않는다.

5.14.1.15 Endurance Group Event Aggregate (Log Identifier 0Fh)

이 Log Page는 특정 Endurance Group에 대한 Endurance Group Event(섹션 8.17 참조)가 발생했는지 여부를 나타낸다. Endurance Group Event가 발생한 경우 해당 Endurance Group의 Endurance Group Information Log Page에 해당 Event의 Details가 포함된다. 이 Log Page에 Enduracne Group에 대한 Entry가 새로 추가되면 Async Event가 발생한다.

Endurance Group에 대해 활성화된 Endurance Group Event가 보류 중인 경우 Endurance Group Event Aggregate Log Page에 해당 Endurance Group에 대한 Entry가 포함된다. Log Page는 Endurance Group Identifier에 의해 순서대로 나열된다.

예를 들어 Endurance Group Event가 Endurance Group2, 1, 7에 대해 보류 중인 경우 Log Page에는 숫자 순서가 1, 2, 7이어야 합니다. Get Log Page가 성공적으로 완료된 후 해당 Endurance Group에 대한 Endurance Group Information Log Page의 Async Event Retain Event Bit를 0으로 지운 후 이 Log Page에서 특정 Endurance Group Entry가 제거된다.

Log Page Size는 Identifier Controller Data Structure에 보고된 Endurance Group Identifier Maximum Value(그림 251 참조)에 의해 제한된다. Host가 Log Page의 끝을 넘어서면 0이 반환된다. Log Page는 그림 240에 정의되어 있다.

Get Log Page - Endurance Group Event Aggregate Log Page

5.14.1.16.1 Reservation Notification (Log Identifier 80h)

Reservation Notification Log Page는 Reservation Notification Log Page의 시간 순서 queue에서 하나의 Log Page를 보고한다. 컨트롤러에 연결된 Namespace에서 Mask가 벗겨진 Reservation Notification이 발생할 때마다 새 Reservation Notification Log Page가 생성되고 Reservation Notification Queue 끝에 추가된다.

Get Log Page Command :

Reservation Notification Queue에서 가장 오래된 Log Page에 해당하는 Log Page를 포함하는 Data Buffer(즉, 가장 낮은 Log Page 수 Field를 포함하는 Log Page; wrapping 대한 계정)를 반환한다.
해당 Reservation Notification Log Page를 queue에서 제거한다.

Get Log Command가 실행될 때 사용 가능한 Reservation Notification Log Page Entry가 없는 경우 빈 Log Page(즉, Log Page의 모든 필드가 0h 로 지워짐)가 반환된다.

Queue의 크기 때문에 컨트롤러가 Reservation Notification Log에 Reservation Notification을 저장할 수 없는 경우 해당 Reservation Notification은 손실된다. Reservation Notification이 손실된 경우 컨트롤러는 queue의 마지막 Reservation Notification의 Log Page Count Field를 늘린다(즉, Queue의 마지막 Reservation Notification의 Log Page Count Field에는 가장 최근에 손실된 Reservation Notification과 관련된 값이 포함되어야 함).

Log Page의 Format은 그림 241에 정의되어 있다.

Get Log Page – Reservation Notification Log

Sanitize Status (Log Identifier 81h)

Sanitize Status Log Page는 Sanitize operation time estimate와 최근 Sanitize Operation에 대한 정보를 보고하는 데 사용된다(섹션 8.15 참조).

Get Log Page Command는 그림 242에 정의된 대로 Format이 지정된 Log Page를 포함하는 Data Buffer를 반환한다.

이 Log Page는 power cycle과 reset 과정에서 유지되어야 한다. 이 Log Page에는 CSTS.RDY가 1로 설정될 때마다 유효한 데이터가 포함되어야 한다.

Identify Controller Data Structure의 SANICAP(Sanitize) Field를 0h로 지우지 않으면(즉, Sanitize Command가 지원됨) 이 Log Page가 지원된다.

Identify Controller Data Structure의 Sanitize Capabilities Field를 0h로 지우면 이 Log Page가 reserved된다.

Get Log Page – Sanitize Status Log

5.14.2 Command Completion

Get Log Page Command가 완료되면 컨트롤러는 CQ Entry를 Admin Complete Queue에 게시한다.

Get Log Page – Command Specific Status Values

5.15 Identify Command

5.15.1 Identifiy Command Overview

Identify Command는 NVM subsystem, Controller 또는 Namespace에 대한 정보를 설명하는 Data Buffer를 반환한다. Data Structure Size는 4,096byte이다.

Identify command는 Data Pointer, Command Dword 10, Command Dword 11, Command Dword 14 Field를 사용한다. 다른 모든 command 특정 Field는 reserved 되어 있다.

Controller가 Identify Command에 의해 UUID 선택을 지원하는 경우(섹션 8.24 참조), Command Dword 14를 사용하여 UUID Index 값을 지정한다(그림 247 참조).

반환되는 Data Structure는 그림 248과 같이 Controller 또는 CNS(Namespace Structure) Field를 기준으로 한다. CNS 값을 기준으로 표시된 Data Strucutre에 대해 반환할 List가 적을 경우 List에서 사용되지 않은 부분은 0으로 채워진다.

Controller가 지정된 CNS 값을 지원하지 않을 경우 Controler는 command에 있는 Field가 비활성화됨 상태로 command을 중단해야 한다.

참고: CNS Field는 Revision 1.0에서는 1Bit Field로, Revision 1.1에서는 2Bit Field로 명시되었다. Host SW는 Revision 1.0을 준수하는 Controller에 대해서만 Revision 1.0에서 정의된 CNS 값을 발행해야 한다. Host SW는 Revision 1.1을 준수하는 Controller에 대해서만 Revision 1.1에서 정의된 CNS 값을 발행해야 한다.

다른 CNS 값을 각각 Revision 1.0 또는 1.1을 준수하는 Controller에 발행한 결과는 불확실하다.

Identify Controller data structure와 Identify Namespace data structure는 여러 Identifier를 포함하고 있다.

5.15.2 Identify Data Structures

5.15.2.1 Identify Namespace data structure

Namespace Identifier(NSID) Field가 active NSID를 지정하면 해당 namespace에 대한 Identify namespace Data Structure(그림 249 참조)가 host로 반환된다.

지정된 namespace가 inactive NSID인 경우 Controller는 0으로 채워진 Data Structure를 반환한다.

Controller가 Namespace Management Function(섹션 8.12 참조)을 지원하고 NSID Field가 FFFFFh로 설정되면 Controller는 Controller의 Namespace에 공통되는 기능을 지정하는 Identify Namespace Data Structure를 반환한다.

Controller가 Namespace Management Function을 지원하지 않고 NSID Field가 FFFFFh로 설정되면 Controller는 Invalid Namespace 또는 Format의 Status Code로 command를 중단해야 한다.

Identify - Identify Namespace Data Structrue, NVM Command Set Specific

5.15.2.2 Identify Controller data structure

Identify Controller Data Structure(그림 251 참조)가 Controller에 대해 Host로 반환된다.

그림 252는 각 Power State의 Attribute를 설명하는 Power State Descriptor를 정의한다. Power State Descriptor Field의 사용 방법에 대한 자세한 내용은 전력 관리 섹션 8.4를 참조하십시오.

Identify - Identify Controller Data Structure

Identify - Power State Descriptor Data Structure

5.15.2.3 Active Namespace ID list (CNS 02h)

1,024개의 Namespace ID List는 Command의 Namespace Identifier(NSID) Field에 지정된 값보다 큰 증가하는 순서로 Active NSID를 포함하는 Host에 반환된다. NSID Field가 FFFFFEh 또는 FFFFFh 로 설정된 경우 Controller는 Status Code Invalid Namespace 또는 Format으로 Command를 중단해야 한다.

NSID Field를 0h로 삭제하여 1h의 NSID로 시작하는 Namespace를 포함하는 Namespace List를 검색할 수 있다. 반환되는 Data Structure는 Namespace List이다. (섹션 4.10 참조).

5.15.2.4 Namespace Identifier Descriptor list (CNS 03h)

Active NSID인 경우 Namespace Identifier(NSID) Field에 지정된 Namespace에 대해 Namespace ID Descriptor Structure List(그림 253 참조)가 Host로 반환된다.

NSID Field에 Active NSID가 지정되지 않은 경우 상태 코드는 섹션 6.1.5를 참조하여 반환된다.

Controller는 4,096 byte Identify payload에 맞는 가변 길이의 Namespace ID Descriptor Structure를 얼마든지 반환할 수 있다. Namespace ID Descriptor Structure 뒤에 남은 모든 byte는 0h로 지워져야 하며 Host는 0h의 Namespace ID Descriptor Length(NIDL) 값을 List의 끝으로 해석해야 한다.

Host는 Host가 지원하지 않는 Namespace ID Type의 Namespace ID Descriptor를 무시해야 한다.

Controller는 동일한 NIDT(Namespace Identifier Type)를 가진 여러 Descriptor를 반환할 수 없다. Controller는 Namespace를 식별하는 적어도 하나의 Descriptor를 반환해야 한다.

Identify - Namespace Identification Descriptor

5.15.2.5 NVM Set List (CNS 04h)

그림 254는 NVM Set List를 정의한다. Data Structure는 CDW11.NVMSETID에 표시된 NVM Set Identifier이상의 NVM subsystem에서 지원하는 첫 번째 NVM Set Identifier부터 시작하여 NVM Set Identifier로 정렬된 NVM Set Identifier 순서 List이다. NVM Set List는 그림 254의 NVM Set Attributes Entry를 기반으로 List에 있는 각 NVM Set의 속성을 설명한다.

NVM Set List

NVM Set Attributes Entry

5.15.2.6 Allocated Namespace ID List (CNS 10h)

최대 1,024개의 Namespace ID List가 Identify Command의 Namespace Identifier(NSID) Field에 지정된 값보다 큰 순서대로 할당된 NSID를 포함하는 Host로 반환된다.

NSID Field가 FFFFFEh또는 FFFFFh로 설정되어 있는 경우 Controller는 Status Code로 Invalid Namespace 또는 Format으로 Command를 중단해야 한다.

NSID Field를 0h로 삭제하여 1h의 NSID로 시작하는 Namespace를 포함하는 Namespace List를 검색할 수 있다. 반환되는 Data Structure는 Namespace List이다(섹션 4.10 참조).

5.15.2.7 Identify Namespace data structure for an Allocated Namespace ID (CNS 11h)

Namespace Identify Data Structure(그림 249 참조)가 할당된 NSID인 경우 Namespace Identifier(NSID) Field에 지정된 Namespace에 대해 Host로 반환된다. 지정된 Namespace가 할당되지 않은 NSID인 경우 Controller는 0으로 채워진 데이터 구조를 반환한다.

지정한 Namespace가 비활성 NSID이면 Controller는 비활성 Namespace 또는 Format의 Status Code로 Command를 중단해야 한다.

NSID Field가 FFFFFH로 설정되어 있으면 Controller는 비활성 Namespace 또는 Format의 Status Code로 Command를 중단해야 한다.

5.15.2.8 Namespace Attached Controller list (CNS 12h)

최대 2,047개의 Controller Identifier로 구성된 Controller List(섹션 4.11 참조)가 CDW10.CNTID(Controller Identifier) Field에 지정된 값 이상의 Controller Identifier를 포함하여 반환된다.

List에는 Namespace Identifier에 지정된 Namespace에 연결된 Controller Identifier가 포함되어 있다.

NSID Field가 FFFFFh로 설정되어 있는 경우 Controller는 Command에서 비활성 Field의 Status Code로 Command를 중단해야 한다.

5.15.2.9 Controller list (CNS 13h)

최대 2,047개의 Controller Identifier로 구성된 Controller List(섹션 4.11 참조)가 Controller Identifier(CDW10.CNTID) Field에 지정된 값 이상의 Controller Identifier를 포함하여 반환된다. 이 List는 Namespace(s)에 연결될 수도 있고 연결되지 않을 수도 있는 NVM subsystem의 Controller Identifier를 포함한다.

5.15.2.10 Primary Controller Capabilities data structure (CNS 14h)

기본 Controller Capabilities Structure(그림 256 참조)가 지정된 기본 Controller에 대해 Host로 반환된다.

Identify - Primary Controller Capabilities Structure

5.15.2.11 Secondary Controller Primary list (CNS 15h)

Secondary Controller List, 그림 257 참조)은 이 command를 처리하는 Primary Controller와 연관된 최대 127개의 보조 Controller에 대해 Host로 반환된다.

List에는 Controller Identifier(CDW10.CNTID) Field에 지정된 값 이상의 Controller Identifier에 대한 Entry가 포함된다.

Secondary Controller List

Secondary Controller Entry

5.15.2.12 Namespace Granularity List (CNS 16h)

Controller가 Namespace Granularity를 보고를 지원하는 경우(섹션 8.12.1 참조), Namespace Granularity List(그림 259 참조)은 최대 16개의 Namespace Granularity Descriptor에 대해 Host로 반환된다(그림 260 참조).

Namespace Granularity List (CNS 16h)

Namespace Granularity Descriptor

5.15.2.13 UUID List (CNS 17h)

UUID List의 Format은 그림 261에 정의되어 있다.
각 UUID List Entry는 0h, NVMe Invalid UUID 또는 Valid UUID이다.
Valid UUID는 0이 아니며 NVMe Invalid UUID가 아니다(섹션 8.24 참조).

Controller Data Structure Identify (그림 251 참조)의 Controller 속성(CTRATT) Field에서 Bit 9(UUID List)가 1로 설정된 경우:

UUID List에는 하나 이상의 유효한 UUID가 포함되어야 한다(섹션 8.24 참조);
UUID 1 Field는 0이 아닌 값을 포함해야 한다.
UUID Field가 0h로 지워지면 UUID List가 종료됨을 나타냅니다.

List의 순서는 무엇이든 가능하다.

UUID List

UUID List Entry

5.15.3 Command Completion

Identify command가 완료되면 Controller는 CQ Entry를 Admin CQ에 게시한다.

5.16 Keep Alive command

Keep Alive Command(섹션 5.21.1.15 참조) 및 관련 기능은 Host가 Controller가 작동 중임을 확인하고 Controller가 작동 중임을 확인하는 데 사용된다.

Host와 Controller는 각각 Access 가능하고 Command를 발행하거나 처리할 수 있을 때 작동 중이다.

Controller는 Controller Data Structure Identify(그림 251 참조)의 KAS Field에서 Keep Alive Timer의 Granularity을 나타낸다.

Admin Queue에서 Keep Alive Timeout을 사용하도록 설정한 경우 Keep Alive Timer는 다음과 같은 경우에 다시 시작된다.

Keep Alive Command(섹션 7.12.1 참조)이 처리된다.
TBKAS가 1 로 설정되고 Admin Command 또는 I/O Command가 Keep Alive Timeout Interval 동안 처리되는 경우 Keep Alive Timeout(7.12.2절 참조)이 끝나면.

모든 Command별 필드가 reserved 되어 있다.

5.16.1 Command Completion

Keep Alive Command가 완료되면 Controller는 Command의 상태를 나타내는 CQ Entry를 Admin CQ에 게시해야 한다.

5.17 NVMe-MI Receive command

NVMe-MI 수신 Command에 대한 자세한 내용은 NVM Express 관리 인터페이스 사양을 참조하십시오.

5.18 NVMe-MI Send command

NVMe-MI Send Command에 대한 자세한 내용은 NVM Express 관리 인터페이스 사양을 참조하십시오.

5.19 Namespace Attachment command

Namespace Attachment Command는 Namespace에서 Controller를 연결하고 분리하는 데 사용된다.

연결 및 분리 작업은 모든 Reset Event에서 지속적으로 수행된다.

Namespace Attachment 및 Detach Operation은 보조 Controller를 Offline으로 설정하는 Virtual Management Command에서 지속적으로 수행된다.

Namespace Attachment Command가 지원되는 경우 Namespace Management Command (섹션 5.20 참조)도 지원된다.

Namespace Attachment Command는 Data Pointer 및 Command Dword 10 Field를 사용한다. 다른 모든 Command별 Field는 reserved되어 있다.

Select(선택) Field는 Command의 일부로 사용되는 Data Structure를 결정한다. Data Structure의 크기는 4,096byte이다.

Controller Attach(컨트롤러 부착)와 Controller Detach(컨트롤러 분리)에 사용되는 Data Structure는 Controller List(컨트롤러 목록)이다(섹션 4.11 참조).

Data Structure에는 각각 부착하거나 분리할 Controller가 설명되어 있다.

5.19.1 Command Completion

Command가 완료되면 Controller는 Command의 Status를 나타내는 CQ Entry를 Admin CQ에 게시한다.

Namespace Attachment Command와 관련된 Command 특정 Status 값은 그림 265에 정의되어 있다.

실패의 경우, 첫 번째 Failures Entry의 byte offset이 Error Information Log Entry의 Command Specific Information Field에 보고된다.

Controller는 오류가 발생한 후에 Controller List의 추가 Entry를 처리하지 않는다.

Namespace Attachment – Command Specific Status Values

5.20 Namespace Management Command

Namespace Management Command는 Creation 및 Delete Operation을 포함하여 Namespace를 관리하는데 사용된다(섹션 8.12 참조).

참고: Controller는 이 Operation이 진행되는 동안 I/O Submission Queues에 제출된 Command를 계속 실행한다.

Namespace Management Command가 지원되는 경우 Namespace Attachement Command(세션 5.19 참조)도 지원된다.

HostSW는 Namespace Attachment Command를 사용하여 Controller에 Namespace를 부착하거나 분리한다.

Creation Operation은 Namespace를 Controller에 부착하지 않는다. Deletion Operation의 부작용으로 시스템에 더 이상 Namespace가 없으므로 Namespace는 모든 Controller에서 분리된다.

HostSW는 Namespace 삭제하기 전에 모든 Controller를 Namespace에서 분리하는 것이 좋다.
Namespace가 다른 Controler(즉, Operation을 처리하는 Controller가 아닌 다른 Controller)에 연결되어 있고 해당 Controller에 Namespace 속성 Notice가 활성화되어 있는 경우(그림 291 참조), Deletion Operation이 요청되면 Deletion Operation의 일부로 해당 Controller에서 Namespace Attribute Notice를 발행하여 Namespace 변경을 표시한다.

Creation Operation에 사용되는 Data Structure는 그림 269에 정의되어 있으며 그림 249에 정의된 Namespace Data Structure Indentify과 같은 Format을 가지고 있다.

Creation Operation과 함께 Namespace Management Command를 성공적으로 완료한 후 Namespace는 지정된 속성으로 Format된다.

Host SW가 Creation Operation에서 지정할 수 있는 Field는 그림 266에 정의되어 있다.

Reversed filed는 hostSW에 의해 0h로 정리된다. 삭제 작업을 위해 전송되는 Data Structure는 없다.

Namespace Management – Host SW Specified Fields

Namespace Management Command는 Data Pointer 및 Dword 10 Field를 사용한다. 다른 모든 Command별 Field는 reserved되어 있다.

NSID(Namespace Identifier) Field는 Creation 및 Deletion Operation에 다음과 같이 사용된다:

Create: NSID Field는 이 Operation을 위해 reserved 되어있으며 hostSW는 이 Field를 0h값으로 지운다.
Controller Operation에 사용할 사용 가능한 Namespace Identifier를 선택해야 한다. 또는
Delete: 이 Field는 이 Operation에서 삭제할 이전에 만든 Namespace를 지정한다. FFFFFFh의 값을 지정하면 NVM subsystem의 모든 Namespace가 삭제된다.

FFFFFFh의 값을 지정하고 유효한 Namespace가 0개 있으면 Command가 성공적으로 완료된다.

5.20.1 Command Completion

Command가 완료되면 Controller는 Command에 대한 Status를 나타내는 CQ Entry를 Admin CQ에 게시한다.
Namespace Management Command Specific Status 값은 그림 270에 정의되어 있다.

CQ Entry의 Dword 0은 생성된 Namespace Identifier를 포함한다. CQ Entry의 Dword 0의 정의는 그림 271에 나와 있다.

Namespace Management – Command Specific Status Values

Namespace Management – Completion Queue Entry Dword 0

5.21 Set Features command

Set Features Command는 표시된 Features의 특성을 지정한다.

Set Features Command는 Data Pointer, Command Dword 10 및 Command Dword 14를 사용한다.

Command Dword 11, Command Dword 12, Command Dword 13 및 Command Dword 15 Field의 사용은 Features 고유하다.

Command Dword 11, Command Dword 12, Command Dword 13 또는 Command Dword 15 Field가 사용되지 않으면 Command Dword는 reserved된다.

Controller가 Set Features Command(그림 275 및 섹션 8.24 참조)에 의한 UUID 선택을 지원하고 Controller가 지정된 Vendor 특정 Feature Indentifier(그림 275 참조)에 대한 UUID 선택을 지원하는 경우 Command Dword 14는 UUID Index 값을 지정하는 데 사용된다(그림 274 참조).

Controller가 Set Features Command에 의한 UUID 선택을 지원하지 않거나 Controller가 지정된 Vendor 특정 Feature Identifier에 대한 UUID 선택을 지원하지 않는 경우 Command Dword 14는 UUID Index 값을 지정하지 않는다.

5.21.1 Feature Specific Information

그림 275는 Set Features Command로 구성하고 Get Features Command로 검색할 수 있는 Features를 정의한다. 그림 276은 NVM Command Set에 고유한 Features를 정의한다.

다양한 Controller Type에 대한 필수, 선택 및 금지 Features는 섹션 7.1을 참조하십시오.

일부 Features는 Memory Buffer를 사용하여 Features의 속성을 구성하거나 반환하는 반면, 다른 Features는 Command 또는 CQ Entry에 Dword만 사용한다.

Features가 Power Cycle에 걸쳐 지속되지 않고 Reset되는 경우 해당 Features의 현재 값은 Controller Level Reset의 일부로 해당 Features의 기본 값으로 설정된다.

기본 값 정의, 저장된 값 정의 및 현재 값 정의를 포함한 Features에 대한 자세한 내용은 섹션 7.8을 참조하십시오.

Feature가 변경되면 실행 중인 Command가 있을 수 있다.

Feature가 변경되면 실행을 위해 이미 제출된 Command에 새 Setting이 적용될 수도 있고 적용되지 않을 수도 있다.

Set Feature Command가 성공적으로 완료된 후 SQ에 제출된 모든 Command는 관련 Feature에 대한 새 설정을 활용한다.

Feature 값이 모든 후속 Command에 적용되도록 하려면 Set Feature Command를 실행하기 전에 Host에서 처리 중인 Command가 완료되도록 해야 한다.

Controller가 기능에 대해 변경 가능한 값을 지원하지 않고(예: 기능이 변경 가능하지 않음) 해당 기능에 대한 기능 Setting Command가 처리되면 해당 Command가 다음과 같은 기능 값을 지정한다:

해당 기능의 기존 값과 동일하지 않은 경우, Controller는 변경할 수 없는 기능의 상태 코드를 사용하여 해당 Command를 중단해야 한다.
해당 기능의 기존 값과 같다면 Controller는 다음과 같이 할 수 있다:
- 해당 Command를 성공적으로 완료한다. 또는
- 변경할 수 없는 기능 상태 코드로 해당 Command를 중단한다.

5.21.1.1 Arbitration (Feature Identifier 01h)

이 기능은 Command Arbitration을 제어한다. Command Arbitration에 대한 자세한 내용은 섹션 4.13을 참조하십시오. 속성은 Command Dword 11에 명시되어 있다.

이 기능에 대해 Get Features Command를 제출하면 그림 277에 지정된 속성이 해당 Command에 대한 CQ Entry의 Dword 0에 반환된다.

5.21.1.2 Power Management (Feature Identifier 02h)

이 기능을 사용하면 Host가 Power State를 구성할 수 있다. 속성은 Command Dword 11에 지정되어 있다(그림 278 참조).

이 기능에 대한 Set Features Command가 성공적으로 완료되면 Controller는 지정된 Power State에 있어야 한다. Non-operational Power State로의 전환을 위해 장치는 섹션 8.4.1(예: 이 Command를 완료하는 동안)에 정의된 해당 Non-operational Power State에 대해 표시된 Power를 초과할 수 있다.

Active된 경우 New State에서 Autonomous Power State Transition이 계속 발생한다.

이 기능에 대해 Get Features Command를 제출하면 그림 279에 설명된 속성이 해당 Command에 대한 CQ Entry의 Dword 0에 반환된다.

5.21.1.3 LBA Range Type (Feature Identifier 03h), (Optional)

이 기능은 지정된 Namespace의 일부인 LBA Range의 Type과 속성을 나타낸다. 이 기능에 대한 여러 Set Features Command가 처리되면 가장 최근에 성공한 Command의 정보만 유지된다(즉, 후속 Command는 이전 Command에서 제공한 정보를 대체한다).

Feature Identifier를 03h로 설정하고 NSID Field를 FFFFFFFFh로 설정한 Set Features Command는 Invalid Field in Command State로 중단해야 한다.

LBA Range Type기능은 Command Dword 11을 사용하며 그림 282와 같은 Data Structure에서 Type과 Attribute Information를 지정한다.

Data Structure는 4,096 byte size이며 physical로 연속되어야 한다.

이 기능에 대해 Get Features Command를 제출하면 그림 281에 지정된 속성이 CQ Entry의 Dword 0에 반환되고 그림 282에 지정된 LBA Range Type Data Structure가 해당 Command의 Data Buffer에 반환된다.

LBA Range Type Data Structure의 각 Entry는 그림 282에 정의되어 있다. LBA range Feature은 64byte Entry Set이며, Entry 수는 Command 매개 변수로 표시되고, 최대 Entry 수는 64개이다.

Controller는 이 Data Structure의 Field 중 어느 하나에 대해서도 유효성 검사를 수행할 필요가 없다. LBA Range는 중첩되지 않아야 하며, 임의의 순서로 나열될 수 있다(예: LBA에 의한 순서 지정은 필요 없음).

Controller가 LBA 범위 중첩을 확인하고 Controller가 LBA 범위 중첩을 감지하면, Controller는 중첩 범위 오류를 반환해야 한다.

Get Features Command의 경우, Controller는 LBA Range Type Data Structure의 모든 미사용 Entry를 0으로 선택 취소할 수 있다. Set Features Command의 경우, Controller는 LBA Range Type Data Structure의 모든 미사용 Entry를 무시해야 한다.

Namespace의 Size나 Namespace의 LBA Format이 변경되면 지정된 LBA Range가 NVM에서 예상되는 위치를 나타내지 않을 수 있다. 이러한 변경 후 Host는 의도된 LBA가 지정되었는지 확인해야 한다.

이 기능의 기본값은 Number of LBA Range Field를 0h(즉, 하나의 LBA Range가 있음)로 지우고 LBA Range Type Data Structure를 초기화하여 다음 항목을 포함해야 한다:

Type Field를 0h로 지운다;
Attribute Field를 1h로 설정한다;
LBA Field를 0h로 클리어하는 중;
Namespace의 LBA 수를 나타내도록 설정된 Logical Block 수 Field; 및
GUID Field가 0h 로 지워지거나 Globally Unique Identifier로 설정된다.

5.21.1.4 Temperature Threshold (Feature Identifier 04h)

Controller는 SMART/Health Information Log에 최대 9개의 온도 값을 보고할 수 있다(즉, Composite Temperature and Temperature Sensor 1 ~ Temperature Sensor 8; 그림 198 참조). 구현된 각 Temperature Sensor와 관련된 Temperature Sensor는 Over Temperature Threshold와 Under Temperature Threshold이다.

Temperature가 해당 Over Threshold 이상이거나 낮으면 SMART/Health Information Log(섹션 5.14.1.2 참조)의 Critical Warning Field 중 하나를 1 로 Bit한다. 이는 Asynchronous Event를 유발할 수 있다.

Over Threshold Feature은 Composite Temperature에 대해 구현되어야 한다. Over Threshold Feature와 Temperature Threshold Feature는 Identify Controller data structure에 Non-zero Warning Composite Temperature Threshold(WCTEMP) Field 값이 보고된 경우 Composite Temperature에 대해 구현되어야 한다(그림 251 참조).

Over Temperature Threshold 및 Over Temperature Threshold Feature는 구현된 모든 Temperature Sensor(즉, 0이 아닌 값을 보고하는 모든 Temperature Sensor Field)에 대해 구현되어야 한다.

Composite Temperature(복합 온도)에 대한 Over Temperature Threshold Feature의 기본값은 WCTEMP가 0이 아닌 경우 Controller Identify Data Structure의 WARNING Composite Temperature Threshold(WCTEMP) Field에 있는 값이며, 그렇지 않으면 기본값은 구현에 따라 다르다.

Composite Temperature(복합 온도)에 대한 Under Temperature Threshold Feature의 기본값은 구현에 따라 다르다. 구현된 모든 Temperature Sensor에 대한 Over Temperature Threshold의 기본값은 FFFh이다.

구현된 모든 Temperature Sensor에 대한 Under Temperature Threshold의 기본값은 0h이다.

이 기능에 대해 Get Features Command를 제출하면 Command Dword 11에서 선택한 Temperature Threshold가 해당 Command에 대한 CQ Entry의 Dword 0에서 반환된다.

5.21.1.5 Error Recovery (Feature Identifier 05h)

이 기능은 지정된 Namespace에 대한 Error recovery Attribute를 제어한다. Attribute는 Command Dword 11에 표시된다.

이 기능에 대해 Get Features Command를 제출하면 그림 284에 설명된 Attribute가 해당 Command에 대한 CQ Entry의 Dword 0에 반환된다.

5.21.1.6 Volatile Write Cache (Feature Identifier 06h), (Optional)

이 기능은 Controller의 Volatile Write Cache(있는 경우)를 제어한다. Volatile Write Cache가 있는 경우(그림 251의 VWOCK 필드 참조), 이 기능이 지원되어야 한다.

Attribute는 Command Dword 11에 명시되어 있다.

참고: Controller가 Write Cache에 있는 데이터가 Power Loss시 Volatile Media에 기록되도록 보장할 수 있는 경우 해당 Write Cache는 Non-Violate으로 간주되며 이 기능은 해당 Write Cache에 적용되지 않는다.

이 기능에 대해 Get Features Command를 제출하면 그림 285에 지정된 속성이 해당 Command에 대한 CQ Entry의 Dword 0에 반환된다.

Volatile Write Cache가 없는 경우 Volatile Write Cache Feature Identifier를 지정하는 Set Features Command가 Invalid Field in Command Status로 중단되고, olatile Write Cache Feature Identifier를 지정하는 Get Features Command가 nvalid Field in Command Status로 중단된다.

5.21.1.7 Number of Queues (Feature Identifier 07h)

이 기능은 Host가 Command를 처리하는 Controller에 요청하는 Queue의 수를 나타낸다.

이 기능은 I/O Submission 및/또는 CQ를 생성하기 전에 초기화하는 동안만 실행되어야 한다. I/O Submission 및/또는 I/O CQ을 생성한 후에 이 기능에 대해 Set Features Command가 실행되면 Set Features Command는 Command Sequence Error의 Status Code로 중단된다. Controller는 Reset 사이에 할당된 값을 변경해서는 안 된다. Set Features Command의 경우에는 Command Dword 11에 속성이 지정된다(그림 286 참조). Get Features Command의 경우 Dword 11은 무시된다.

이 Feature에 대해 Set Features 또는 Get Features Command를 제출하면 그림 287에 지정된 속성이 해당 Command에 대한 CQ Entry의 Dword 0에 반환된다.

참고: 할당된 값은 종종 Virtualized Implementations에서 요청된 Queue의 수보다 작거나 클 수 있다.

Controller는 요청된 것만큼 할당할 Queue를 갖지 않을 수도 있다. 대안적으로, Controller는 Queue의 할당 단위(예컨대, power of two)를 가질 수 있고, 그 할당 단위를 만족시키기 위해 Host SW에 더 많은 Queue를 공급할 수도 있다.

5.21.1.8 Interrupt Coalescing (Feature Identifier 08h)

이 기능은 Interrupt Coalescing Settings를 구성한다.

Controller는 Aggregation Time 또는 Aggregation Threshold 조건 중 하나가 충족되면 Interrupt Signal을 보내야 한다.

Aggregation Time 또는 Aggregation Threshold Field 중 하나가 0h로 선택 해제되면 Interrupt가 발생할 수 있다(즉, Interrupt Coalescing이 암묵적으로 비활성화됨).

이 기능은 I/O Queue에만 적용된다. Error가 완료된 Command에 대한 Interrupt는 병합하지 않는 것이 좋다. 설정은 Command Dword 11에 지정되어 있다.

Controller가 이 Vector에 대해 Interrupt들이 이미 처리되고 있음을 검출하면, Controller는 추가 Interrupt들을 지연시킬 수 있다.

구체적으로, CQ Head Doorbell Register가 특정 Interrupt Vector와 연관되어 Update되고 있다면, Controller는 CQ Entry들이 이미 처리되고 있음을 긍정적으로 표시한다.

이 경우에, Aggregate Time 및/또는 Aggregate Threshold는 연관된 Register 기입 시에 Reset/Restart될 수 있다. 이는 Aggregate Time 또는 Aggregate Threshold Aggregate Threshold가 0이 아닌 특정 Workload들 사이에서 Interrupt들이 무기한 지연되는 결과를 초래할 수 있다.

이 기능에 대해 Get Features Command를 제출하면 그림 288에 지정된 속성이 해당 Command에 대한 CQ Entry의 Dword 0에 반환된다.

이 기능은 Controller가 Pin 기반, MSI, Multiple MSI 또는 MSI-X Interrupt용으로 구성되어 있을 때 유효하다.

Interrupt Mode를 변경할 경우 Controller가 이러한 설정을 유지할 필요가 없다. Host가 Interrupt Mode를 변경한 후에 이 기능을 다시 실행하는 것이 좋다.

5.21.1.9 Interrupt Vector Configuration (Feature Identifier 09h)

이 기능은 특정 Interrupt Vector에 특정한 설정을 구성한다. Settings은 Command Dword 11에 지정되어 있다.

기본적으로, Coalescing Settings(통합 설정)은 각 Interrupt Vector에 대해 활성화된다. Admin CQ에는 Interrupt Coalescing이 지원되지 않는다.

이 기능에 대해 Get Features를 제출하면 그림 289에 지정된 속성이 Command Dword 11에 지정된 Interrupt Vector에 대한 CQ Entry의 Dword 0에 반환된다.

이 기능을 지정하는 Set Features Command를 실행하기 전에 Host는 지정된 Interrupt Vector를 I/O CQ로 구성해야 한다(섹션 5.3 참조).

지정된 Interrupt Vector가 유효하지 않거나 기존 I/O CQ와 연관되지 않은 경우(그림 153 참조), Controller는 Invalid Field in Command의 Error를 반환해야 한다.

5.21.1.10 Write Atomicity Normal (Feature Identifier 0Ah)

이 기능은 AWUN 및 NAWUN 매개변수의 Operation을 controll한다(섹션 6.4 참조). 속성은 Command Dword 11에 지정되어 있다.

이 기능에 대해 Get Features Command를 제출하면 그림 290에 지정된 속성이 해당 Command에 대한 CQ Entry의 Dword 0에 반환된다.

5.21.1.11 Asynchronous Event Configuration (Feature Identifier 0Bh)

이 기능은 Host에 대한 Asynchronous Event Notification을 trigger하는 Event를 제어한다.

이 기능은 Persistent Condition의 경우 Event Report를 enable하는 데 사용될 수 있다(섹션 5.2 참조).

해당 Notification이 활성화되었을 때 Event의 조건이 true이면 Event가 Host로 전송된다. 이 속성은 Command Dword 11에 지정되어 있다.

이 기능에 대해 Get Features Command를 제출하면 그림 291에 지정된 속성이 해당 Command에 대한 CQ Entry의 Dword 0에 반환된다.

5.21.1.12 Autonomous Power State Transition (Feature Identifier 0Ch), (Optional)

이 기능은 8.4.2절을 참조하여 Autonomous Power State Transition에 대한 설정을 구성한다.
Autonomous Power State Transition은 Command Dword 11을 사용하고, 그림 292에 표시된 Data Structure와 그림 293에 정의된 Entry 중 32개로 구성된 Autonomous Power State Transition Data Structure에서 Attribute Information을 지정한다.
이 기능에 대해 Get Features Command가 실행되면 그림 292에 지정된 속성이 CQ Entry의 Dword 0에 반환되고 Entry Structure가 그림 293에 정의된 Autonomous Power State Transition Data Structure가 해당 Command의 Data Buffer에 반환된다.

Autonomous Power State Transition Data Structure의 각 Entry는 그림 293에 정의되어 있다. 각 Entry는 64bit size이다. allowable 32개의 Power State 각각에 대한 Entry가 있다.

지원되지 않는 Power State의 경우, 사용되지 않은 Autonomous Power State Transition Data Structure Entry는 모두 0으로 clear된다.

Entry는 Power State 0으로 시작하여 순차적으로 증가한다(즉, Power State 0은 byte 7:0, Power State 1은 byte 15:8 등으로 기술된다). Data Structure는 256 byte크기이며 물리적으로 연속적이어야 한다.

업로드중..

Autonomous Power State Transition 기능은 Non-Operational Power State Config 기능과 상호 작용할 수 있다(섹션 5.21.1.17 참조). 그림 294는 이러한 상호 작용을 보여준다.

5.21.1.13 Host Memory Buffer (Feature Identifier 0Dh), (Optional)

이 기능은 Host Memory Buffer를 제어한다. Attribute는 Command Dword 11, Command Dword 12, Command Dword 13, Command Dword 14, Command Dword 15에 지정되어 있다.

Host Memory Buffer Feature는 Host가 Host Memory의 일부를 Controller 전용으로 할당하는 메커니즘을 제공한다.

Host Memory Buffer를 사용하도록 설정하는 기능 설정 Command를 성공적으로 완료한 후에는 Host가 다음에 쓸 수 없다:

a) Host Memory Descriptor List(그림 300 참조); 및
b) 연관된 Host Memory Region
(즉, Host Memory Descriptor List에 의해 설명되는 Memory Region)
Host Memory Buffer가 비활성화될 때까지.
Host Memory Buffer가 활성화된 경우 
Host Memory Buffer를 활성화하기 위한 기능 설정 Command
(즉, 1 로 설정된 EHM Bit(그림 295 참조)이
Command Sequence Error의 Status Code와 함께 중단된다.

Host Memory Buffer가 활성화되지 않은 경우 Host Memory Buffer를 비활성화하는 기능 설정 Command(즉, EHM Bit(그림 295 참조)이 아무런 조치 없이 성공한다.

Host Memory Buffer를 비활성화하는 Set Features Command를 성공적으로 완료한 후, Controller는 Host Memory Buffer가 활성화될 때까지 Host Memory Buffer의 어떤 데이터도 access해서는 안 된다.

Controller는 Host Memory Buffer를 비활성화하는 Set Features Command에 대한 CQ Entry를 게시하기 전에 사용 중인 Host Memory Buffer에서 필요한 데이터를 검색해야 한다.

Host Memory Buffer를 비활성화하는 Set Features Command에 대한 CQ Entry를 게시하면 Host SW가 Host Memory Buffer 내용을 수정해도 안전하다는 것을 알 수 있다. 섹션 8.9를 참조하십시오.

hyejinkwon

이전 포스트