An asynchronous verification method for SSD firmware front-end queue injection

Abstract

The application discloses an asynchronous checking method for SSD firmware front-end queue injection, and relates to the technical field of solid state disk firmware testing. The command context only saves a command generation and an unbound placement generation field before a host command is submitted. After the host command enters a real front-end processing path, the RUH associated state corresponding to the placement identification is read, and the data placement state is formed. The placement generation and the placement state identification are written by the state owner based on the same local placement snapshot. The placement attribution of the command is accurate at the time point when the firmware actually consumes the RUH associated state, the submitted stage state, the actual placement decision stage state and the completion return stage state can be distinguished, and the placement state misjudgment caused by the overlapping of RUH switching and in-transit write commands is reduced.

Description

Technical Field

[0001] This invention relates to the field of solid-state drive firmware testing technology, and in particular to an asynchronous verification method for SSD firmware front-end queue injection. Background Technology

[0002] As NVMe SSDs evolve towards multiple commit queues, multiple completion queues, and high queue depths, firmware testing platforms typically inject read / write or management commands into the firmware of the SSD under test through host commit queues, doorbell registers, and completion queues. Before command submission, the testing platform establishes a test context, recording the command identifier, logical address, data pattern, data version, and queue information. After the completion queue item returns, it retrieves the corresponding test context based on the command identifier to verify the data write, data read, and command completion status.

[0003] For SSDs that support Flexible Data Placement, write commands can carry a placement identifier. The firmware determines the placement state of the data based on the Reclaim Unit Handle associated with this placement identifier. Existing testing procedures typically read the RUH state corresponding to the placement identifier when the write command is submitted, and save this state along with the logical address, data pattern, and command identifier. After the write command is completed, the completion status, read data, RUH state snapshot, or FDP event are combined to determine whether the write command fell into the expected placement state. Some testing procedures also read the state before and after the RUH update, or pause subsequent write commands with the same placement identifier during the RUH update, to reduce the impact of state switching on the verification results.

[0004] However, when multiple commit queues run in parallel and have high queue depths, there is an interval between the moment the host side writes a command and triggers a commit, and the moment the firmware frontend captures the command, parses the placement identifier, and reads the RUH association state. When RUHUpdate, implicit RUH switching, or controller state reconstruction occurs within this interval, the same placement identifier may correspond to different RUH association states in the command commit phase and the actual firmware placement decision phase. If the test platform uses the RUH state read in the commit phase as the basis for verifying the command, the firmware is prone to misjudgment when processing the command in the RUH state after the switch. If the test platform only verifies based on the final RUH snapshot, written data, or logical address, it is difficult to identify situations where the firmware continues to use the RUH association state before the switch due to caching, cross-core message passing, or state synchronization delays.

[0005] Furthermore, completed queue items may be returned out of order, and command identifiers may be reused after reset, timeout processing, or queue resource reclamation. Relying solely on command identifiers and two state snapshots before and after the RUH update makes it difficult to determine whether a specific command actually consumes the placement state before or after the switch. Late completion items or outdated placement state records may also be associated with the reused command context, causing incorrect context binding. If only the number of completed commands is counted at the end of the test, without confirming that historical placement states no longer have in-transit commands referencing them, unassigned placement events and unclosed verification contexts may still remain. Therefore, an asynchronous verification method for SSD firmware front-end queue injection is urgently needed to solve these problems. Summary of the Invention

[0006] This invention provides an asynchronous verification method for SSD firmware front-end queue injection, which solves the problem of asynchronous verification distortion caused by the difficulty in tracing the generation of command placement under concurrent FDP switching.

[0007] This invention provides an asynchronous verification method for SSD firmware front-end queue injection, used for software testing of SSD firmware supporting FDP, including:

[0008] Transform the write test request into a write host command that is associated with the commit queue identifier and carries the command identifier, logical address, and placement identifier;

[0009] Before committing, assign a command generation to the write host command, establish a command context containing the expected data state and unbound generation fields, and establish a command generation association table indexed by the commit queue identifier and command identifier.

[0010] The write host command is prompted to enter the actual front-end processing path via a front-end queue notification.

[0011] When the write host command reads the RUH association status corresponding to the placement identifier and forms a data placement status, the status owner generates a placement status record based on the same local placement snapshot for the test side to read through the read-only observation interface, obtains the command generation according to the command generation association table, and writes the placement generation and placement status identifier into the command context at once.

[0012] A new placement generation is generated when the state owner confirms the change in the RUH associated state corresponding to the placement identifier.

[0013] After receiving the asynchronous completion information, use the submission queue identifier and command identifier to query the command generation association table to locate the command context, and verify the data result and data placement status.

[0014] The referenced historical placement generation remains valid until the reference is removed, and test results are generated after the command context and the historical placement generation have been reclaimed.

[0015] In some embodiments, converting a write test request into a write host command includes: normalizing the logical address range of the write test request according to the data processing boundaries of the SSD firmware under test;

[0016] When a write test request spans more than two logical processing units, the write test request is split into multiple sub-commands; for each sub-command, the submission queue identifier, command identifier, logical processing unit address, valid data range within the unit, and data version are recorded, and each sub-command is established as an independent asynchronous verification object to create a command context.

