NVMe · Q1–328

NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4

Q54–Q68

Get Features and Set Features

Establish scope, changeability and saveability before Set. Completion, Current readback, actual behavior and restoration after reset are separate observations; a successful CQE does not replace them.

CQE: Completion Queue Entry

Each question is followed by its explanation. Start with the volume overview, then follow the field interpretations, comparisons or processes. Essential conditions and the normal path are visible from the start. All numerical examples are hypothetical. Status is written SCT/SC; h indicates hexadecimal.

SCT: Status Code Type

Current and Saved follow different update paths

SV=0 changes the present value; SV=1 requests saving. Restoration additionally depends on scope, saveability and feature exceptions.

Action	Current	Saved / subsequent restoration
Start with a saveable feature	A	Saved=A
Successful Set B, SV=0	B	Remains A
A reset restoring Saved	Returns to A	A
Successful Set C, SV=1	C	Updates to C
Same reset again	Returns to C	C

Worked interpretation: This table assumes a saveable feature and a reset that restores Saved. It is not universal: FID 84h is unsaveable with no Default, yet basic WPS1 survives power cycling and WPS2 clears on a power cycle.

FID: Feature Identifier

Sources: Base 2.4 §4.4 · Base 2.4 §5.2.12 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.30.1.38, 8.1.18

Review the terminology when needed

Controller / namespace: A controller receives commands and manages access. A namespace is a logical storage space that commands can address. An NVM subsystem contains controllers and nonvolatile storage resources.
SQ / CQ / SQE / CQE: Submission and Completion Queues carry command entries (SQEs) and completion entries (CQEs). QID identifies a queue, CID distinguishes outstanding commands in one SQ, and NSID identifies a namespace.
Register / Identify / Feature / Log: A register exposes control or state. Identify queries capabilities and attributes; features query or configure operation; log pages report specific state or records. FID, LID, CNS and CSI select features, logs, Identify structures and command sets.
index / offset / zero-based: An index selects an entry, usually starting at 0; an offset measures distance from an origin in specified units. A zero-based count encodes count−1, but not every zero-valued field is a count. A Dword is 4 bytes; a byte is 8 bits.
Scope / reset / retention: Scope names the affected objects; retention means preserving state. Controller Reset (clearing CC.EN) is one form of Controller Level Reset, or CLR. Different CLR triggers can retain different registers.

Questions in this volume

Q54 · What do Current, Default, Saved and Supported Capabilities mean?
Q55 · How does Set Features.Save affect values after reset and power cycling?
Q56 · Which errors apply to unsupported features, invalid values and unsupported Save?
Q57 · How does the host determine whether a feature requires NSID?
Q58 · How are Arbitration, Number of Queues and I/O Command Set Profile configured and checked?
Q59 · How are interrupt coalescing and vector configuration set and verified?
Q60 · What do Volatile Write Cache and Write Atomicity Normal control?
Q61 · How does Asynchronous Event Configuration select reported events?
Q62 · How do Power Management, APST and Host Controlled Thermal Management differ?
Q63 · How are Timestamp, Keep Alive Timer and Host Memory Buffer configured and verified?
Q64 · What do Host Behavior Support, Error Recovery and Read Recovery Level do?
Q65 · How is namespace write protection configured, and which modes survive reset or power cycling?
Q66 · Why read Get Features after a successful Set Features?
Q67 · How should features change after activation, namespace deletion, reset and power cycling?
Q68 · How should supported-feature claims be checked when Get, Set and behavior appear inconsistent?

Q54 What do Current, Default, Saved and Supported Capabilities mean?

Task: establish Volatile Write Cache feature availability, saveability and current enable state. Follow the support, saveability and current-setting queries with their response formats.

Follow the explanation

Separate the active value, manufacturing default, saved value and change/save capabilities; these are not four identical settings.

1. What differs

Compare the same FID, scope and selectors; Current can differ across namespaces.

SEL 0/1/2/3 select Current/Default/Saved/Supported Capabilities. With SEL 3, DW0 bits 2/1/0 are CHANG/NSSPEC/SVBL, not operational values.

2. How to choose and verify

Separate FID availability from its settings capabilities. LID 12h FSUPP reports availability; Identify.ONCS.SSFS advertises Save/Select, under which Get Features.SEL 3 returns CHANG/NSSPEC/SVBL. SEL 3 DW0 bit 0 is SVBL, not FSUPP.

LID: Log Page Identifier

Worked lookup: FSUPP, SVBL and Current.WCE

Assume CC.CSS=000b, UUID Index 0, MLPS=1, SSFS=1 and VWC.VWCP=1. The example performs queries only and does not change the cache.

