Page MenuHomeFreeBSD

nvme_sim: Attach as a child of nvme
Needs ReviewPublic

Authored by imp on Jul 17 2025, 7:51 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Oct 9, 5:28 AM
Unknown Object (File)
Sep 14 2025, 11:02 AM
Unknown Object (File)
Sep 12 2025, 10:01 AM
Unknown Object (File)
Sep 3 2025, 4:26 PM
Unknown Object (File)
Aug 5 2025, 2:40 AM
Unknown Object (File)
Jul 29 2025, 5:25 AM
Unknown Object (File)
Jul 28 2025, 2:27 PM
Unknown Object (File)
Jul 28 2025, 2:52 AM
Subscribers

Details

Summary

Rather than registering as a consumer of the nvme controller, hook into
the child device and use that.

This is a small regression at the moment: we don't fail the device when
that happens at runtime, and we don't handle new namespaces when they
arrive (though that feature is currently fragile).

Sponsored by: Netflix

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 65530
Build 62413: arc lint + arc unit

Event Timeline

sys/dev/nvme/nvme_sim.c
374

Have you thought about defining a nvme_if.m and having a nvme_ns_changed DEVMETHOD? You could then handle enumerating namespaces in the controller driver and just invoke the method in the child device each time a namespace changes.

(FWIW, nvmf(4) does handle namespaces coming and going dynamically using an AER to notice when a namespace changes. It works in that you can use ctladm to add new LUNs on the fly on the target side, and the FreeBSD nvmf client will notice the new namespace.)

I also don't understand the regression described in the commit message. (What do you mean by "that" in "failing devices when that happens at runtime"? Is "that" an AER, is it an I/O error, completion timeout?)

BTW, should this mean that you can kldunload nvme_sim and then kldload nvd to switch from nda to nvd? Or adjust the tunable in kenv and then do a 'devctl detach/attach' of the device? (Granted, I don't think devctl can name this device for attach to work)

In D51384#1175594, @jhb wrote:

I also don't understand the regression described in the commit message. (What do you mean by "that" in "failing devices when that happens at runtime"? Is "that" an AER, is it an I/O error, completion timeout?)

BTW, should this mean that you can kldunload nvme_sim and then kldload nvd to switch from nda to nvd? Or adjust the tunable in kenv and then do a 'devctl detach/attach' of the device? (Granted, I don't think devctl can name this device for attach to work)

This commit regresses calling the failure callback that the 'consumer' interface has when the controller fails (and calls the right failure routine). One could, in theory, attach different types of nda / nvd devices after this change, but I've not tested to see if it breaks things... nvme_sim isn't a loadable module, it's co-located in the nvme module when cam is enabloed. These things should be possible, but are not likely to be seamless just yet..

sys/dev/nvme/nvme_sim.c
374

There's a future review that does exactly this sort of thing.

nvd doesn't handle dynamic namespaces at all... That future change will allow them to arrive.
nda allows them to come, but not depart or change

sys/dev/nvme/nvme_sim.c
374

Hmm, nda handles it fine for me with nvmf when I've tested it. At least removing devices does work.

sys/dev/nvme/nvme_sim.c
374

Hmmm, reading the code suggests it shouldn't...
But maybe I fixed this case better than I'd thought when I was working on dynamic namespace support.... Adding works I know, and removing and adding back kinda works... I didn't think I had all the kinks out of simply removing though.