[0017] In some embodiments, the expected data state includes a version to be written, an effective version, logical address information, and valid data range information; for a write command that partially covers a logical processing unit, after the write command is successfully completed, the version to be written of the data unit covered by the valid data range is submitted as an effective version, and the effective version of the data unit that is not covered is maintained.

[0018] When a write command fails, times out, or is canceled, the version to be written is not committed as an effective version. In tests that include read commands, the read command does not perform generational binding, and performs effective version verification and logical address verification on data units within the valid data range after asynchronous completion.

[0019] In some embodiments, the command context has states of pending write, published, committed, processing completed, and released; in the pending write state, the commit queue identifier, command identifier, command generation, logical address, data expected state, placement identifier, and unbound placement generation field are written;

[0020] After the field is written, it is converted to the published state; after the front-end queue notification is completed, it is converted to the committed state; after asynchronous processing begins, it is converted to the processing in progress state; after the data result and data placement status verification are completed, it is converted to the released state.

[0021] In some embodiments, asynchronous completion processing only reads the command context that corresponds to the submission queue identifier, command identifier, and command generation and is in a submitted state or in a completed state.

[0022] When the command context corresponding to the asynchronous completion information is in a pending write state, a published state, a released state, or a state where the corresponding command generation does not exist, the asynchronous completion information is written to an abnormal state, and the corresponding state reason is recorded; the asynchronous completion information in the abnormal state does not participate in the generation of normal verification conclusions.

[0023] In some embodiments, the one-time write includes: accepting a placement snapshot binding request from the state owner only when the placement generation field of the command context is in an unbound state;

[0024] Write the placement status identifier and placement generation as a command-level placement snapshot into the command context, and use the binding of a valid flag as the completion release point;

[0025] The processing side reads the command-level placement snapshot only when the binding validity flag is in effect; when the same command context receives another placement snapshot binding request, receives a placement snapshot binding request that is inconsistent with the current command generation, or receives a placement snapshot binding request in a released state, the written command-level placement snapshot is retained, an abnormal state is written, and the corresponding state reason is recorded.

[0026] In some embodiments, the state owner is an FDP state management object that maintains the placement identifier and RUH associated state in the firmware execution environment of the SSD under test; the read-only observation interface exposes a read view of the observation ring buffer and does not set up an RUH mapping table write entry, an RUH associated state modification entry, or a placement generation allocation entry.

[0027] The placement status record includes observation number, submission queue identifier, command identifier, command generation, placement identifier, placement generation, placement status identifier, status timestamp, and submission flag. The observation number is assigned serially or atomically by the status owner. After writing the placement status record fields, the status owner publishes the submission flag. The test side consumes the slot content and updates the next observation number to be consumed when it confirms that the submission flag is effective, the observation number is consistent, and it meets the requirements of the next observation number to be consumed.

[0028] In some embodiments, generating a new placement generation includes: the state owner maintaining a current RUH associated state description item and a historical RUH associated state description item for each placement identifier, the description item including the placement identifier, RUH associated state content, placement generation, state effective flag, and reference count;

[0029] The state owner converts RUH update commands, RUH implicit switching events, and controller state rebuild events that cause the RUH associated state to be re-established into RUH associated state change requests for the same placement identifier, and processes them serially in the order of arrival.

[0030] When the target RUH association state content is inconsistent with the current RUH association state content, a new RUH association state description item is created for the changed RUH association state, and the new placement generation is generated incrementally based on the maximum value among the current active placement generation set, the historical placement generation set that has not yet been recycled, and the generation starting reference value.

[0031] In some embodiments, after a new placement generation is generated, the state owner will change the RUH associated state description item before the change from the current state to the historical reserved state, and set the changed RUH associated state description item as the current state.

[0032] When a command context completes the publication of a command-level placement snapshot, the state owner increments the command context reference count for the corresponding placement generation; when the command context is transferred to the released state, the command context reference count is decremented.

[0033] When a placement status record is published, the reference count of the placement status record for the corresponding placement generation is increased. When the placement status record is consumed by the test side, written to an abnormal state, or overwritten by the record corresponding to the subsequent observation sequence number, the reference count of the placement status record is decreased.

[0034] The total number of unclosed references is obtained by summing the command context reference count and the placement state record reference count. The state owner will reclaim the corresponding historical RUH associated state description only when the total number of unclosed references is zero.

[0035] In some embodiments, the test side establishes a sticky failure state to save the abnormality of this test;

[0036] When a controller reset, command timeout, command cancellation, or front-end queue reconstruction occurs, the command generation or queue generation used before the change will be marked as an invalid generation.

[0037] The test side synchronously writes objects that enter an abnormal state during the test to the sticky failure state; after the test script stops generating new test requests, it performs a joint drain.

[0038] A test pass result is generated when all command contexts have ended their current lifecycles, all published placement state records in the read-only observation interface have been consumed, there are no unclosed references in the historical placement generations, and no exceptions are recorded in the sticky failure state; otherwise, a test failure result is generated.

[0039] Through the above technical solution, the present invention can achieve at least the following beneficial effects:

[0040] In this invention, the command context only stores the command generation and unbound placement generation fields before the host command is submitted. After the host command enters the actual front-end processing path, when reading the RUH association state corresponding to the placement identifier and forming the data placement state, the state owner writes the placement generation and placement state identifier based on the same local placement snapshot. The placement attribution of the command is based on the actual time when the firmware consumes the RUH association state, which can distinguish between the submission stage state, the actual placement decision stage state, and the completion return stage state, reducing misjudgments of placement state caused by the overlap of RUH switching and in-transit write commands.