Step and source location	Information to retrieve	What this establishes
1 · Figure 200, printed 211/PDF 237	Volatile Write Cache uses FID 06h; MLPS=1 also guarantees LID 12h.	Identifies the feature and discovery log. Cache presence does not establish current enablement.
2 · Figures 270–271, printed 276–278/PDF 302–304	Read 1024 bytes of LID 12h (NUMD=255); FID 06h is at byte 4×6=24=18h. Assume its FSUPP bit 0 is 1.	FID 06h is advertised; saveability and current WCE are still unknown.
3 · Figures 198/201, printed 210,212/PDF 236,238	Get Features opcode 0Ah, FID 06h, SEL 3 and NSID 0 returns successful CQE DW0=00000005h.	Bits 2/1/0 give CHANG=1/NSSPEC=0/SVBL=1: changeable and saveable. Five is a capability bitmap, not the cache setting.
4 · Figure 471, printed 464–465/PDF 490–491	Query the same FID with SEL 0. Assume DW0=0; the VWC format decodes bit 0 as WCE=0.	The feature is supported and saveable while caching is currently disabled. Current 0 is not lack of support and need not equal the SEL 3 bitmap 5.

LID: Log Page Identifier
NSID: Namespace Identifier

Three different bit 0 definitions are involved: FSUPP in LID 12h, SVBL in SEL 3 CQE and WCE in this FID’s SEL 0 CQE. Preserve LID/FID, SEL and response format with the numeric value.

Sources: Base 2.4 §5.2.13.1.18 · Base 2.4 §5.2.12 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.30.1.4

Read capabilities and Current first, then Saved/Default for reset analysis. If unsaveable or never saved, SEL 2 returns Default, subject to features that define no Default.

SEL 3 DW0=5 reports CHANG=1, SVBL=1 and NSSPEC=0: changeable and saveable. NSSPEC=0 does not indicate scope; consult FSP or the FID definition rather than assuming controller scope. Five is not the Current operating value.

3. Conditions that shape the comparison

Unsupported FID uses Invalid Field (0/02h); SEL 4–7 are reserved. Without Select support, do not treat a response as valid CHANG/SVBL discovery.

Preserve FID and SEL with the returned DW0 to distinguish a value from a capability bitmap.

Sources: Base 2.4 §4.4 · Base 2.4 §5.2.12 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.18 · Base 2.4 §5.2.30.1.4

Source locations for this question

Back to questions

Q55 How does Set Features.Save affect values after reset and power cycling?

Follow the explanation

Let the host change only the active value or also the persistent value used on restoration.

1. Identify the trigger and affected objects

Saving follows feature scope; namespace-scoped and controller-scoped settings are not one global value.

Check ONCS.SSFS and the FID's SVBL. Controller Save support does not make every feature saveable.

2. State changes and recovery

SV=0 changes Current without updating Saved; successful SV=1 updates both. Default does not become the host's chosen value.

Discover support, Set and await completion, then read Current/Saved separately. After the chosen reset, verify Current under scope and exception rules.

With Saved=A and an SV=0 change to B, Current becomes B; a reset that restores Saved returns it to A, not B.

3. Verify retention and recovery

SV=1 for an unsaveable feature shall return Feature Identifier Not Saveable (1/0Dh), not silently succeed and lose the saved setting.

Save success, active application and restoration are three separate checks. Current=B does not establish Saved=B.

First inspect original SV/SVBL, then reset type and coverage.

Sources: Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.12 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §5.2.13.1.18

Source locations for this question

Back to questions

Q56 Which errors apply to unsupported features, invalid values and unsupported Save?

Follow the explanation

Distinguish unsupported function, unchangeability, unsaveability and invalid value; their causes and corrections differ.

1. Distinguish the failure conditions

Evaluate the FID, target scope, current state and this Get/Set operation, not merely the controller model.

Check FID, SV, NSID, CDW11 and payload. Some features require selectors beyond a single value.

NSID: Namespace Identifier

Unsupported FID/invalid defined value:0/02h; unsaveable:1/0Dh; unchangeable:1/0Eh; controller-scoped Set with a valid NSID:1/0Fh. Specific FID ordering/state errors take precedence.

2. Establish the cause from evidence

SEL 3 capabilities require SSFS. CHANG=1 means some values are changeable, not that a current permanent state can be reversed.

Establish a valid baseline, then separately test unsupported FID, bad values, SV=1 and wrong scope.

3. Outcome and follow-up checks

Successful Set establishes completion. Setting an unchangeable feature to its existing value may succeed or return Feature Not Changeable; both are permitted.

Re-read after failure according to the feature's error rules; an error is not a universal proof of no side effects.

