Page MenuHomeFreeBSD

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

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 and use it in nvmecontrol(8)
to read the cdata. nvmecontrol(8) will still fall back to using a
pass-through command if the new ioctl fails.

This is primarily useful for allowing certain commands like 'devlist'
to work against a disconnected Fabrics host.

Sponsored by: Chelsio Communications

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 requested review of this revision.Fri, Dec 27, 8:29 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?

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.

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?