[0041] The state owner simultaneously writes a command-level placement snapshot to the command context and outputs a similar placement state record through a read-only observation interface. When the test side reads the observation record, it only compares the command context and the copy of the observation record, without writing to the RUH mapping table, modifying the RUH associated state, or participating in placement generation allocation. The placement state evidence obtained by the test side is consistent with the source of the firmware placement decision, enabling the determination of the actual placement state used for the same command while preserving the real firmware front-end processing path.

[0042] Command context is located using a combination of submission queue identifier, command identifier, and command generation. The placement status record also carries the submission queue identifier and command generation. After a controller reset, command timeout, command cancellation, or front-end queue reconstruction, asynchronous completion information under the failed generation is processed separately from the subsequent new command context that reuses the same command identifier. Under conditions of out-of-order completion, late completion, and command identifier reuse, the completion information and placement status record of the old command can be isolated from the new command context, reducing the probability of rebinding with an incorrect context.

[0043] When the RUH association state changes, the state owner generates a new placement generation for the changed RUH association state and retains the previous RUH association state descriptor until the total number of unclosed references reaches zero. In-transit commands that have already been written to the old placement generation continue to belong to the old placement state, while in-transit commands that have not yet been written to a placement generation are assigned affiliation based on the RUH association state actually read later. Therefore, the test completion phase can simultaneously close the command context, placement state record, and historical placement generation references, reducing the number of unassigned placement events remaining when only counting the number of completed commands. Attached Figure Description

[0044] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope of the present invention.