First exclude multiple simultaneous faults that allow different valid error choices.

Sources: Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.12 · Base 2.4 §4.2.3 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §5.2.13.1.18

Source locations for this question

Back to questions

Q57 How does the host determine whether a feature requires NSID?

Follow the explanation

Select the correct target before changing configuration.

1. Select the target and information

Feature scope can be controller, namespace, subsystem, set, group or another management entity, not just two categories.

SEL 3.NSSPEC=1 indicates namespace scope. With zero, inspect the feature-effects scope and Figure 466/NVM Figure 92.

Controller-scoped Get/Set accepts NSID 0 or FFFFFFFFh. A valid namespace ID on Get can return the controller value, whereas Set must report the scope error.

2. Query sequence and interpretation

Determine scope, then NSID and other selectors. Namespace scope normally uses an active NSID; broadcast Get/Set differ and multi-domain restrictions apply.

FID 05h Error Recovery is namespace-scoped and FID 01h Arbitration controller-scoped; numeric CDW11 values do not make their NSID rules interchangeable.

3. Handle missing or inconsistent evidence

Controller-scoped Set with a valid NSID returns 1/0Fh. Namespace-scoped Get with FFFFFFFFh generally returns 0/0Bh, subject to specific exceptions.

NSSPEC=0 can coexist with subsystem/set scope; it does not universally mean one controller value for all namespaces.

First read the scope definition and original NSID before suspecting namespace failure.

Sources: Base 2.4 §4.4 · Base 2.4 §5.2.12 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · NVM Command Set 1.3 §4.1.3.1–4.1.3.7 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §5.2.13.1.18

Source locations for this question

Back to questions

Q58 How are Arbitration, Number of Queues and I/O Command Set Profile configured and checked?

Follow the explanation

These control scheduling parameters, queue allocations and allowed command-set combinations at different initialization stages.

1. Prepare the operation

All three target controller configuration, while Profile affects namespace/command-set usability.

Arbitration uses CAP.AMS/CC.AMS; queue allocation uses successful Set results; Profile requires CAP.CSS.IOCSS and CNS 1Ch vectors.

CNS: Controller or Namespace Structure, selecting Identify data

FID 01h uses AB/HPW/MPW/LPW; FID 07h maps requested to allocated SQ/CQ counts; FID 19h.IOCSCI is a combination index.

SQ: Submission Queue
CQ: Completion Queue

2. Sequence and completion conditions

Select the profile and discover namespaces, allocate queues and create CQs/SQs; verify arbitration parameters together with CC.AMS/QPRIO.

Read back the same FID/selectors. With CC.CSS other than 110b, Set FID 19h succeeds without effect; with 110b, the selected combination applies. Profile index 0 selects combination 0, not no command sets. FID 07h allocation is not instantiated queue count.

3. Handle unmet conditions

Setting FID 07h after queue creation returns 0/0Ch. With CC.CSS=110b, FID 19h shall return Combination Rejected if IOCSCI selects a zero-valued combination or an attached namespace uses an I/O command set absent from that combination. The supplied spec conflicts: Figure 104 lists Combination Rejected as 1/2Bh, Figure 554 as 1/15h. Preserve that discrepancy rather than declaring noncompliance from either table alone.

Verify settings, creatable queue ranges and usable command sets independently.

Sources: Base 2.4 §5.2.30.1.1 · Base 2.4 §5.2.30.1.5 · Base 2.4 §5.2.30.1.18 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.30 (Command Completion) · Base 2.4 §4.2.3 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.18

Source locations for this question

Back to questions

Q59 How are interrupt coalescing and vector configuration set and verified?

Follow the explanation

Trade notification latency against interrupt overhead; posting a completion and generating an IRQ are different events.

1. Prepare the operation

FID 08h controls I/O interrupt coalescing; FID 09h selects its application per vector. Admin CQ does not support coalescing.

CQ: Completion Queue

Check CQ.IEN/IV, PCIe interrupt mode and masks. Feature support is required, while aggregation algorithms remain implementation-specific.

FID 08h TIME uses 100 μs units and THR is zero-based; either zero implicitly disables coalescing. FID 09h uses IV/CD; CD=1 disables coalescing, not interrupts.

2. Sequence and completion conditions

Associate a valid vector with a CQ before Set FID 09h. Set/read FID 08h and observe CQE timing alongside interrupts.

Settings can complete successfully without defining exact IRQ timing for every workload. PCIe makes parameter use implementation-specific and permits no coalescing implementation.

3. Handle unmet conditions

Invalid or unassociated IV in FID 09h should return Invalid Field (0/02h), unlike Create CQ's Invalid Interrupt Vector (1/08h).

