nvme/nvmf: Add NVME_GET_CONTROLLER_DATA ioctl to fetch cached cdata
Needs ReviewPublic
Actions

Authored by jhb on Fri, Dec 27, 8:29 PM.

Details

Reviewers

imp
chuck

Summary

Both nvme and nvmf cache a copy of the controller's identify data in
the softc. Add an ioctl to fetch this copy of the cdata. This is
primarily useful for allowing commands like 'devlist' to work against
a disconnected Fabrics host.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 61357
Build 58241: arc lint + arc unit

Event Timeline

jhb created this revision.Fri, Dec 27, 8:29 PM

Herald added a subscriber: dab. · View Herald TranscriptFri, Dec 27, 8:29 PM

jhb requested review of this revision.Fri, Dec 27, 8:29 PM

Harbormaster completed remote builds in B61357: Diff 148443.Fri, Dec 27, 8:29 PM

jhb added a child revision: D48219: nvmf: Add NVMF_CONNECTION_STATUS ioctl.Fri, Dec 27, 8:29 PM

imp added inline comments.Fri, Dec 27, 8:46 PM

sbin/nvmecontrol/nvmecontrol.c
103	Maybe it uglifies the code, but do we want to have a force a pass through command option and path? It would be useful for debugging in case ident changes and the driver fails to update its cache.
sys/dev/nvme/nvme_ctrlr.c
1447	Copyout maybe?
sys/dev/nvmf/host/nvmf.c
1059	Copyout maybe?

jhb added inline comments.Fri, Dec 27, 8:54 PM

sbin/nvmecontrol/nvmecontrol.c
103	I wondered if there were cases where we would want to always use pass through or not. I could instead restructure the devlist handler to use this ioctl in the case that a fabrics controller is disconnected and leave this path as-is. It wasn't clear to me if there were any cases where the cdata could change or if it was effectively read-only.
sys/dev/nvmf/host/nvmf.c
1059	It's an ioctl, the buffer is already in kernel memory.

imp added inline comments.Fri, Dec 27, 9:33 PM

sys/dev/nvmf/host/nvmf.c
1059	It's a pointer that's copied into the kernel with the usual ioctl routine. The ident size is bigger than can be encoded on the ioctl cmd. So memcpy works because the kernel and user space are mapped at rhe same time on x86_64. Or am I missing something?