nvme/nvmf: Add NVME_GET_CONTROLLER_DATA ioctl to fetch cached cdata

[jhb]

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.

Sponsored by: Chelsio Communications

[imp]

sbin/nvmecontrol/nvmecontrol.c

103 ↗

(On Diff #148443)

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

1111

Copyout maybe?

[jhb]

sbin/nvmecontrol/nvmecontrol.c

103 ↗

(On Diff #148443)

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

1111

It's an ioctl, the buffer is already in kernel memory.

[imp]

sys/dev/nvmf/host/nvmf.c

1111

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?

[jhb]

sys/dev/nvmf/host/nvmf.c

1111

No, 4k is smaller than IOCPARAM_MAX (8k).

[jhb]

Drop nvmecontrol change

[jhb]

Ping