Check readback, CQ mapping, masks and notification behavior. CD=1 does not override an MSI-X mask.

MSI-X: Message Signaled Interrupts Extension

Sources: Base 2.4 §5.2.30.2.1–5.2.30.2.2 · PCIe Transport 1.4 §3.5 · Base 2.4 §5.3.1–5.3.2 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.18

Source locations for this question

Back to questions

Q60 What do Volatile Write Cache and Write Atomicity Normal control?

Follow the explanation

Separate persistence from atomicity: reaching nonvolatile storage is different from updating logical blocks as a defined unit.

1. What differs

FID 06h controls controller volatile caching; FID 0Ah controls normal atomicity requirements, not the advertised namespace atomic units.

With FID 06h.WCE=0, written user data must be persistent. FID 0Ah.DN=1 removes AWUN/NAWUN requirements while retaining AWUPF/NAWUPF.

2. How to choose and verify

VWC advertises cache presence; AWUN/AWUPF, namespace overrides and boundaries describe atomicity.

Read capabilities/format, Set/Get, then compare allowed outcomes for Writes respecting units/boundaries. Drain first for a clean setting transition.

WCE=0 does not make arbitrary-size writes atomic; DN=1 does not make completion persistent. The controls are not substitutes.

3. Conditions that shape the comparison

Get/Set FID 06h without volatile cache shall return Invalid Field (0/02h). Other conditions follow applicable command/namespace/atomicity rules.

Correlate Current.WCE/DN with the effective atomic units. FUA requests persistence for a command without enlarging its atomic unit.

Sources: Base 2.4 §5.2.30.1.4 · NVM Command Set 1.3 §4.1.3.1–4.1.3.7 · NVM Command Set 1.3 §2.1.2–2.1.4 · NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.18

Source locations for this question

Back to questions

Q61 How does Asynchronous Event Configuration select reported events?

Follow the explanation

Select desired change notifications; configuration does not submit an event request on the host's behalf.

1. Prepare the operation

FID 0Bh configures controller notifications about state with various scopes.

OAES advertises optional event support, with applicable health capabilities and NVM-specific bit definitions.

CDW11 enable bits select notifications. AER completion AET/AEI/LID describes the event; it is not the same bitmap.

2. Sequence and completion conditions

Discover support, Set the mask, post AER, observe a condition, read the event/log, acknowledge under its rules and replenish requests.

A condition already true when enabled is also reported under this feature's rules; reporting is not limited to later state changes.

3. Handle unmet conditions

Enabling an unsupported event shall return Invalid Field (0/02h). No outstanding AER can delay notification without being a Set Features error.

Correlate OAES, Current mask, pending requests and event masking. An enabled bit alone does not guarantee immediate delivery.

4. Asynchronous Event notification conditions

This feature configures notifications, with event-specific conditions and clearing rules. FID 0Bh is not a universal switch for every Error event, and Get Features does not replenish AERs.

Sources: Base 2.4 §5.2.30.1.6 · Base 2.4 §5.2.2 · Base 2.4 §5.2.14.2.1 · NVM Command Set 1.3 §4.1.3.1–4.1.3.7 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.18

Source locations for this question

Back to questions

Q62 How do Power Management, APST and Host Controlled Thermal Management differ?

APST: Autonomous Power State Transition

Follow the explanation

Separate explicit host power-state selection, idle-driven automatic transitions and temperature-driven power/performance management.

1. What differs

Configuration targets a controller, while shared-domain controllers can interact in power behavior.

FID 02h selects PS and related limits. FID 0Ch.APSTE enables a 32-entry table with ITPT idle milliseconds in that state and ITPS targeting a nonoperational state. FID 10h TMT1/TMT2 use kelvins.

2. How to choose and verify

Read NPSS/power-state descriptors, APSTA, HCTMA and MNTMT/MXTMT.

Discover states/latencies, select explicit PS or an APST table and separately set legal TMT1<TMT2 when both are nonzero. Each new state uses its own idle-transition condition.

APST: Autonomous Power State Transition

Successful FID 02h Set establishes the requested PS, but enabled APST may transition again. HCTM activity is not another host Power Management command.

3. Checks across reset or power loss

Trigger	Effect on this operation or state
What survives or continues after Controller Reset?	Non-saveable Power Management/APST follows Figure 466 defaults; non-saveable HCTM is persistent. Saveable configurations use Saved rules, with coordination among controllers sharing a domain.
What survives or continues after a power cycle?	Do not classify all three as volatile: non-saveable HCTM persists, whereas Power Management/APST do not; saveable features restore Saved.

