管理命令集与操作 - 第158页
我们现在来逐段深入分析 NVMe 2.0b 基础规范第 147 页的内容，特别是两条重要 Admin 命令：
- Abort 命令
- Asynchronous Event Request（异步事件请求）命令
📌 第一部分：Abort 命令（中止命令）
📘 描述：
Abort 命令用于中止（取消）控制器中已经提交但尚未完成的命令。
🧩 Command Dword 10 结构（见 Figure 140）：
| Bit 区间 | 字段名 | 含义 |
|---|---|---|
| 31:16 | Command Identifier (CID) |
要被中止的命令的 ID，即原命令 CDW0 中的 CID。 |
| 15:00 | Submission Queue Identifier (SQID) |
要中止的命令所处的 Submission Queue 的 ID。 |
📝 CID + SQID 联合定位 了哪个命令要被中止。
🔁 命令完成时的行为：
- 控制器完成 Abort 命令后，会向 Admin Completion Queue 提交一个 CQE（完成队列项），告诉主机 Abort 命令执行得如何。
- 关键：Dword 0 的 Bit 0 表示中止是否成功：
| Dword 0 Bit 0 | 说明 |
|---|---|
| 0 | 表示目标命令成功被中止。控制器会先给被中止的命令提交一个 CQE（状态码：Command Abort Requested），然后才给 Abort 命令提交 CQE。 |
| 1 | 表示未能中止该命令。Abort 命令本身仍会完成，但目标命令仍继续执行。 |
🚫 错误状态码（Figure 141）：
| 值 | 含义 |
|---|---|
| 3h | Abort Command Limit Exceeded：并发中止命令数超过了控制器在 Identify Controller 数据结构中所定义的最大值。 |
📌 第二部分：Asynchronous Event Request 命令（异步事件请求）
📘 描述：
该命令用于注册监听控制器主动上报的事件（如健康状态变化、错误、告警等），相当于在 NVMe 层面实现了一种 事件驱动机制。
🔔 使用方式：
- 主机向控制器提交该命令后，控制器不会立即响应，而是在有事件发生时才完成该命令并在 Completion Queue 中填入事件信息。
- 该命令 没有超时 —— 控制器在“事件发生”前会一直挂起该命令。
🔄 Reset 情况下的处理：
如果控制器发生重置（Reset）时仍有未完成的 Asynchronous Event Request 命令，这些命令 不会产生 CQE，而是直接被中止。
🧩 Completion Queue Entry 中的信息：
- Dword 0 的 Asynchronous Event Type 字段 指明了事件的类型（例如：SMART 警告、电源状态变更等）。
- 某一类型的事件被报告一次后，控制器会自动屏蔽该类型的后续事件，直到主机明确“清除”该事件状态。
✅ 清除事件的方式：
- 通过读取对应的 Log Page 来清除（使用 Get Log Page 命令）。
- 如果读取失败（如介质未就绪，返回 Admin Command Media Not Ready），控制器不会认为事件已被清除，事件类型依然被屏蔽。
⛓️ 多命令支持：
- 主机可以提交多个 Asynchronous Event Request 命令，从而 降低事件上报延迟。
- 同时存在的 Asynchronous Event Request 命令数量受限于
Identify Controller数据结构中的Asynchronous Event Request Limit字段（见 Figure 275）。
📌 总结对比表：
| 命令 | 功能 | 关键字段 | 是否立即完成 | 特殊处理 | 清除方式 |
|---|---|---|---|---|---|
| Abort | 取消一个已提交的命令 | CID + SQID | 是（立即完成，返回是否成功） | 会优先返回被中止命令的CQE | 无需清除 |
| Async Event | 等待控制器主动上报事件 | 无命令特定字段 | 否（挂起直到事件发生） | 控制器自动屏蔽事件类型 | 通过 Get Log Page 清除 |
如果你想看这两个命令在 NVMe-MI 里的实现（如 over MCTP 的格式、AE 触发时机、Log Page 的结构等），我也可以进一步说明 NVMe-MI 与 NVMe base spec 的关联部分。
还需要深入某个命令字段或带上实际的例子说明吗？