[0045] Figure 1 This is a flowchart of the asynchronous verification method injected into the SSD firmware front-end queue in the embodiment. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0047] All terms used in this invention (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined.

[0048] Example 1:

[0049] like Figure 1 As shown, this embodiment provides an asynchronous verification method for SSD firmware front-end queue injection, used for software testing of SSD firmware that supports Flexible Data Placement (FDP), including:

[0050] Step S1: Convert the write test request into a write host command that is associated with the commit queue identifier and carries the command identifier, logical address and placement identifier;

[0051] Step S2: Before committing, assign command generations to the write host command, establish a command context containing the expected data state and unbound generation fields, and establish a command generation association table indexed by the commit queue identifier and command identifier.

[0052] The command generation association table stores the correspondence between the commit queue identifier, command identifier, command generation, and command context index. The testing side writes entries to the command generation association table before the command context enters the published state and removes the corresponding entries after the command context enters the released state. When generating a placement state record, the state owner retrieves the command generation from the command generation association table using the commit queue identifier and command identifier. Upon receiving asynchronous completion information, the completion processing side retrieves the command generation from the command generation association table using the commit queue identifier and command identifier in the asynchronous completion information to obtain the command generation and locate the command context.

[0053] In this embodiment, the data processing boundary represents the smallest logical range boundary used by the tested SSD firmware when performing expected data state updates and verifications. The logical processing unit represents the logical address unit divided by this data processing boundary, and the data unit represents the smallest verification granularity used within the logical processing unit to record the data version. The test side divides the logical processing units covered by the test request according to the logical address and transmission length, and uses the effective data range within the unit as the scope of data version updates or reads.

[0054] In one optional implementation, converting a write test request into a write host command includes: normalizing the logical address range of the write test request according to the data processing boundary of the SSD firmware under test; when a write test request spans more than two logical processing units, splitting the write test request into multiple sub-commands; recording the submission queue identifier, command identifier, logical processing unit address, valid data range within the unit, and data version for each sub-command, and establishing a command context for each sub-command as an independent asynchronous verification object.

[0055] Furthermore, the expected data state in the command context includes the version to be written, the effective version, logical address information, and valid data range information. For write commands that partially cover logical processing units, the test side first records the version to be written for the data units covered by the valid data range; when the write command completes successfully, the test side submits the version to be written for the corresponding data unit as the effective version, and maintains the effective version for the uncovered data units; when the write command fails, times out, or is canceled, the test side discards the corresponding version to be written and does not update the effective version used by subsequent read commands. In tests including read commands, the read command does not perform generational binding; after the read command completes asynchronously, the test side performs effective version verification and logical address verification on the data units within the valid data range to distinguish between current version data, historical version data, and data from other logical addresses.

[0056] When both the effective version and logical address information are consistent with the expected data state, the test side determines that the data result verification of the read command has passed; when the effective version is inconsistent, the test side writes the corresponding command context into an abnormal state and records the reason for the state as inconsistent data version; when the logical address information is inconsistent, the test side writes the corresponding command context into an abnormal state and records the reason for the state as inconsistent logical address.

[0057] Step S3: The host command is sent to the real front-end processing path by notifying the front-end queue recognized by the firmware of the SSD under test.

[0058] Specifically, front-end queue notifications include updates to the tail pointer of the submission queue, doorbell writing, queue status notifications in the firmware emulation environment, and command visibility notifications consistent with the front-end capture logic of the SSD firmware under test. The actual front-end processing path begins with the host command becoming visible to the front-end of the SSD firmware under test, and sequentially includes front-end command capture, command field parsing, placement identifier parsing, RUH association status reading, data placement status formation, media write request generation, and completion information return. Host commands can be written to the submission queue in the form of NVMe submission queue items, or to the test queue in the form of front-end command descriptors in the SSD firmware emulation environment; both forms are read by the original front-end command parsing logic of the SSD firmware under test.

[0059] The submission queue identifier is determined by the submission queue containing the host command, and the command identifier is determined by the command identifier field in the write host command. After the front-end of the SSD under test captures the write host command, it passes the submission queue identifier and command identifier to the placement decision function, enabling the state owner to query the command generation association table. The completion time of the front-end queue notification is based on the SSD under test being able to capture the host command; the command generation is written to the command context before the host command enters the captureable state.

[0060] The command context has four states: Pending Write, Published, Committed, Processing Complete, and Released. In the Pending Write state, the commit queue identifier, command identifier, command generation, logical address, expected data status, placement identifier, and unbound placement generation field are written. After the fields in the command context are written, it transitions to the Published state. After the front-end queue notification is received upon completion of the write host command, it transitions to the Committed state. After asynchronous completion processing begins, it transitions to the Processing Complete state. Finally, after verifying the data results and data placement status, it transitions to the Released state.

[0061] Step S4: When the write host command reads the RUH association state corresponding to the placement identifier in the real front-end processing path and forms a data placement state, the status owner who maintains the placement identifier and RUH association state generates a placement state record based on the same local placement snapshot. The status owner retrieves the command generation by querying the command generation association table using the submission queue identifier and command identifier, and writes the placement generation and placement state identifier into the command context at once. The test side reads the placement state record through the read-only observation interface. When the status owner confirms that the RUH association state corresponding to the placement identifier has changed, a new placement generation is generated;

[0062] Step S5: After receiving the asynchronous completion information, the command generation is retrieved from the command generation association table using the submission queue identifier and command identifier in the asynchronous completion information. The command context is then located using the submission queue identifier, command identifier, and command generation. The test side verifies the data results and data placement status based on the command context. Historical placement generations referenced by the command context remain valid until the reference is removed. Test results are generated after the command context and its referenced placement generations have been reclaimed.

[0063] In a preferred embodiment of Example 1, the read-only observation interface is set within the firmware execution environment of the SSD under test.

[0064] When the state owner reads the RUH associated state corresponding to the placement identifier and forms a placement state identifier in the placement decision function, it uses the same local placement snapshot to generate a placement state record. The state owner is the FDP state management object in the SSD firmware execution environment under test, which stores the current mapping, historical mapping, and placement generation allocation state of the placement identifier and RUH associated state. The trigger point for the host command to actually consume the placement state is after the host command completes the placement identifier parsing and before the media write request is generated. The local placement snapshot contains at least the submission queue identifier, command identifier, command generation, placement identifier, placement generation, placement state identifier, and state timestamp, and is used to write the command context and form the placement state record in the same placement decision call. The read-only observation interface only exposes a read view of the observation ring buffer and does not provide an entry point for writing the RUH mapping table, modifying the RUH associated state, or allocating the placement generation.

[0065] Specifically, the read-only observation interface is implemented by reading the content of the corresponding slot in the observation circular buffer. The state owner determines the write slot according to the observation sequence number assigned to the placement state record, based on the slot mapping relationship between the observation sequence number and the total number of slots in the observation circular buffer. The test side saves the next observation sequence number to be consumed and determines the slot to be read according to the slot mapping relationship based on the next observation sequence number to be consumed. The test side reads the submission flag, the observation sequence number in the slot, and each field of the placement state record from the slot to be read through the read-only observation interface. The test side first reads the submission flag and the observation sequence number value in the slot, and after reading the field content of the placement state record, it reads the submission flag and the observation sequence number value in the slot again. When the submission flag is active in both reads, the observation sequence number value in the slot is consistent in both reads, and the observation sequence number value in the slot is equal to the next observation sequence number to be consumed, the placement state record in the slot is taken as the result of this read, and the next observation sequence number to be consumed is updated. The read-only observation interface reads only the published placement state records from the observation ring buffer and does not write or modify the RUH mapping table, RUH associated state, or placement generation allocation state.

[0066] For example, the observation ring buffer can be set to 4096 slots, with each slot storing one placement status record. The observation sequence number uses a 64-bit monotonically increasing counter, and the status timestamp uses a monotonically increasing counter source within the SSD firmware execution environment under test. The number of slots in the observation ring buffer can be set from 1024 to 65536, with the value determined based on the test queue depth, the maximum number of concurrent commands, and the test side polling cycle. If the number of slots is too small, placement status records that have not yet been consumed by the test side are easily overwritten by subsequent records; if the number of slots is too large, the test memory occupied by the observation buffer increases, and the scanning time for historical placement status records during the emptying phase is prolonged. The commit flag and the observation sequence number together serve as the basis for determining the integrity of the slot content, and the status timestamp is used to help distinguish the sequential relationship of records generated at different observation times with the same command identifier. The observation sequence number is used to determine the publication order of placement status records in the read-only observation interface, and the placement generation is used to distinguish different RUH associated status stages corresponding to the same placement identifier; the two participate in record reading and placement attribution determination respectively, and do not replace each other.

[0067] The placement status record is encapsulated according to fixed fields as follows:

[0068] ,

[0069] in, Indicates the observation number is The placement status record, This represents the monotonically increasing observation number assigned by the state owner to the placement state record. Indicates the observation number is The placement status is recorded in the observation ring buffer slot, carrying the observation sequence number value, and The value of and Consistent, Indicates the observation number is The submission queue identifier in the placement status record, Indicates the observation number is The command identifier in the placement status record; Indicates the observation number is The command sequence in the placement status record. Indicates the observation number is The placement identifier in the placement status record, Indicates the observation number is The placement generation in the placement status record, Indicates the observation number is The placement status identifier in the placement status record, Indicates the observation number is The status timestamp in the placement status record. Indicates the observation number is The commit flag in the placement status record.

[0070] The slots in the observation ring buffer are obtained by mapping the observation sequence number:

[0071] ,

[0072] in, Indicates the observation number is The placement status is recorded in the slot number within the observation ring buffer. This indicates the total number of slots in the observed annular buffer zone.

[0073] The status owner is in the slot When writing placement status records, first set the commit flag for that slot to an inactive state, then write... The system requires the following fields to be written: queue identifier, command identifier, command generation, placement identifier, placement generation, placement status identifier, and status timestamp. After writing these fields, a valid commit flag is written. Observation numbers are assigned by the status owner in a monotonically increasing manner. When multiple front-end queues generate placement status records simultaneously, observation numbers are assigned serially or atomically by the status owner. When the test side reads a slot, it first reads the commit flag and the observation number value within the slot. After reading the field content, it reads the commit flag and the observation number value within the slot again. If the commit flag read in both reads is valid, the observation number value within the slot is consistent, and the observation number value within the slot equals the next observation number to be consumed saved by the test side, the test side consumes the placement status record. The test side consuming the placement status record indicates that the slot content meets the complete reading conditions. Before generating a placement status consistency conclusion, the test side continues to perform a record validity check on the placement status record.

[0074] Furthermore, the test side performs record validity checks before consuming the placement status record. Record validity checks include field integrity checks, generation matching checks, observation order checks, and context lifecycle checks. Field integrity checks confirm that the command identifier, command generation, placement identifier, placement generation, and placement status identifier in the placement status record have all been published along with the effective commit flag; generation matching checks confirm that the command generation in the placement status record matches the command generation in the command context saved by the test side; observation order checks confirm that the observation sequence number progresses consecutively according to the next pending observation sequence number saved by the test side; and context lifecycle checks confirm that the corresponding command context is in a committed state or a processing-completed state.

[0075] Placement status records that fail the record validity check are written to an abnormal status, and the corresponding status reason is recorded. Status reasons include incomplete fields, generation mismatch, discontinuous observation order, slot coverage, and context lifecycle mismatch. The test side stops generating placement status consistency conclusions for placement status records that have been written to an abnormal status, and retains placement status records that have been read and passed the record validity check.

[0076] After the placement status record passes the record validity check, the test side uses the submission queue identifier, command identifier, and command generation to locate the command context and compares the placement generation and placement status identifier in the placement status record with the command-level placement snapshot in the command context. If both the placement generation and placement status identifier match, the test side determines that the data placement status verification for the host command has passed; if the placement generation or placement status identifier does not match, the test side writes an abnormal status to the command context and records the reason as placement status inconsistency. The comparison process only accesses the command context and observation record copy maintained by the test side and does not write data to the RUH mapping table, status owner, or placement generation allocation logic of the tested SSD firmware.

[0077] Through the above processing, the read-only observation interface is only used for bypass reading of placement status records already generated by the status owner. The status owner retains the maintenance rights of the placement identifier and the RUH association status. The placement generation is generated by the status owner as the RUH association status changes. The test side does not reverse-correct the placement decision of the tested SSD firmware based on the observation results.

[0078] Specifically, the commit queue identifier in the command context comes from the commit queue where the write host command resides, the command identifier comes from the command identifier field in the write host command, and the command generation is generated by the test side when the command identifier is assigned to this write host command. The expected data state is obtained from the write test request transformation process and is published along with the command context. For write commands, the expected data state includes the version to be written, the effective version, logical address information, and valid data range information; for read commands, the expected data state includes the effective version, logical address information, and valid data range information.

[0079] Furthermore, asynchronous completion processing only reads command contexts that correspond to the submission queue identifier, command identifier, and command generation and are in a committed state or a completed state. When the command context corresponding to the asynchronous completion information is in a pending state, a published state, a released state, or does not have a corresponding command generation, the asynchronous completion information is written to an exception state, and the corresponding state reason is recorded.

[0080] One-time write includes: accepting placement snapshot binding requests from the state owner only when the placement generation field in the command context is in an unbound state. The state owner first writes the placement status identifier and placement generation as a command-level placement snapshot to the command context, and then writes the binding validity flag; the binding validity flag serves as the publication point of the command-level placement snapshot visible to the completion processing side. The completion processing side reads the command-level placement snapshot only when the binding validity flag is in an effective state. When a placement snapshot binding request occurs again in the same command context, a placement snapshot binding request inconsistent with the current command generation is received, or a placement snapshot binding request is received in a released state, the written command-level placement snapshot is retained, and the placement snapshot binding request is written to an abnormal state with the corresponding state reason recorded.

[0081] Queue generations are used to distinguish the usage stages of the same front-end queue in different reconstruction cycles. The test side assigns a queue generation to a front-end queue when it is created, and assigns a new queue generation to the reconstructed front-end queue after controller reset or reconstruction. The command context records the queue generation of its associated front-end queue. If the queue generation corresponding to the asynchronous completion information is inconsistent with the queue generation recorded in the command context, the test side writes the asynchronous completion information to an abnormal status and records the reason as queue generation failure.

[0082] When a controller reset, command timeout, command cancellation, or front-end queue reconstruction occurs, the command generation or queue generation used before the change is marked as a failed generation. Unfinished asynchronous completion information under the failed generation is not associated with a new command context that reuses the same command identifier. After confirming that the tested SSD firmware and the status owner have released the reference to the old command context, the old command context is released. Asynchronous completion information or placement status records that arrive after release are written to an abnormal status, and the reason for the status is recorded as late.

[0083] Based on the above implementation, exception handling is uniformly recorded according to object name, exception status, and status reason. The exception object includes asynchronous completion information, placement status record, command context, and historical placement generation. The exception status indicates that the exception object will no longer participate in the generation of normal verification conclusions, and the status reason indicates the specific source that triggered the exception status. Status reasons for command-related exceptions include invalid command generation, released command context, reused command identifier, and delayed asynchronous completion information; status reasons for placement record exceptions include duplicate writing of placement generation, delayed placement status record, discontinuous observation order, and slot overwriting.

[0084] Reasons for abnormal state handling include the generation limit being triggered and the old RUH associated state not being fully recovered after controller state reconstruction. Abnormal objects written to abnormal states do not participate in the generation of normal verification conclusions and are synchronously written to the sticky failure state.

[0085] A sticky failure state is set during testing. The sticky failure state is used to save the object that first enters an abnormal state during the test and its reason. The abnormal state applies to a single asynchronous completion message, placement status record, command context, or historical placement generation. The sticky failure state applies to the current test process. A sticky failure state is written to the test side when the object first enters an abnormal state due to inconsistent data version, inconsistent logical address, inconsistent placement state, duplicate writing of placement generation, delayed completion due to a failed generation, delayed placement status record due to a released command context, failed record validity check, discontinuous observation order, or slot overwriting. After a sticky failure state is recorded, subsequent abnormal objects continue to be recorded according to their abnormal state and reason. The sticky failure state retains the commit queue identifier, command identifier, command generation, placement generation, and expected data state corresponding to the first abnormality.

[0086] Furthermore, the joint drain is performed in the order of command context, placement status record, and historical placement generation. The test side first stops generating new test requests and waits for the asynchronous completion information corresponding to the submitted command to arrive or enter an abnormal state; then it consumes the published placement status records in the read-only observation interface and completes the comparison between the placement status records and the command context; finally, it counts the total number of unclosed references in the historical placement generations. Historical placement generations with a total number of unclosed references of 0 are reclaimed by the status owner, while historical placement generations with a total number of unclosed references greater than 0 continue to be retained as read-only valid states. Even when a sticky failure state has been recorded as abnormal, the test side continues to perform the joint drain until the command context and historical placement generations meet the reclamation conditions before generating test failure results.

[0087] Example 2:

[0088] In Example 2, the state owner maintains a current RUH associated state description and a historical RUH associated state description for each placement identifier. The description includes at least the placement identifier, RUH associated state content, placement generation, state activation flag, and reference count. The allocation of placement generations is completed by the state owner when processing generation allocation trigger sources. Generation allocation trigger sources include RUH update commands, RUH implicit switching events caused by the internal policies of the tested SSD firmware, and controller state reconstruction events that cause the RUH associated state to be re-established after controller reset, namespace reconstruction, or queue reconstruction.

[0089] After the aforementioned trigger sources enter the state owner, they are all converted into RUH associated state change requests for the same placement identifier, and are processed serially within the state owner in the order of arrival, so that only one RUH associated state for the same placement identifier is marked as the current state at any given time.

[0090] When the state owner processes a RUH-related state change request, it reads the placement identifier and target RUH-related state content carried in the request and compares them with the current RUH-related state description item corresponding to the placement identifier. If the target RUH-related state content is inconsistent with the RUH-related state content in the current RUH-related state description item, the state owner confirms that the RUH-related state has changed; if they are consistent, the state owner maintains the current RUH-related state description item and the current placement generation.

[0091] When the state owner confirms that the RUH associated state has changed, a new RUH associated state description entry is created for the changed RUH associated state, and a new placement generation is assigned in a monotonically increasing manner:

[0092] ,

[0093] in, Indicates placement of signs The new placement generation assigned after this RUH association state change. Placement identifier indicating a change in RUH association status. Indicates placement of signs The current set of placement generations that is still in effect. Indicates placement of signs The historical collection of placement generations that has not yet been fully recycled. Indicates placement of signs The generation starting baseline value. By including the currently effective placement generations and the historical placement generations that are still retained in the allocation caliber, the changed RUH association status obtains a placement generation that is different from the RUH association status before the change. Old placement generations that have been generated but not yet recycled under the same placement identifier will not be reassigned.

[0094] The generation starting baseline value is initialized by the state owner for each placement identifier at the start of the test and does not decrease with changes in the RUH associated state during the same test. After controller reset, namespace reconstruction, or queue reconstruction, the state owner uses the currently saved maximum placement generation as the basis for continued allocation.

[0095] After a new placement generation is generated, the state owner will change the RUH-related state description item from the current state to the historically retained state, and set the changed RUH-related state description item as the current state. The old placement generation in the historically retained state continues to retain its RUH-related state content, placement state identifier, and reference count, and will not be overwritten by the new RUH-related state. In-transit command contexts that have completed a one-time write of their placement generation continue to belong to their written old placement generation, and the placement state identifier corresponding to the old placement generation will still be used for consistency judgment during subsequent asynchronous verification. For in-transit commands that have not yet completed the placement generation write, when their actual front-end processing path subsequently reads the RUH-related state, if they read the changed RUH-related state, they will write the new placement generation; if they read the RUH-related state before the change, they will write the old placement generation before the change. Command ownership is based on the point in time when the command actually reads the RUH-related state and completes the one-time write.

[0096] The retention and reclamation of older generations are performed based on the number of references:

[0097] ,

[0098] in, Indicates placement of signs Subsequent generations The total number of unclosed references, Indicates placement of signs Any placement generation that is retained or referenced below, This indicates that the placement label is still being used. Subsequent generations The number of command contexts, The observation ring buffer of the read-only observation interface still retains and references the placeholder identifier. Subsequent generations The number of placement status records. The status owner only... When the value equals 0, the corresponding historical RUH associated state description item is reclaimed; when When the value is greater than 0, even if the same placement identifier has been assigned a new placement generation, the old placement generation remains in a read-only valid state.

[0099] When a command context completes a command-level placement snapshot publication, the state owner increments the command context reference count for the corresponding placement generation; when the command context transitions to a released state, the state owner decrements the command context reference count for the corresponding placement generation. When a placement state record is published, the state owner increments the placement state record reference count for the corresponding placement generation; when a placement state record is normally consumed by the test side, written to an abnormal state, or overwritten by the record corresponding to a subsequent observation sequence number, the state owner decrements the placement state record reference count for the corresponding placement generation. After the controller is reset or the front-end queue is rebuilt, the test side continues to perform the reference count decrement process according to the current state of the command context and placement state record under the failed generation.

[0100] In abnormal operating conditions, if the number of new placement generations to be allocated reaches the pre-configured upper limit, the state owner will suspend the allocation of new placement generations for the placement identifier, keep the old placement generations that have been written to the command context in a read-only valid state, and register the relevant in-transit command context as a historical reference object that needs to be drained; the test side will resume the allocation of placement generations for the placement identifier after the corresponding historical reference object has been recycled.

[0101] If, after the controller state is rebuilt, the historical RUH associated state description still retains complete RUH associated state content and placement state identifier, the state owner keeps the old placement generation already written to the command context in a read-only valid state, and the test side continues to perform data placement state verification based on this historical RUH associated state description. If the RUH associated state content or placement state identifier in the historical RUH associated state description is missing, the test side will still write the command context referencing the old placement generation into an abnormal state and record the state reason as the old RUH associated state being unable to be completely recovered.

[0102] For example, the placement generation can use a 64-bit monotonically increasing value. Alternatively, the placement generation can use a 32-bit monotonically increasing value, triggering a joint drain before reaching the generation cap. With a smaller bit width, the generation cap is more likely to occur during long-term high-concurrency tests; with a larger bit width, the risk of duplicate generation allocation decreases, but the field usage for placement status records and command context increases.

[0103] Through the above processing, the RUH associated state change, the attribution of new and old placement generations, and the recycling of historical generations are executed continuously within the state owner according to the same placement identifier, so that the placement generation used in the asynchronous completion phase corresponds to the RUH associated state actually read by the command.

[0104] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

[0105] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of the invention and form different embodiments. For example, all the embodiments above can be used in any combination. The information disclosed in the Background section is intended only to enhance the understanding of the general background of the invention and should not be construed as an admission or in any way implying that such information constitutes prior art known to those skilled in the art.

Claims

1. An asynchronous verification method for SSD firmware front-end queue injection, used for software testing of SSD firmware supporting FDP, characterized in that, include: Transform the write test request into a write host command that is associated with the commit queue identifier and carries the command identifier, logical address, and placement identifier; Before committing, assign a command generation to the write host command, establish a command context containing the expected data state and unbound generation fields, and establish a command generation association table indexed by the commit queue identifier and command identifier. The write host command is prompted to enter the actual front-end processing path via a front-end queue notification. When the write host command reads the RUH association status corresponding to the placement identifier and forms a data placement status, the status owner generates a placement status record based on the same local placement snapshot for the test side to read through the read-only observation interface, obtains the command generation according to the command generation association table, and writes the placement generation and placement status identifier into the command context at once. A new placement generation is generated when the state owner confirms the change in the RUH associated state corresponding to the placement identifier. After receiving the asynchronous completion information, use the submission queue identifier and command identifier to query the command generation association table to locate the command context, and verify the data result and data placement status. The referenced historical placement generations remain valid until the reference is removed, and test results are generated after the command context and the historical placement generations have been reclaimed. The state owner is the FDP state management object that maintains the placement identifier and RUH associated state in the execution environment of the SSD firmware under test; the read-only observation interface exposes the read view of the observation ring buffer and does not set the RUH mapping table write entry, RUH associated state modification entry, and placement generation allocation entry.

2. The asynchronous verification method for SSD firmware front-end queue injection according to claim 1, characterized in that, Converting a write test request into a write host command includes: normalizing the logical address range of the write test request according to the data processing boundaries of the SSD firmware under test; When a write test request spans more than two logical processing units, the write test request is split into multiple sub-commands; for each sub-command, the submission queue identifier, command identifier, logical processing unit address, valid data range within the unit, and data version are recorded, and each sub-command is established as an independent asynchronous verification object to create a command context.

3. The asynchronous verification method for SSD firmware front-end queue injection according to claim 2, characterized in that, The expected data state includes the version to be written, the version already in effect, logical address information, and valid data range information; for write commands that partially cover logical processing units, after the write command is successfully completed, the version to be written of the data units covered by the valid data range is submitted as the version already in effect, while the version already in effect of the data units that are not covered is maintained. When a write command fails, times out, or is canceled, the version to be written is not committed as an effective version. In tests that include read commands, the read command does not perform generational binding, and performs effective version verification and logical address verification on data units within the valid data range after asynchronous completion.

4. The asynchronous verification method for SSD firmware front-end queue injection according to claim 1, characterized in that, The command context has states of pending write, published, committed, processing completed, and released; in the pending write state, the commit queue identifier, command identifier, command generation, logical address, expected data status, placement identifier, and unbound placement generation field are written. After the field is written, it is converted to the published state; after the front-end queue notification is completed, it is converted to the committed state; after asynchronous processing begins, it is converted to the processing in progress state; after the data result and data placement status verification are completed, it is converted to the released state.

5. The asynchronous verification method for SSD firmware front-end queue injection according to claim 1, characterized in that, Asynchronous completion processing only reads the command context that corresponds to the submission queue identifier, command identifier, and command generation and is in the submitted or completed state. When the command context corresponding to the asynchronous completion information is in a pending write state, a published state, a released state, or a state where the corresponding command generation does not exist, the asynchronous completion information is written to an abnormal state, and the corresponding state reason is recorded; the asynchronous completion information in the abnormal state does not participate in the generation of normal verification conclusions.

6. The asynchronous verification method for SSD firmware front-end queue injection according to claim 1, characterized in that, The one-time write includes: accepting a placement snapshot binding request from the state owner only when the placement generation field of the command context is in an unbound state; Write the placement status identifier and placement generation as a command-level placement snapshot into the command context, and use the binding valid flag as the completion release point; The processing side reads the command-level placement snapshot only when the binding validity flag is in effect; when the same command context receives another placement snapshot binding request, receives a placement snapshot binding request that is inconsistent with the current command generation, or receives a placement snapshot binding request in a released state, the written command-level placement snapshot is retained, an abnormal state is written, and the corresponding state reason is recorded.

7. The asynchronous verification method for SSD firmware front-end queue injection according to claim 1, characterized in that, The placement status record includes observation number, submission queue identifier, command identifier, command generation, placement identifier, placement generation, placement status identifier, status timestamp, and submission flag. The observation number is assigned serially or atomically by the status owner. After writing the placement status record fields, the status owner publishes the submission flag. The test side consumes the slot content and updates the next observation number to be consumed when it confirms that the submission flag is effective, the observation number is consistent, and it meets the requirements of the next observation number to be consumed.

8. The asynchronous verification method for SSD firmware front-end queue injection according to claim 1, characterized in that, Generating a new placement generation includes: the state owner maintaining a current RUH associated state description item and a historical RUH associated state description item for each placement identifier. The description item includes the placement identifier, RUH associated state content, placement generation, state effective flag, and reference count. The state owner converts RUH update commands, RUH implicit switching events, and controller state rebuild events that cause the RUH associated state to be re-established into RUH associated state change requests for the same placement identifier, and processes them serially in the order of arrival. When the target RUH association state content is inconsistent with the current RUH association state content, a new RUH association state description item is created for the changed RUH association state, and the new placement generation is generated incrementally based on the maximum value among the current active placement generation set, the historical placement generation set that has not yet been recycled, and the generation starting reference value.

9. The asynchronous verification method for SSD firmware front-end queue injection according to claim 8, characterized in that, After the new placement generation is generated, the state owner will change the RUH associated state description item before the change from the current state to the historical reserved state, and set the changed RUH associated state description item as the current state. When a command context completes the publication of a command-level placement snapshot, the state owner increments the command context reference count for the corresponding placement generation; when the command context is transferred to the released state, the command context reference count is decremented. When a placement status record is published, the reference count of the placement status record for the corresponding placement generation is increased. When the placement status record is consumed by the test side, written to an abnormal state, or overwritten by the record corresponding to the subsequent observation sequence number, the reference count of the placement status record is decreased. The total number of unclosed references is obtained by summing the command context reference count and the placement state record reference count. The state owner will reclaim the corresponding historical RUH associated state description only when the total number of unclosed references is zero.

10. The asynchronous verification method for SSD firmware front-end queue injection according to any one of claims 1 to 9, characterized in that, The test side establishes a sticky failure state to save the abnormalities of this test; When a controller reset, command timeout, command cancellation, or front-end queue reconstruction occurs, the command generation or queue generation used before the change will be marked as an invalid generation. The test side synchronously writes objects that enter an abnormal state during the test into the sticky failure state. Perform a combined drain after the test script stops generating new test requests; A test pass result is generated when all command contexts have ended their current lifecycles, all published placement state records in the read-only observation interface have been consumed, there are no unclosed references in the historical placement generations, and no exceptions are recorded in the sticky failure state; otherwise, a test failure result is generated.

Images