4. Conditions that shape the comparison

Unsupported states, invalid APST targets and illegal thermal ranges/order follow the relevant Invalid Field (0/02h) requirements.

Compare configuration, operational state, SMART temperature and HCTM counters separately. Lower power alone does not identify APST as the cause.

Sources: Base 2.4 §5.2.30.1.2, 5.2.30.1.7 · Base 2.4 §5.2.30.1.10 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.18 · Base 2.4 §8.1.19 · Base 2.4 §5.2.13.1.14.2.13

Source locations for this question

Back to questions

Q63 How are Timestamp, Keep Alive Timer and Host Memory Buffer configured and verified?

Follow the explanation

These provide event time, communication-liveness monitoring and dedicated host memory, requiring different validation methods.

1. Prepare the operation

Timestamp/Keep Alive are controller time state; HMB also controls ownership/lifetime of host memory.

HMB: Host Memory Buffer

Check ONCS for Timestamp, KAS/CTRATT.TBKAS for Keep Alive, and HMPRE/HMMIN/HMMINDS/HMMAXD for HMB.

HMB: Host Memory Buffer

FID 0Eh sets a 48-bit millisecond Timestamp in an 8-byte buffer. FID 0Fh sets KATO milliseconds rounded up to KAS×100 ms. FID 0Dh configures EHM/MR, HSIZE and descriptor address/count.

2. Sequence and completion conditions

Timestamp Get should reflect elapsed time; KATO Get returns the rounded value. Allocate valid HMB pages before enabling and reclaim only after successful disable. MR=1 requires unchanged contents and descriptors as well as layout.

KAS=10 rounds requested KATO1500 ms to 2000 ms. HMB Get returns CQE state and an attributes buffer, not only an enable bit.

3. Handle unmet conditions

Re-enabling enabled HMB returns 0/0Ch; HMDLEC=0 returns 0/02h. PCIe allows KATO=0 to disable; do not import another transport's mandatory-enablement rule.

Check Timestamp Origin/Synch rather than assuming a perfect wall clock, rounded KATO Current and HMB support/configuration/EHM/memory retention.

Sources: Base 2.4 §5.2.30.1.8 · Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.30.2.3, 8.2.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.18

Source locations for this question

Back to questions

Q64 What do Host Behavior Support, Error Recovery and Read Recovery Level do?

Follow the explanation

Advertise host understanding of extensions, configure namespace error recovery and choose a read-recovery strategy.

1. What differs

FID 16h is controller-scoped, FID 05h namespace-scoped, and FID 12h set/subsystem-scoped according to NVM Set support.

FID 16h payload includes ACRE/LBAFEE. FID 05h TLER uses 100 ms and DULBE bit 16. FID 12h RRL is a level code, not the RRLS bitmap.

2. How to choose and verify

Pair ACRE with relevant capabilities, check NSFEAT.DAE before DULBE and RRLS before selecting a recovery level.

Discover support before Set. TLER starts when error recovery begins, not at command submission as a universal timeout. Set/read an advertised RRL for the correct target.

ACRE enables applicable advanced retry behavior; DULBE changes unwritten/deallocated-block responses. Fast Fail does not promise fixed latency or zero internal attempts.

3. Checks across reset or power loss

Trigger	Effect on this operation or state
What survives or continues after Controller Reset?	Non-saveable Host Behavior Support and Error Recovery are nonpersistent, while Read Recovery Level persists. Saveable cases follow Saved and scope-dependent reset rules.
What survives or continues after a power cycle?	Re-read Current after a power cycle. Non-saveable RRL still persists; absence of Saved does not mean it must return zero. Host Behavior Support/Error Recovery use their separate restoration rules.

4. Conditions that shape the comparison

Unsupported levels/invalid settings follow 0/02h and applicable rules. Command Interrupted 0/21h requires ACRE=1 and DNR=0.

DNR: Do Not Retry, a completion retry indication

LBAFEE affects exposure/use of extended formats; interpret capability, host declaration and namespace format together.

Sources: Base 2.4 §5.2.30.1.15 · NVM Command Set 1.3 §4.1.3.1–4.1.3.7 · Base 2.4 §5.2.30.1.12, 8.1.23 · Base 2.4 §4.2.3 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.18

Source locations for this question

Back to questions

Q65 How is namespace write protection configured, and which modes survive reset or power cycling?

Follow the explanation

Prevent namespace modification with reversible, until-power-cycle and permanent protection lifetimes.

1. Prepare the operation

Protection belongs to the namespace and applies through other controllers accessing it, not just one queue's software flag.

NWPC advertises capability, WPC.WPUPCC/PWPC permits entering specific modes and Get FID 84h.WPS reports current state.

