Handful of nits, but overall, LGTM!

amazeballs!

LGTM

Not familiar with this driver, but the changes look OK to me.

LGTM, but I'll give other folks a chance to peek

Updated per review comments

When nda turns off reporting, how are pass-through commands treated? Will this change suppress errors from those commands as well?

If you are looking to add more flag values, I'd move this to after retries and change the type to uint32_t or uint16_t if you think more might be needed in the future.

I like @jhb 's table approach but would prefer the shorter string (i.e., RESERVATION REGISTER vs NVME_OPC_RESERVATION_REGISTER

Tested with smart(8) and all looks good:

# ./smart -d nda0
Critical Warning        0       0
Composite Temperature   1       316
Available Spare 3       100
Available Spare Threshold       4       5
Percentage Used 5       0
Data Units Read 32      1524527
Data Units Written      48      2582739
Host Read Commands      64      22258691
Host Write Commands     80      26153957
Controller Busy Time    96      36
Power Cycles    112     483
Power On Hours  128     2564
Unsafe Shutdowns        144     242
Media and Data Integrity Errors 160     0
Number of Error Information Log Entries 176     373
#

In D41119#936246, @jhb wrote:

Would you be able to test it easily? :)

In D41058#935594, @imp wrote:

...
nvme_qpair.c grew unfortunate knowledge of ccb's after I did the initial nvme sim work. Although I committed it, chuck tuffli did the the work to add CAM_DATA_SG support to the pass driver for nvme, where we have to load a dmamap for that operation (so normal I/O doesn't use it, but this new, special I/O through pass does use it). This was fine while the bus_dmamap_load_ccb was inside of subr_busdma, but when it moved to cam, it was no longer fine, but the liability we're talking about now.

FWIW, I was able to boot an Alma Linux VM with this change

If the transport variable mirrors the Fabric types (i.e., PCIe, RDMA, TCP, FC), this makes sense to me as there are differences (like shown here with the PCIe lane count / speeds) between the -oF transports.

Other than minor nit, LGTM

LGTM but I'm also curious if @corvink suggestion of %u helps

These changes are good but not really necessary from a functionality point of view. In both cases, the emulation is returning an error, making the LID undefined from the guest's perspective. But I'm all for good hygiene.

LGTM

I see what you are saying. Unfortunately, I can't figure out how to remove the "revisions requested" status.

The existing code isn't quite right, but I'm not quite sure what to do here. The number of firmware slots should not ever be zero (i.e., "This field shall specify a value from one to seven"), and my guess is, for most drives, this condition will always be true. Perhaps removing the check and unconditionally printing the slot count and RO status makes more sense as the field description (e.g., "Number of Firmware Slots") are always present.