src/sys/dev/nvme, branch mainFreeBSD source treehttps://cgit-dev.freebsd.org/src/atom?h=main2026-03-30T09:24:34Znvme_sim: Fix name in module version metadata2026-03-30T09:24:34ZOlivier Certnerolce@FreeBSD.org2026-03-30T09:17:04Zurn:sha1:e220af9cee74082841db9e80cbb73f570f3a570f
MFC after: 1 week
Fixes: 1e39b5d4833e ("nvme_sim: Attach as a child of nvme")
Sponsored by: The FreeBSD Foundation
nvme: Replace bus_space_[read|write]_4 with bus_[read|write]_42026-03-16T17:38:27ZMatt Delcodelco@google.com2026-03-10T20:12:56Zurn:sha1:889d10d5b12050b4b3923917b5edeac85e8ca706
The goal this change is to remove the use of the tag and handle
needed by bus_space_[read|write]_4.
Fixes: b3d9e5013f3e5 (Don't active memory space)
Requested by: jhb
Reviewed by: gallatin, imp, jhb, jrtc27
Differential Revision: https://reviews.freebsd.org/D55818
nvme: Removed unused 'regs' variable2026-03-16T17:37:46ZMatt Delcodelco@google.com2026-03-10T19:30:51Zurn:sha1:4e3beef84628ce6dfea7f053cddf3289fddf7794
The private struct has a 'regs' member that's only written to
and otherwise unused. This change removes it.
Fixes: b3d9e5013f3e5 (Don't active memory space)
Requested by: jhb
Reviewed by: imp, jhb, jrtc27
Differential Revision: https://reviews.freebsd.org/D55817
nvme: Don't active memory space until all BARs are configured2026-03-06T17:28:41ZMatt Delcodelco@google.com2026-03-06T17:23:03Zurn:sha1:b3d9e5013f3e5016ffbd3d3d6091194658af2b92
In the current current behavior the 2nd and 3rd BARs can be activated
when they're configured with address zero. This change defers the
activation of all BARs until after they've all been configured with an
address.
This enables FreeBSD on Google Compute Engine C4-LSSD Machines.
Sponsored by: Google
Tested by: NetApp (previous version)
Reviewed by: gallatin, imp
Discussed with: jrtc27 (improved error reporting)
Differential Revision: https://reviews.freebsd.org/D55541
nvme_sim: Fix a cut and paste error2026-03-03T17:59:42ZWarner Loshimp@FreeBSD.org2026-03-03T17:59:42Zurn:sha1:244ae85eb97548fd81783f079ee26e0aa9f4b984
Fix the error message in nvme_sim_ns_removed that was cut and pasted
from nvme_sim_ns_changed to reflect its new home. No functional change.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D55522
chore: replace {0, 0} with {DEV,KOBJ}METHOD_END2026-02-25T05:59:34ZEnji Cooperngie@FreeBSD.org2026-02-21T06:14:46Zurn:sha1:0fc6c3f731a2cca3120798806c330a3081c9424b
Both of the aforementioned macros have been present in FreeBSD
for well over a decade: 2009 for `KOBJMETHOD_END`; 2011 for
`DEVMETHOD_END`.
Adapt all hardcoded references of `{0, 0}` with `DEVMETHOD_END`
and `KOBJMETHOD_END` as appropriate. This helps ensure that
future adaptations to drivers following patterns documented
in driver(9) can be made more easily/without issue.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D55414
nvme: Fix sim unit number to match nvme device2026-02-18T16:40:06ZWarner Loshimp@FreeBSD.org2026-02-17T21:08:46Zurn:sha1:8aa560491cfad7953c7c089f4847951e867ef47c
The CAM sim unit numbner should match the nvme device number. We need
this to match unit numbers in some wiring scenarios. For example:
hint.nvme.0.at="UEFI:PciRoot(0x3)/Pci(0x1,0x1)/Pci(0x0,0x0)"
hint.nvme.1.at="UEFI:PciRoot(0x3)/Pci(0x1,0x2)/Pci(0x0,0x0)"
hint.nvme.2.at="UEFI:PciRoot(0x3)/Pci(0x1,0x3)/Pci(0x0,0x0)"
hint.nvme.3.at="UEFI:PciRoot(0x3)/Pci(0x1,0x4)/Pci(0x0,0x0)"
hint.scbus.33.at="nvme0"
hint.nda.0.at="scbus33"
hint.scbus.34.at="nvme1"
hint.nda.1.at="scbus34"
hint.scbus.35.at="nvme2"
hint.nda.2.at="scbus35"
hint.scbus.36.at="nvme3"
hint.nda.3.at="scbus36"
If the devices that are nvme0 and nvme3 are the only ones populated, you
still want them associated with nda0 and nda3.
The nvme_sim device changes meant we were passing the wrong device's
unit number to cam_sim_alloc. This fixes the problem.
Sponsored by: Netflix
nvme: fix panic if we boot w/o a namespace2026-02-18T16:39:28ZWarner Loshimp@FreeBSD.org2026-02-17T08:00:34Zurn:sha1:c8d63d63679fc0d8a67b33499a2a2edd444c8e2e
If we format a drive, and then crash, we'll come back up. nvme_sim_ns
device won't attach because we don't have a namespace. Some drives (all?
I couldn't find it in the standard) send an AER with a namespace change,
which causes a NULL dereference because s_sim wasn't initialized because
we didn't attach. So, if we get into the ns_changed routine, bail early
if we didn't attach. We'll attach later, and deal with the ns correctly
if it's really there, or not attach one if it's not.
Sponsored by: Netflix
nvme: Use size_t for payload size2026-02-13T18:37:16ZDag-Erling Smørgravdes@FreeBSD.org2026-02-13T18:37:07Zurn:sha1:be7e4dc878eab090cd411c9ef28880e4f62116f5
Using uint32_t here can cause spurious compiler warnings. I assume it
was done to constrain the range; use a KASSERT instead.
Sponsored by: Klara, Inc.
Sponsored by: NetApp, Inc.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D55279
nvme: Change fail_on_reset to bool2026-02-13T12:34:51ZDag-Erling Smørgravdes@FreeBSD.org2026-02-13T12:34:42Zurn:sha1:1e2eea55c4559544b68c99e95641097983230611
This is safe since sysctl_handle_bool() handles ints transparently.
Sponsored by: Klara, Inc.
Sponsored by: NetApp, Inc.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D55263