WPS0/1/2/3 means none/basic/until-power-cycle/permanent. This feature is unsaveable and has no Default; SV=1 does not create persistence.

2. Sequence and completion conditions

Check support/entry permission, Set WPS for NSID and read Current. Entering protection commits that namespace's volatile data/metadata to nonvolatile media.

After success, prohibited operations must obey protection rules while ordinary reads remain governed by readable state. Verify behavior in addition to Set success.

3. Checks across reset or power loss

Trigger	Effect on this operation or state
What survives or continues after Controller Reset?	Controller Reset preserves existing WPS, including Until Power Cycle; unsaveability does not remove protection.
What survives or continues after NVM Subsystem Reset?	NVM Subsystem Reset is not a power cycle; WPS follows its state machine. NSSR is not a method to remove Until Power Cycle protection.
What survives or continues after a power cycle?	An actual power cycle returns WPS2 to No Write Protect; basic WPS1 and permanent WPS3 persist. Ordinary Set/reset cannot remove permanent protection.

4. Handle unmet conditions

Changing WPS2/3, missing entry permission or prohibited multi-domain WPS2 transition uses 1/0Eh; Get Default uses 0/02h; prohibited commands may return Namespace is Write Protected 0/20h.

CHANG=1 does not promise reversal of permanent protection. Reset of WPC permission bits differs from the namespace's existing WPS state.

Sources: Base 2.4 §5.2.30.1.38, 8.1.18 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.18

Source locations for this question

Back to questions

Q66 Why read Get Features after a successful Set Features?

Follow the explanation

Verify transformations between the requested and effective value rather than relying only on success status.

1. Prepare the operation

Compare identical FID/scope/selectors and time; Supported Capabilities is not Current.

Know the response format and support; values may be in CQE, a payload or both.

Preserve original SV/parameters and Set results, read Current with SEL 0 and Saved with SEL 2 when needed.

2. Sequence and completion conditions

Await successful Set before Get and coordinate concurrent shared-scope writers. Compare dynamic values such as Timestamp with elapsed time rather than byte equality.

Successful Set completion cannot precede completion of attribute setting. Rounded KATO and allocated queue counts may validly differ from requests.

3. Handle unmet conditions

A later Get failure has its own status and does not replace the Set result. Check selectors, scope and intervening reset.

Readback establishes reported configuration; behavioral checks establish its use. Both are needed, without duplicating the same comparison as separate tests.

Sources: Base 2.4 §5.2.12 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.30 (Command Completion) · Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.30.1.5 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §4.4 · Base 2.4 §5.2.13.1.18

Source locations for this question

Back to questions

Q67 How should features change after activation, namespace deletion, reset and power cycling?

Follow the explanation

Establish persistence expectations per event and feature instead of assuming universal clearing or retention.

1. Identify the trigger and affected objects

Separate controller, namespace and shared-object scope, then Current/Saved/Default.

Check SVBL, Figure 466/NVM Figure 92 and feature-specific exceptions. Unsaveable and nonpersistent are not synonyms.

2. State changes and recovery

Record actual CLR occurrence and coverage. Namespace deletion removes an object; a new namespace reusing its number is not automatically the same configured object.

Snapshot, perform the defined event, restore management access, reread values/capabilities and verify behavior. For activation, identify its actual activation/reset path.

An SV=0 change to a saveable feature can revert to older Saved after reset; HMB needs reconfiguration; WPS2 survives Controller Reset but ends at a power cycle.

3. Verify retention and recovery

Access after object deletion follows that FID's NSID rules; failure to read a deleted namespace is not evidence of failed saving.

Preserve object identity, SV, scope, reset cause and timing, not merely a changed-value flag.

First confirm the same object and the actual reset coverage.

Sources: Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.30.1.8 · Base 2.4 §5.2.30.2.3, 8.2.4 · Base 2.4 §5.2.30.1.38, 8.1.18 · Base 2.4 §5.2.24–5.2.25, 8.1.17 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §5.2.13.1.18

Source locations for this question

Back to questions

Q68 How should supported-feature claims be checked when Get, Set and behavior appear inconsistent?

Follow the explanation

Isolate whether the contradiction lies in capability, configuration, observation or firmware behavior under reproducible conditions.

1. Preserve the evidence first

Fix controller, FID, NSID/other selectors and configuration interval to avoid mixing scopes.

Compare Identify, feature-effects information and SEL 3. NSSPEC=0 is not necessarily controller scope; CHANG=1 is not unconditional changeability.

Preserve FID/SEL/SV/CDW11/payloads and CQEs, and identify commands already outstanding before behavioral checks.

2. Work through the possible causes

First check wrong SEL/NSID or behavioral test commands submitted before Set completed.

Discover, legally Set, await completion, Get Current and submit new affected work; test saving/reset separately, changing one factor at a time.

3. Connect observations to specification conditions

Consistency means conformance to allowed outcomes. Rounded KATO, dynamic Timestamp and implementation-specific coalescing cannot be rejected simply for differing from a request.

First distinguish unsupported FID 0/02h, unsaveable 1/0Dh, unchangeable 1/0Eh and wrong-scope 1/0Fh; retain allowed status choices for multiple faults.

A noncompliance finding should include the explicit requirement, established prerequisites, raw request/response and evidence excluding selector/timing misuse.

Sources: Base 2.4 §4.4 · Base 2.4 §5.2.12 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.30 (Command Completion) · Base 2.4 §5.2.30.2.1–5.2.30.2.2 · Base 2.4 §5.2.13.1.6 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §5.2.13.1.18

Source locations for this question

Back to questions

Source locations and existing figure guides

Base printed page = PDF page−26; the other two use identical numbers. Locations follow the supplied PDF body and retain figure numbers. Shared pages contribute only the relevant definitions, excluding Fabrics and PCIe link/packet content.

Base 2.4 · §3.7.1–3.7.4
Printed pages 120–124 · PDF 146–150
Base 2.4 · §3.9 (common and PCIe rules), 5.2.30.1.9
Printed pages 129–135, 471 · PDF 155–161, 497 · Figure 481
Base 2.4 · §4.2.3
Printed pages 145–155 · PDF 171–181 · Figure 101–105
Base 2.4 · §4.4
Printed pages 166–169 · PDF 192–195 · Figure 126–127
Base 2.4 · §5.2.2
Printed pages 183–190 · PDF 209–216 · Figure 150–156
Base 2.4 · §5.2.12
Printed pages 209–212 · PDF 235–238 · Figure 197–202
Base 2.4 · §5.2.13.1.2
Printed pages 218–220 · PDF 244–246 · Figure 212
Base 2.4 · §5.2.13.1.6
Printed pages 226–229 · PDF 252–255 · Figure 216–217
Base 2.4 · §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Printed pages 244–256, 258, 262–264 · PDF 270–282, 284, 288–290 · Figure 232–244, 246, 252–253
Base 2.4 · §5.2.13.1.14.2.13
Printed pages 265–266 · PDF 291–292 · Figure 255
Base 2.4 · §5.2.13.1.18
Printed pages 276–278 · PDF 302–304 · Figure 270–271
Base 2.4 · §5.2.14.2.1
Printed pages 340–387 · PDF 366–413 · Figure 338–341
Base 2.4 · §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2
Printed pages 387–399, 402–404 · PDF 413–425, 428–430 · Figure 342–355, 360–362
Base 2.4 · §5.2.24–5.2.25, 8.1.17
Printed pages 442–448, 660–664 · PDF 468–474, 686–690 · Figure 442–450
Base 2.4 · §5.2.30.1 (common fields, scope and persistence)
Printed pages 456–460 · PDF 482–486 · Figure 463–466
Base 2.4 · §5.2.30.1.1
Printed pages 460 · PDF 486 · Figure 467
Base 2.4 · §5.2.30.1.2, 5.2.30.1.7
Printed pages 460–462, 468–469 · PDF 486–488, 494–495 · Figure 468–469, 475–478
Base 2.4 · §5.2.30.1.4
Printed pages 464–465 · PDF 490–491 · Figure 471
Base 2.4 · §5.2.30.1.5
Printed pages 465–466 · PDF 491–492 · Figure 472–473
Base 2.4 · §5.2.30.1.6
Printed pages 466–468 · PDF 492–494 · Figure 474
Base 2.4 · §5.2.30.1.8
Printed pages 469–471 · PDF 495–497 · Figure 479–480
Base 2.4 · §5.2.30.1.10
Printed pages 471–472 · PDF 497–498 · Figure 482
Base 2.4 · §5.2.30.1.12, 8.1.23
Printed pages 473, 689–690 · PDF 499, 715–716 · Figure 484–485, 755
Base 2.4 · §5.2.30.1.15
Printed pages 475–477 · PDF 501–503 · Figure 491
Base 2.4 · §5.2.30.1.18
Printed pages 478–479 · PDF 504–505 · Figure 494–495
Base 2.4 · §5.2.30.1.38, 8.1.18
Printed pages 512, 664–666 · PDF 538, 690–692 · Figure 541, 735–737
Base 2.4 · §5.2.30.2.1–5.2.30.2.2
Printed pages 514–515 · PDF 540–541 · Figure 543–544
Base 2.4 · §5.2.30.2.3, 8.2.4
Printed pages 515–519, 744 · PDF 541–545, 770 · Figure 545–553
Base 2.4 · §5.2.30 (Command Completion)
Printed pages 519 · PDF 545 · Figure 554
Base 2.4 · §5.3.1–5.3.2
Printed pages 527–531 · PDF 553–557 · Figure 571–579
Base 2.4 · §8.1.19
Printed pages 666–672 · PDF 692–698 · Figure 738–740
NVM Command Set 1.3 · §2.1.2–2.1.4
Printed pages 14–20 · PDF 14–20 · Figure 3–9
NVM Command Set 1.3 · §4.1.3.1–4.1.3.7
Printed pages 64–69 · PDF 64–69 · Figure 92–101
NVM Command Set 1.3 · §4.1.5.1–4.1.5.4
Printed pages 84–107 · PDF 84–107 · Figure 123–130
PCIe Transport 1.4 · §3.5
Printed pages 13–16 · PDF 13–16 · Figure 9

When you need a field guide

Existing figure explanations have canonical locations; use these links instead of duplicating the same guide.

Original documents used

NVM Express Base Specification · Revision 2.4 · 2026-07-31
NVM-Express-Base-Specification-Revision-2.4-Ratified-2026.07.31.pdf
NVM Express NVM Command Set Specification · Revision 1.3 · 2026-07-31
NVM-Express-NVM-Command-Set-Specification-Revision-1.3-Ratified-2026.07.31.pdf
NVM Express NVMe over PCIe Transport Specification · Revision 1.4 · 2026-07-31
NVM-Express-NVMe-over-PCIe-Transport-Specification-Revision-1.4-Ratified-2026.07.31.pdf

NVMe Self-Study Bank: Get Features and Set Features

Current and Saved follow different update paths

Questions in this volume

Q54 What do Current, Default, Saved and Supported Capabilities mean?

1. What differs

2. How to choose and verify

Worked lookup: FSUPP, SVBL and Current.WCE

3. Conditions that shape the comparison

Q55 How does Set Features.Save affect values after reset and power cycling?

1. Identify the trigger and affected objects

2. State changes and recovery

3. Verify retention and recovery

Q56 Which errors apply to unsupported features, invalid values and unsupported Save?

1. Distinguish the failure conditions

2. Establish the cause from evidence

3. Outcome and follow-up checks

Q57 How does the host determine whether a feature requires NSID?

1. Select the target and information

2. Query sequence and interpretation

3. Handle missing or inconsistent evidence

Q58 How are Arbitration, Number of Queues and I/O Command Set Profile configured and checked?

1. Prepare the operation

2. Sequence and completion conditions

3. Handle unmet conditions

Q59 How are interrupt coalescing and vector configuration set and verified?

1. Prepare the operation

2. Sequence and completion conditions

3. Handle unmet conditions

Q60 What do Volatile Write Cache and Write Atomicity Normal control?

1. What differs

2. How to choose and verify

3. Conditions that shape the comparison

Q61 How does Asynchronous Event Configuration select reported events?

1. Prepare the operation

2. Sequence and completion conditions

3. Handle unmet conditions

4. Asynchronous Event notification conditions

Q62 How do Power Management, APST and Host Controlled Thermal Management differ?

1. What differs

2. How to choose and verify

3. Checks across reset or power loss

4. Conditions that shape the comparison

Q63 How are Timestamp, Keep Alive Timer and Host Memory Buffer configured and verified?

1. Prepare the operation

2. Sequence and completion conditions

3. Handle unmet conditions

Q64 What do Host Behavior Support, Error Recovery and Read Recovery Level do?

1. What differs

2. How to choose and verify

3. Checks across reset or power loss

4. Conditions that shape the comparison

Q65 How is namespace write protection configured, and which modes survive reset or power cycling?

1. Prepare the operation

2. Sequence and completion conditions

3. Checks across reset or power loss

4. Handle unmet conditions

Q66 Why read Get Features after a successful Set Features?

1. Prepare the operation

2. Sequence and completion conditions

3. Handle unmet conditions

Q67 How should features change after activation, namespace deletion, reset and power cycling?

1. Identify the trigger and affected objects

2. State changes and recovery

3. Verify retention and recovery

Q68 How should supported-feature claims be checked when Get, Set and behavior appear inconsistent?

1. Preserve the evidence first

2. Work through the possible causes

3. Connect observations to specification conditions

Source locations and existing figure guides

When you need a field guide

Jia-Chang

Recent posts

Comments