)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"0f6e632238b0b5012d7e343ad6430918c8ed6ae5","unresolved":false,"context_lines":[{"line_number":1,"context_line":"Parent:     9fba9d7f (pci-sim: introduce personality ops-table dispatch for VF device types)"},{"line_number":2,"context_line":"Author:     Chandan Kumar (raukadah) \u003cchkumar@redhat.com\u003e"},{"line_number":3,"context_line":"AuthorDate: 2026-08-06 10:44:42 +0530"},{"line_number":4,"context_line":"Commit:     Chandan Kumar (raukadah) \u003cchkumar@redhat.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":14,"id":"6daa389f_5225ff52","line":1,"updated":"2026-08-18 08:07:55.000000000","message":"The commit message advertises \u0027oacs bit 3 for namespace management\u0027 among the controller capabilities. The Identify Controller data sets OACS \u003d 0x0022 (bits 1 and 5; bit 3 clear) in pci_sim_nvme_fill_identify_ctrl(), and the admin dispatcher implements no namespace-management commands (Create/Delete/Attach/Detach Namespace) — such opcodes fall through to INVALID_OPCODE. Bit 5 is advertised without any corresponding feature, and the adjacent code comment \u0027OACS: Format + Sanitize\u0027 does not match the value either.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: The permanent change history misstates the emulated capabilities; a spec-conformant host reading OACS bit 3 would correctly decline, but any reader trusting the commit message (or the bit-5 advertisement) expects namespace management/directives support that returns errors. Low runtime impact, but the stated intent contradicts the implementation.\n\n**Suggestion**:\nDrop the \u0027oacs bit 3 for namespace management\u0027 bullet from the commit message (or actually set bit 3 and implement the namespace-management admin commands), and correct the OACS value/comment so only implemented capabilities (Format, and whatever is intended by bit 5) are advertised.","commit_id":"d5c6e164d1ef30afc7d4a96e3dbd1adf9dc79fe4"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3f1619780058af2dc79e93fd0fb3d294ce4ca79e","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":22,"id":"2716bd47_038fd400","updated":"2026-08-26 19:25:29.000000000","message":"i have not done a full review of this just commentign that the pci-sim supprot is not fucntional as implmeted in the top patch in the serse and the issue seams to be in the msix suppprot advertized but not implmented in this patch","commit_id":"e8ab207f032cf2778beb34ac6bdcecea9df54d2c"},{"author":{"_account_id":12393,"name":"chandan kumar","display_name":"Chandan Kumar","email":"chkumar@redhat.com","username":"chkumar246"},"change_message_id":"f6ee2470fd12a0ad5c7351840979285b69e9db98","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":27,"id":"0cf7c63b_398c6448","updated":"2026-09-07 05:35:40.000000000","message":"recheck","commit_id":"797d4ff09639a1b281ec01b1d4967dec518b17ab"}],"doc/source/contributor/pci-sim/developer-guide.rst":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"bd50f149faac711ecb3a3f00a3b57ae3dff2fa56","unresolved":false,"context_lines":[{"line_number":784,"context_line":"   * - ``nvme_backing_file``"},{"line_number":785,"context_line":"     - (none)"},{"line_number":786,"context_line":"     - Path prefix for NVMe backing files (per-VF: ``\u003cprefix\u003e.\u003cindex\u003e``)."},{"line_number":787,"context_line":"   * - ``vf_serial_class``"},{"line_number":788,"context_line":"     - false"},{"line_number":789,"context_line":"     - Expose UART VFs as PCI serial/16550 class instead of vendor-specific."},{"line_number":790,"context_line":"   * - ``vfio_guest_8250_compat``"}],"source_content_type":"text/x-rst","patch_set":4,"id":"afb86b1e_cdbe7cb2","line":787,"updated":"2026-08-09 06:51:46.000000000","message":"The developer guide\u0027s module parameters table includes vf_serial_class with default \u0027false\u0027, described as \u0027Expose UART VFs as PCI serial/16550 class instead of vendor-specific.\u0027 This parameter does not exist in the module code. The actual mechanism for serial class exposure is handled by init_vf_...\n\n**Severity**: SUGGESTION | **Confidence**: 0.8\n\n**Benefit**: Users and maintainers will look for a vf_serial_class module parameter that does not exist and cannot configure the behavior it claims to control.\n\n**Recommendation**:\nRemove the vf_serial_class entry from the module parameters table. If serial class configuration is a desired feature, add the actual module parameter and implementation first.","commit_id":"a01f2d2be561ee8fc6b08fdce89d6946a71ad2dc"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"bd50f149faac711ecb3a3f00a3b57ae3dff2fa56","unresolved":false,"context_lines":[{"line_number":1029,"context_line":"  init, and BAR dispatch use this pointer instead of calling"},{"line_number":1030,"context_line":"  device-specific functions directly."},{"line_number":1031,"context_line":""},{"line_number":1032,"context_line":"``host-\u003ehost_data`` (``void *``)"},{"line_number":1033,"context_line":"  Opaque per-PF personality state.  Each personality allocates its own"},{"line_number":1034,"context_line":"  private struct in ``host_init`` and stores a pointer here; a typed"},{"line_number":1035,"context_line":"  accessor (e.g. ``pci_sim_nvme_get_host_data(host)``) casts it back in"}],"source_content_type":"text/x-rst","patch_set":4,"id":"4e4a29cd_d373168d","line":1032,"updated":"2026-08-09 06:51:46.000000000","message":"The developer guide added in this commit describes host-\u003ehost_data as an opaque per-PF personality state pointer with a typed accessor pci_sim_nvme_get_host_data(host). Neither this field nor the accessor function exists in the code. The NVMe personality stores its state directly in host-\u003envme_st...\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Maintainers following the guide to add a new VF personality will look for a host_data field and typed accessor that do not exist, wasting time and potentially introducing incorrect code patterns.\n\n**Suggestion**:\nRemove the host-\u003ehost_data description from the developer guide. Document the actual pattern: NVMe personality state is stored directly in host-\u003envme_state[] and accessed by indexing the array. For new personalities, either add a dedicated field to struct fake_pci_host or document the union approach used in pci_sim_vfio_vf.","commit_id":"a01f2d2be561ee8fc6b08fdce89d6946a71ad2dc"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"bd50f149faac711ecb3a3f00a3b57ae3dff2fa56","unresolved":false,"context_lines":[{"line_number":1381,"context_line":"#. Create ``fake_pci_sriov_\u003cname\u003e.c`` with a"},{"line_number":1382,"context_line":"   ``const struct pci_sim_personality_ops pci_sim_\u003cname\u003e_ops`` instance."},{"line_number":1383,"context_line":"   Fill in at least ``name``, ``device_id``, ``pci_class``, and"},{"line_number":1384,"context_line":"   ``vfio_state_size``.  Implement the ops callbacks the personality needs:"},{"line_number":1385,"context_line":"   ``host_init``/``host_fini`` for per-PF state (allocate a private struct"},{"line_number":1386,"context_line":"   and store in ``host-\u003ehost_data``), ``sriov_enable``/``sriov_disable``"},{"line_number":1387,"context_line":"   for VF lifecycle, and ``bar_rw``, ``config_overlay``, ``get_bar_info``,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"b6f0539a_1fc379f4","line":1384,"updated":"2026-08-09 06:51:46.000000000","message":"The developer guide\u0027s \u0027Add a new VF personality\u0027 checklist still tells developers to fill in vfio_state_size in the ops struct, but this field was removed from struct pci_sim_personality_ops in the same commit. The personality state is now handled via a union in pci_sim_vfio_vf. Two separate refe...\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: A developer following the personality extension checklist will try to set a non-existent field and will not understand the actual union-based state allocation mechanism.\n\n**Suggestion**:\nReplace the vfio_state_size references with a description of the actual mechanism: personality state is allocated as a union member in struct pci_sim_vfio_vf (see uart/nvme union), and pci_sim_vfio_state() in fake_pci_sriov_vfio.c returns the typed pointer.","commit_id":"a01f2d2be561ee8fc6b08fdce89d6946a71ad2dc"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"dd8eae7587132645990f464e644baf7a13ff9733","unresolved":false,"context_lines":[{"line_number":200,"context_line":"code ``0108`` but have no real memory behind BAR0. The stock ``nvme`` driver"},{"line_number":201,"context_line":"cannot bind (``pci_request_mem_regions`` fails). The custom"},{"line_number":202,"context_line":"``pci_sim_nvme_host`` driver binds instead and creates"},{"line_number":203,"context_line":"``/dev/pci_sim_nvmeN`` character devices for ``nvme-cli`` commands. This mode"},{"line_number":204,"context_line":"works in both VMs and bare metal and requires no kernel boot parameters."},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"**memmap mode** is the most capable but least portable. It requires a"}],"source_content_type":"text/x-rst","patch_set":24,"id":"0d8bcc05_668cbe90","line":203,"updated":"2026-09-03 18:53:50.000000000","message":"The new developer-guide and testing docs repeatedly describe the host char device as /dev/pci_sim_nvmeN (developer-guide.rst:190,203,271,286; testing.rst:89), and developer-guide.rst:203 says nvme-cli commands run against \u0027/dev/pci_sim_nvmeN character devices\u0027. The implementation registers the node as plain \u0027nvme%d\u0027 via device_create(..., \"nvme%d\", dev-\u003eid) with the class \u0027pci_sim_nvme\u0027, so the actual node is /dev/nvme0. The doc table at developer-guide.rst:271 even contrasts \u0027pci_sim_nvmeN char device\u0027 with the stock-driver \u0027/dev/nvmeN block device\u0027, which contradicts the code and the script (test_pci_sim_nvme_host.sh uses /dev/nvme0).\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: A contributor or CI author following the docs looks for /dev/pci_sim_nvme0, finds nothing, and cannot run the documented nvme-cli workflow; it also hides the /dev/nvmeN collision issue.\n\n**Suggestion**:\nPick one name and make code and docs agree: either rename the node to pci_sim_nvme%d (recommended, also resolves CF-003) or update the docs to /dev/nvmeN.","commit_id":"d9e746e72fe4d754603b5cc20a4b99609e981c96"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"a0f3dbcff174a9307f0fccc959174a336507ecf4","unresolved":false,"context_lines":[{"line_number":200,"context_line":"code ``0108`` but have no real memory behind BAR0. The stock ``nvme`` driver"},{"line_number":201,"context_line":"cannot bind (``pci_request_mem_regions`` fails). The custom"},{"line_number":202,"context_line":"``pci_sim_nvme_host`` driver binds instead and creates"},{"line_number":203,"context_line":"``/dev/pci_sim_nvmeN`` character devices for ``nvme-cli`` commands. This mode"},{"line_number":204,"context_line":"works in both VMs and bare metal and requires no kernel boot parameters."},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"**memmap mode** is the most capable but least portable. It requires a"}],"source_content_type":"text/x-rst","patch_set":26,"id":"4d7f02b2_dddad2b3","line":203,"updated":"2026-09-04 08:33:39.000000000","message":"developer-guide.rst (lines 190, 203, 271, 286) and testing.rst (line 89) describe the host character device as /dev/pci_sim_nvmeN. The implementation calls device_create(pci_sim_nvme_host_class, ..., \"nvme%d\", dev-\u003eid), so the device node is /dev/nvmeN; only the chrdev region and class are named \u0027pci_sim_nvme\u0027 (visible in /proc/devices and /sys/class). The commit message itself says the driver \u0027registers /dev/nvmeN\u0027, and test_pci_sim_nvme_host.sh checks /dev/nvme$i.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Operators following the docs look for /dev/pci_sim_nvmeN, find nothing, and may conclude Phase 1 failed; the confusion is amplified because /dev/nvmeN is also the name the stock nvme driver uses in Phase 2, so the docs\u0027 only distinction between phases is wrong.\n\n**Suggestion**:\nUpdate developer-guide.rst and testing.rst to use /dev/nvmeN for the Phase 1 char device (optionally noting the class/chrdev name \u0027pci_sim_nvme\u0027 in /proc/devices to disambiguate from the stock driver).","commit_id":"dd700467f638287da18ba08c9bdce22f1f0dd047"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"6d9fb80205038548d9da0966a54d9907a86e0482","unresolved":false,"context_lines":[{"line_number":1137,"context_line":"In NVMe stock-driver mode (with ``memmap\u003dSIZE$START`` kernel boot parameter"},{"line_number":1138,"context_line":"and ``nvme_memmap_start``/``nvme_memmap_size`` module parameters):"},{"line_number":1139,"context_line":""},{"line_number":1140,"context_line":"#. At module load, reserved memory is mapped with ``memremap(MEMREMAP_WT)``."},{"line_number":1141,"context_line":"#. ``pci_sim_nvme_host`` returns ``-ENODEV`` so it does not bind."},{"line_number":1142,"context_line":"#. When VFs are enabled, ``sriov_configure`` calls"},{"line_number":1143,"context_line":"   ``pci_sim_nvme_poll_preinit_vfs()`` which pre-initializes NVMe state and"}],"source_content_type":"text/x-rst","patch_set":28,"id":"88b996bb_f04a4c9a","line":1140,"updated":"2026-09-07 16:57:30.000000000","message":"The new Phase 2 flow documentation states \u0027At module load, reserved memory is mapped with memremap(MEMREMAP_WT)\u0027 (developer-guide.rst:1140) and that IRQ injection uses \u0027msi_get_virq() -\u003e irq_get_irq_data() -\u003e chip-\u003eirq_retrigger()\u0027 (line 1158; also 920). The actual code maps with ioremap() inside pci_sim_nvme_host_init() (fake_pci_sriov_nvme.c:1355-1362), which runs during the vf_personality sysfs write, not at module load, and injects IRQs with generic_handle_irq_safe(virq) (fake_pci_sriov_nvme_poll.c:48).\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Contributors debugging BAR0 mapping or interrupt delivery follow the wrong mechanism and the wrong lifecycle point (module load vs sysfs personality write), which is exactly the knowledge needed to diagnose why the poll path is inert.\n\n**Suggestion**:\nUpdate the two flow bullets to describe ioremap() performed in host_init during the vf_personality sysfs store and generic_handle_irq_safe() injection.","commit_id":"ec86791c7f606998a376188efbffaa4506ab92cf"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"d71464234cca034a647f629acf77559699bca9d6","unresolved":false,"context_lines":[{"line_number":793,"context_line":"   * - ``vfio_uart_trace``"},{"line_number":794,"context_line":"     - false"},{"line_number":795,"context_line":"     - Trace VFIO BAR0 UART register accesses."},{"line_number":796,"context_line":"   * - ``fake_intx_irq``"},{"line_number":797,"context_line":"     - 0"},{"line_number":798,"context_line":"     - Optional host IRQ number for fake PCI INTx routing (0 disables)."},{"line_number":799,"context_line":"   * - ``mem_base``"}],"source_content_type":"text/x-rst","patch_set":29,"id":"fa5a0dbe_ce8b6a3b","line":796,"updated":"2026-09-08 10:47:11.000000000","message":"The module-parameter reference table added to developer-guide.rst includes a row for fake_intx_irq (\u0027Optional host IRQ number for fake PCI INTx routing (0 disables)\u0027). This same commit deletes the fake_intx_irq module parameter from fake_pci_sriov_core.c and makes fake_pci_map_irq() return -1 unconditionally. The added documentation therefore describes a parameter that no longer exists after this change; following the new guide (e.g. insmod fake_pci_sriov.ko fake_intx_irq\u003dN) fails with \u0027Unknown parameter\u0027 and misleads operators about INTx support.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Operator-facing documentation contradicts the shipped module; users following the guide pass a nonexistent parameter and get a load failure, and are told INTx routing is configurable when it is not.\n\n**Suggestion**:\nDelete the fake_intx_irq row from the module-parameter table (and note that fake_pci_map_irq() returns -1 unconditionally, so INTx routing is not supported), or reinstate the parameter if removal was unintentional.","commit_id":"dff1cc943141d7f15518107f29e958bd829edfd9"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"8532d53823b705d2307eb3d086681401a75f6479","unresolved":false,"context_lines":[{"line_number":200,"context_line":"code ``0108`` but have no real memory behind BAR0. The stock ``nvme`` driver"},{"line_number":201,"context_line":"cannot bind (``pci_request_mem_regions`` fails). The custom"},{"line_number":202,"context_line":"``pci_sim_nvme_host`` driver binds instead and creates"},{"line_number":203,"context_line":"``/dev/pci_sim_nvmeN`` character devices for ``nvme-cli`` commands. This mode"},{"line_number":204,"context_line":"works in both VMs and bare metal and requires no kernel boot parameters."},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"**memmap mode** is the most capable but least portable. It requires a"}],"source_content_type":"text/x-rst","patch_set":31,"id":"ad6c03b4_253f384d","line":203,"updated":"2026-09-09 05:39:42.000000000","message":"developer-guide.rst (several places), the command-support table, and testing.rst refer to the Phase 1 char device as /dev/pci_sim_nvmeN. pci_sim_nvme_host_probe() calls device_create(pci_sim_nvme_host_class, ..., \"nvme%d\", dev-\u003eid), so the devtmpfs node is /dev/nvmeN, as test_pci_sim_nvme_host.sh itself verifies (\u0027test -c /dev/nvme$i\u0027).\n\n**Severity**: SUGGESTION | **Confidence**: 0.85\n\n**Impact**: Developers looking for /dev/pci_sim_nvmeN will not find the device and may conclude the driver failed to register; the name is also easy to confuse with the real stock-driver /dev/nvmeN path the docs intentionally distinguish.\n\n**Recommendation**:\nUpdate the developer-guide and testing.rst references to /dev/nvmeN (created by the pci_sim_nvme_host driver), or rename the device_create() node format to pci_sim_nvme%d if a distinct node name is preferred (then update the test script).","commit_id":"984f55716b417da2056c1c601ddd4ced9333fe72"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"b9da9f1b1a37991ff229b02fe09aa5f4532567e6","unresolved":false,"context_lines":[{"line_number":793,"context_line":"   * - ``vfio_uart_trace``"},{"line_number":794,"context_line":"     - false"},{"line_number":795,"context_line":"     - Trace VFIO BAR0 UART register accesses."},{"line_number":796,"context_line":"   * - ``fake_intx_irq``"},{"line_number":797,"context_line":"     - 0"},{"line_number":798,"context_line":"     - Optional host IRQ number for fake PCI INTx routing (0 disables)."},{"line_number":799,"context_line":"   * - ``mem_base``"}],"source_content_type":"text/x-rst","patch_set":32,"id":"6424b530_00b8a2b1","line":796,"updated":"2026-09-09 06:58:35.000000000","message":"The change deletes the fake_intx_irq module parameter from fake_pci_sriov_core.c (module_param and desc removed; fake_pci_map_irq now returns -1 unconditionally), but the developer-guide module-parameter table updated in the same change still lists \u0027fake_intx_irq - 0 - Optional host IRQ number to report for fake PCI INTx routing\u0027.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Operators following the docs will pass fake_intx_irq\u003dN at insmod and get \u0027unknown parameter\u0027 rejection, or believe INTx routing is configurable when it is not.\n\n**Suggestion**:\nDelete the fake_intx_irq row from the module-parameter table in developer-guide.rst (and check overview.rst/README for the same stale reference).","commit_id":"346c240b00496988cb10b651472020e1f21b3537"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"bb9b000f0a0673e1493a0b07e6a388d7a32f4fd2","unresolved":false,"context_lines":[{"line_number":200,"context_line":"code ``0108`` but have no real memory behind BAR0. The stock ``nvme`` driver"},{"line_number":201,"context_line":"cannot bind (``pci_request_mem_regions`` fails). The custom"},{"line_number":202,"context_line":"``pci_sim_nvme_host`` driver binds instead and creates"},{"line_number":203,"context_line":"``/dev/pci_sim_nvmeN`` character devices for ``nvme-cli`` commands. This mode"},{"line_number":204,"context_line":"works in both VMs and bare metal and requires no kernel boot parameters."},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"**memmap mode** is the most capable but least portable. It requires a"}],"source_content_type":"text/x-rst","patch_set":33,"id":"848f94ab_33a65f18","line":203,"updated":"2026-09-09 15:26:55.000000000","message":"The new developer-guide and testing sections repeatedly tell users the Phase-1 host character device is /dev/pci_sim_nvmeN, but pci_sim_nvme_host_probe() calls device_create(..., \"nvme%d\", dev-\u003eid), which registers /dev/nvme0, /dev/nvme1, etc. A contributor following the docs will look for a device node that never appears and may conclude the probe failed.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Users and CI engineers following the contributor docs cannot find the documented device node and waste debugging time; the doc also masks the real (collision-prone) /dev/nvmeN naming (see CF-004).\n\n**Suggestion**:\nUpdate developer-guide.rst (lines 190, 203, 271, 286) and testing.rst:89 to say /dev/nvmeN, or rename the device node in the driver to /dev/pci_sim_nvmeN — but note the Cyborg sysfs-compat symlink rationale before changing the code.","commit_id":"ff0395aa92d19d85ae49c592b8bcdd0ad3801400"}],"doc/source/contributor/pci-sim/overview.rst":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"4a23e7d6624ff387761c870820cd7b4061ece3b9","unresolved":false,"context_lines":[{"line_number":22,"context_line":"Each PF exposes a ``vf_personality`` sysfs file that controls what type of"},{"line_number":23,"context_line":"VF device the PF creates, enabling mixed configurations on the same host."},{"line_number":24,"context_line":"PFs start with personality ``unset``; the user must assign a personality"},{"line_number":25,"context_line":"before the PF can create VFs.  Currently supported personalities are"},{"line_number":26,"context_line":"``uart``; additional types (e.g. NVMe, mdev) may be added in the future."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"The source currently lives under the top-level ``pci-sim/`` directory and is"}],"source_content_type":"text/x-rst","patch_set":6,"id":"57d33868_9951d5b5","line":25,"updated":"2026-08-11 18:09:20.000000000","message":"In doc/source/contributor/pci-sim/overview.rst, the bullet list at lines 13-21 correctly describes both uart and nvme personalities, but the following paragraph at lines 25-26 still says \u0027Currently supported personalities are uart; additional types (e.g. NVMe, mdev) may be added in the future.\u0027 T...\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Misleading documentation for contributors reading the overview. The bullet list above contradicts the paragraph below it.\n\n**Suggestion**:\nUpdate the sentence to reflect that both uart and nvme personalities are supported: \u0027Currently supported personalities are uart and nvme.\u0027","commit_id":"b751927859bfe9d6bee3a5d261abbfa308e69f07"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"2dcb3df0c9289d6b2e7bca0e0ea0e0eaf2a096e2","unresolved":false,"context_lines":[{"line_number":13,"context_line":"* **uart** (default): a 16550-style UART loopback.  That is enough to prove"},{"line_number":14,"context_line":"  that a VF assigned through VFIO is visible and usable inside an unmodified"},{"line_number":15,"context_line":"  guest such as CirrOS."},{"line_number":16,"context_line":"* **nvme**: an NVMe 1.4 controller emulation with file-backed storage.  The"},{"line_number":17,"context_line":"  guest sees a standard NVMe block device (``/dev/nvme0n1``) and can exercise"},{"line_number":18,"context_line":"  admin commands (Identify, Format NVM, Sanitize) and I/O commands"},{"line_number":19,"context_line":"  (Read, Write,"}],"source_content_type":"text/x-rst","patch_set":27,"id":"11fcb93b_9e43fd6c","line":16,"updated":"2026-09-05 05:58:42.000000000","message":"The rewritten overview lists two personalities (uart and nvme, lines 11-20) but the immediately following unchanged paragraph still states \u0027Currently supported personalities are ``uart``; additional types (e.g. NVMe, mdev) may be added in the future\u0027 (lines 24-26). After this commit the sentence is factually wrong, so the contributor doc contradicts the implemented behavior it sits next to.\n\n**Severity**: SUGGESTION | **Confidence**: 0.9\n\n**Impact**: Contributors reading the overview get contradictory information about which personalities exist, which can misdirect testing (e.g. skipping NVMe smoke tests) and erodes trust in the pci-sim docs.\n\n**Recommendation**:\nUpdate the paragraph at lines 24-26 to \u0027Currently supported personalities are ``uart`` and ``nvme``; additional types (e.g. mdev) may be added in the future.\u0027","commit_id":"797d4ff09639a1b281ec01b1d4967dec518b17ab"}],"doc/source/contributor/pci-sim/testing.rst":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"060042c30ba61f1ac162de1c49ef7bf81521b6c0","unresolved":false,"context_lines":[{"line_number":78,"context_line":""},{"line_number":79,"context_line":".. code-block:: console"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"   $ sudo bash pci-sim/run_nvme_vfio_guest_probe.sh"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"This downloads an Ubuntu cloud image, sets NVMe personality, creates a VF,"},{"line_number":84,"context_line":"binds it to VFIO, launches QEMU, and runs six guest checks automatically."}],"source_content_type":"text/x-rst","patch_set":15,"id":"3ad4af7a_7f3dc5cc","line":81,"updated":"2026-08-21 13:28:38.000000000","message":"doc/source/contributor/pci-sim/testing.rst instructs contributors to run \u0027sudo bash pci-sim/run_nvme_vfio_guest_probe.sh\u0027, and pci-sim/README.rst documents both run_nvme_vfio_guest_probe.sh and run_nvme_vfio_guest_probe.py as shipped helpers (\u0027Automated QEMU NVMe guest passthrough probe... runs six guest checks\u0027). Neither file exists anywhere in the repository - only the cirros variants (run_cirros_vfio_guest_probe.sh/.py) are present, and neither script is in the changed-files list.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Contributors following testing.rst hit \u0027No such file or directory\u0027 when trying the documented automated NVMe guest verification path, and the README inventory of test assets is inaccurate.\n\n**Suggestion**:\nEither add the missing run_nvme_vfio_guest_probe.sh/.py scripts (adapting the existing cirros probe scripts as the docs describe) or remove/adjust the references in testing.rst and README.rst to point at the manual QEMU/VFIO instructions that are already documented.","commit_id":"e75bcc46da049aeaab64e70f7d07d3fe48d90140"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3f1619780058af2dc79e93fd0fb3d294ce4ca79e","unresolved":true,"context_lines":[{"line_number":44,"context_line":"``uart`` personality, confirms personality changes are rejected while"},{"line_number":45,"context_line":"VFs are active, and validates that invalid personality names are rejected."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"NVMe guest verification"},{"line_number":48,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"NVMe testing requires a QEMU guest with the NVMe VF assigned through VFIO."}],"source_content_type":"text/x-rst","patch_set":22,"id":"f61a0c2c_33b0580b","line":47,"updated":"2026-08-26 19:25:29.000000000","message":"i have run both of these on centos 10 stream on a physical host and they both fail.\n\ni will try it again in a debian vm to see if this woudl work in ci but i think we reslly do need to fully implemnt virutual MSI-domain and interupts.","commit_id":"e8ab207f032cf2778beb34ac6bdcecea9df54d2c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b58f6c5e790155fa4a3cc5f1e5d750f923a524c","unresolved":true,"context_lines":[{"line_number":107,"context_line":".. code-block:: console"},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"   # Kernel boot parameter (add to grub/BLS):"},{"line_number":110,"context_line":"   memmap\u003d512M$7G"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"   # Module parameters (test script does this automatically):"},{"line_number":113,"context_line":"   $ sudo insmod pci-sim/fake_pci_sriov.ko \\"}],"source_content_type":"text/x-rst","patch_set":22,"id":"2f561971_b787117e","line":110,"updated":"2026-08-27 16:34:19.000000000","message":"ok i found the issue you also need to set intremap\u003doff\n\nalso when seting this in the grub command line you need to escape the dollar\n\nlike this\n```\n[stack@hibernal01 ~]$ sudo grubby --info\u003d$(sudo grubby --default-kernel)\nindex\u003d1\nkernel\u003d\"/boot/vmlinuz-6.12.0-260.el10.x86_64\"\nargs\u003d\"ro nofb quiet splash\u003dquiet default_hugepagesz\u003d1G hugepagesz\u003d1G hugepages\u003d4 hugepagesz\u003d2M hugepages\u003d1024 console\u003dttyS1,115200n8 crashkernel\u003d2G-64G:256M,64G-:512M resume\u003dUUID\u003d3f4c08b1-bbcd-43a7-b346-e915908ae3c6 rd.lvm.lv\u003dhibernal01_os/root rd.lvm.lv\u003dhibernal01_os/swap console\u003dtty0 console\u003dttyS1,115200 intel_iommu\u003doff memmap\u003d512M\\$0x1c0000000 intremap\u003doff\"\nroot\u003d\"/dev/mapper/hibernal01_os-root\"\ninitrd\u003d\"/boot/initramfs-6.12.0-260.el10.x86_64.img\"\ntitle\u003d\"CentOS Stream (6.12.0-260.el10.x86_64) 10 (Coughlan)\"\nid\u003d\"7945c56c20d8489180730e536b8c72e8-6.12.0-260.el10.x86_64\"\n```\n\nintel_iommu\u003doff is not required bcasue that is the default anyway\n\n\nif we disabel DMAR interrupt remapping then the msi-x vectors get assgiend and this works\n\nim almost out of time for today but ill contineu testing on tuesday. \n\nwe shoudl add this to the doc.","commit_id":"e8ab207f032cf2778beb34ac6bdcecea9df54d2c"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"a0f3dbcff174a9307f0fccc959174a336507ecf4","unresolved":false,"context_lines":[{"line_number":78,"context_line":""},{"line_number":79,"context_line":".. code-block:: console"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"   $ sudo bash pci-sim/run_nvme_vfio_guest_probe.sh"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"This downloads an Ubuntu cloud image, sets NVMe personality, creates a VF,"},{"line_number":84,"context_line":"binds it to VFIO, launches QEMU, and runs six guest checks automatically."}],"source_content_type":"text/x-rst","patch_set":26,"id":"d5253c59_771a6013","line":81,"updated":"2026-09-04 08:33:39.000000000","message":"testing.rst instructs contributors to run \u0027sudo bash pci-sim/run_nvme_vfio_guest_probe.sh\u0027 and README.rst documents both run_nvme_vfio_guest_probe.sh and run_nvme_vfio_guest_probe.py, but no such files exist anywhere in the tree. \u0027ls pci-sim/*.sh pci-sim/*.py\u0027 shows only the cirros/uart-era scripts plus test_pci_sim_nvme_host.sh.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: A contributor following the NVMe guest verification instructions hits \u0027No such file or directory\u0027 and cannot run the advertised end-to-end guest probe, undermining the primary workflow this change documents.\n\n**Suggestion**:\nEither add the missing run_nvme_vfio_guest_probe.sh/.py scripts in this commit or remove the sections describing them (and the README entries) until the scripts land, keeping the manual guest-verification steps.","commit_id":"dd700467f638287da18ba08c9bdce22f1f0dd047"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"8ffbeab1893067fc5a41067d288f49961241db29","unresolved":false,"context_lines":[{"line_number":86,"context_line":"NVMe host character device test"},{"line_number":87,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"Tests Phase 1 (char device ``/dev/pci_sim_nvmeN``) and Phase 2 (stock"},{"line_number":90,"context_line":"``nvme`` driver binding via BAR0).  Includes fio data I/O,"},{"line_number":91,"context_line":"filesystem (parted/mkfs/mount), and VFIO rebind tests."},{"line_number":92,"context_line":""}],"source_content_type":"text/x-rst","patch_set":27,"id":"3c228827_da395d50","line":89,"updated":"2026-09-07 06:04:38.000000000","message":"The new documentation consistently describes Phase 1 host char devices as /dev/pci_sim_nvmeN (testing.rst:89, developer-guide.rst:190, 203, 271, 286 and the mode table). The actual code creates nodes named /dev/nvmeN: fake_pci_sriov_nvme_host.c:361-364 calls device_create(..., \"nvme%d\", dev-\u003eid), and the shipped test script uses /dev/nvme0 (test_pci_sim_nvme_host.sh:89-104, 169-172). The /dev/nvmeN naming is deliberate (nvme-cli passthrough plus the \u003cpci_addr\u003e/nvme sysfs symlink that Cyborg\u0027s spec-compliant sysfs walk expects), so the docs are wrong, not the code.\n\n**Severity**: WARNING | **Confidence**: 0.88\n\n**Impact**: Users and automation following the docs look for /dev/pci_sim_nvmeN and find nothing; the docs also conceal that the sim intentionally occupies the real nvme device namespace (/dev/nvmeN), which can collide with genuine NVMe controllers on machines that have them — an operator-facing consequence worth documenting explicitly.\n\n**Suggestion**:\nReplace /dev/pci_sim_nvmeN with /dev/nvmeN throughout testing.rst and developer-guide.rst, and add a short note that the device name intentionally matches the stock nvme char device namespace (with the collision caveat on hosts with real NVMe devices).","commit_id":"797d4ff09639a1b281ec01b1d4967dec518b17ab"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"8532d53823b705d2307eb3d086681401a75f6479","unresolved":false,"context_lines":[{"line_number":78,"context_line":""},{"line_number":79,"context_line":".. code-block:: console"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"   $ sudo bash pci-sim/run_nvme_vfio_guest_probe.sh"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"This downloads an Ubuntu cloud image, sets NVMe personality, creates a VF,"},{"line_number":84,"context_line":"binds it to VFIO, launches QEMU, and runs six guest checks automatically."}],"source_content_type":"text/x-rst","patch_set":31,"id":"f0dc2ce7_258ee2c0","line":81,"updated":"2026-09-09 05:39:42.000000000","message":"doc/source/contributor/pci-sim/testing.rst instructs \u0027sudo bash pci-sim/run_nvme_vfio_guest_probe.sh\u0027 describing an automated QEMU NVMe guest probe, and pci-sim/README.rst lists both run_nvme_vfio_guest_probe.sh and run_nvme_vfio_guest_probe.py under test scripts. Neither file exists anywhere in the repository (only the docs mention them).\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Users following the NVMe guest verification section hit \u0027No such file or directory\u0027 for the documented automated wrapper, undermining the doc\u0027s promise of six automated guest checks.\n\n**Suggestion**:\nEither add the run_nvme_vfio_guest_probe.sh/.py scripts in this change or drop/soften the references until the scripts land, keeping only the manual QEMU instructions that are complete.","commit_id":"984f55716b417da2056c1c601ddd4ced9333fe72"}],"pci-sim/README.rst":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"7d1aed30154fc155c41bbb6a0819c66b4ac4edfb","unresolved":false,"context_lines":[{"line_number":8,"context_line":"bridges with physical functions and software-created virtual functions."},{"line_number":9,"context_line":"The VFs can be bound to VFIO and assigned to QEMU guests."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"VF personality"},{"line_number":12,"context_line":"--------------"},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Each PF selects a *personality* that determines the device type exposed by its"}],"source_content_type":"text/x-rst","patch_set":2,"id":"78849818_0dc84498","line":11,"updated":"2026-08-07 08:38:46.000000000","message":"This patch adds a new \u0027VF personality\u0027 section (lines 11-36) while the pre-existing \u0027VF personality\u0027 section (lines 51-74) remains, creating two RST sections with the same title. The old section says \u0027Currently supported personalities are uart\u0027 contradicting the new section which correctly lists...\n\n**Severity**: SUGGESTION | **Confidence**: 0.9\n\n**Benefit**: Duplicate section titles create RST/Sphinx cross-reference ambiguity. The old section\u0027s claim that only uart is supported contradicts the new section and the actual code.\n\n**Recommendation**:\nRemove or merge the old \u0027VF personality\u0027 section (lines 51-74) into the new one, updating the stale \u0027only uart\u0027 claim. Keep a single authoritative personality section.","commit_id":"8ea2eb20b6720e5177ebfbfede3670c608136ffc"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"7d1aed30154fc155c41bbb6a0819c66b4ac4edfb","unresolved":false,"context_lines":[{"line_number":14,"context_line":"Each PF selects a *personality* that determines the device type exposed by its"},{"line_number":15,"context_line":"VFs (device ID, PCI class, BAR layout, and VFIO emulation behavior).  The"},{"line_number":16,"context_line":"``default_personality`` module parameter sets the personality for"},{"line_number":17,"context_line":"all PFs at load time (default ``uart``)::"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"   modprobe fake_pci_sriov default_personality\u003duart"},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"53614c0f_9888e346","line":17,"updated":"2026-08-07 08:38:46.000000000","message":"The new \u0027VF personality\u0027 section in README.rst claims a default_personality module parameter exists and defaults to \u0027uart\u0027. No such parameter exists in fake_pci_sriov_core.c; PFs start with personality \u0027unset\u0027 and must be assigned via sysfs before VFs can be created.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: A user following the README would try \u0027modprobe fake_pci_sriov default_personality\u003dnvme\u0027 and get \u0027unknown parameter\u0027 error. The incorrect default (\u0027uart\u0027) also misleads users into thinking PFs come pre-configured.\n\n**Suggestion**:\nRemove the default_personality module parameter reference. Document that PFs start as \u0027unset\u0027 and require sysfs assignment (echo nvme \u003e vf_personality) before enabling VFs, which is already described later in the same section.","commit_id":"8ea2eb20b6720e5177ebfbfede3670c608136ffc"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"198d83783d31f82835cc5deb92eccf9f47a508c8","unresolved":false,"context_lines":[{"line_number":11,"context_line":"VF personality"},{"line_number":12,"context_line":"--------------"},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Each PF selects a *personality* that determines the device type exposed by its"},{"line_number":15,"context_line":"VFs (device ID, PCI class, BAR layout, and VFIO emulation behavior).  The"},{"line_number":16,"context_line":"``default_personality`` module parameter sets the personality for"},{"line_number":17,"context_line":"all PFs at load time (default ``uart``)::"}],"source_content_type":"text/x-rst","patch_set":3,"id":"2627fd8d_dc82e81c","line":14,"updated":"2026-08-07 18:07:47.000000000","message":"The README has two \u0027VF personality\u0027 sections that contradict each other. Lines 14-37 describe a non-existent \u0027default_personality\u0027 module param defaulting to \u0027uart\u0027. Lines 52-74 correctly describe the unset default but say \u0027Currently supported personalities are uart\u0027 — now stale since nvme is als...\n\n**Severity**: SUGGESTION | **Confidence**: 0.8\n\n**Benefit**: Users following the README to configure NVMe personality will be confused by contradictory instructions and the non-existent default_personality parameter. The stale \u0027uart only\u0027 statement misleads about available capabilities.\n\n**Recommendation**:\nRemove the first (incorrect) \u0027VF personality\u0027 section (lines 12-37) or merge accurate information from both sections. Update \u0027Currently supported personalities are uart\u0027 to include nvme.","commit_id":"f3159e05b31f758c11457a19a686cf50759643e0"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"bd50f149faac711ecb3a3f00a3b57ae3dff2fa56","unresolved":false,"context_lines":[{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Each PF selects a *personality* that determines the device type exposed by its"},{"line_number":15,"context_line":"VFs (device ID, PCI class, BAR layout, and VFIO emulation behavior).  The"},{"line_number":16,"context_line":"``default_personality`` module parameter sets the personality for"},{"line_number":17,"context_line":"all PFs at load time (default ``uart``)::"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"   modprobe fake_pci_sriov default_personality\u003duart"}],"source_content_type":"text/x-rst","patch_set":4,"id":"6a80ccd7_895186fa","line":16,"updated":"2026-08-09 06:51:46.000000000","message":"The new \u0027VF personality\u0027 section added to README.rst tells users to use a \u0027default_personality\u0027 module parameter to set personality at load time. No such parameter exists in the module code. Additionally, the README now has two \u0027VF personality\u0027 sections: the new one (line 11) correctly describes...\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Users will try to use modprobe fake_pci_sriov default_personality\u003duart and get an \u0027unknown parameter\u0027 error. The contradictory sections create confusion about what personalities are actually supported.\n\n**Suggestion**:\nRemove the default_personality reference from the new section. Document that personality must be set via sysfs (echo uart|nvme \u003e vf_personality) after module load, or that nvme_memmap_start/nvme_memmap_size params pre-set NVMe personality at load time. Remove or update the stale pre-existing \u0027VF personality\u0027 section (line 51-75) to avoid contradictions.","commit_id":"a01f2d2be561ee8fc6b08fdce89d6946a71ad2dc"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"4a23e7d6624ff387761c870820cd7b4061ece3b9","unresolved":false,"context_lines":[{"line_number":9,"context_line":"The VFs can be bound to VFIO and assigned to QEMU guests."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"VF personality"},{"line_number":12,"context_line":"--------------"},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Each PF selects a *personality* that determines the device type exposed by its"},{"line_number":15,"context_line":"VFs (device ID, PCI class, BAR layout, and VFIO emulation behavior).  The"}],"source_content_type":"text/x-rst","patch_set":6,"id":"40cf7a65_14028ed1","line":12,"updated":"2026-08-11 18:09:20.000000000","message":"README.rst now contains two separate \u0027VF personality\u0027 sections: one at lines 12-47 (newly added) and another at lines 51-74 (pre-existing). The upper section documents a nonexistent default_personality parameter and claims uart is the default, while the lower section correctly documents that PFs...\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Confusing user experience with two sections titled identically giving contradictory guidance. The lower section also has stale content (line 72: \u0027not uart\u0027 should be \u0027unset\u0027, and it doesn\u0027t mention nvme).\n\n**Suggestion**:\nMerge the two sections into one authoritative \u0027VF personality\u0027 section. Use the lower section\u0027s accurate description of the sysfs-based mechanism as the basis, add nvme documentation from the upper section, and remove the duplicate. Update line 72\u0027s \u0027not uart\u0027 to \u0027not set\u0027 and mention nvme.","commit_id":"b751927859bfe9d6bee3a5d261abbfa308e69f07"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"4a23e7d6624ff387761c870820cd7b4061ece3b9","unresolved":false,"context_lines":[{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Each PF selects a *personality* that determines the device type exposed by its"},{"line_number":15,"context_line":"VFs (device ID, PCI class, BAR layout, and VFIO emulation behavior).  The"},{"line_number":16,"context_line":"``default_personality`` module parameter sets the personality for"},{"line_number":17,"context_line":"all PFs at load time (default ``uart``)::"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"   modprobe fake_pci_sriov default_personality\u003duart"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ef461c2e_47ffe0e3","line":16,"updated":"2026-08-11 18:09:20.000000000","message":"The README.rst \u0027VF personality\u0027 section (lines 14-19) documents a default_personality module parameter and shows \u0027modprobe fake_pci_sriov default_personality\u003duart\u0027. No such module parameter exists in the code. The actual mechanism is the per-PF vf_personality sysfs file, and PFs start with person...\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Users following the README instructions will get \u0027modprobe: unknown parameter default_personality\u0027 errors. The documentation contradicts the actual module interface.\n\n**Suggestion**:\nRemove the default_personality module parameter documentation. Document that PFs start with personality \u0027unset\u0027 and must be assigned via sysfs before enabling VFs. The later README section (lines 51-74) already documents this correctly — the upper section should be reconciled with the lower one.","commit_id":"b751927859bfe9d6bee3a5d261abbfa308e69f07"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"dc7934f877c0b7af7cb63c87e2919599282e664e","unresolved":false,"context_lines":[{"line_number":11,"context_line":"VF personality"},{"line_number":12,"context_line":"--------------"},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Each PF selects a *personality* that determines the device type exposed by its"},{"line_number":15,"context_line":"VFs (device ID, PCI class, BAR layout, and VFIO emulation behavior).  The"},{"line_number":16,"context_line":"``default_personality`` module parameter sets the personality for"},{"line_number":17,"context_line":"all PFs at load time (default ``uart``)::"}],"source_content_type":"text/x-rst","patch_set":8,"id":"b16701ab_ff037fa1","line":14,"updated":"2026-08-12 16:58:47.000000000","message":"The new VF personality section in README.rst references a `default_personality` module parameter that does not exist in the code. PFs start with personality `unset`, not `uart`, and there is no module parameter to set it at load time.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Users following the README will attempt `modprobe fake_pci_sriov default_personality\u003duart` which will fail with \u0027unknown parameter\u0027. The README also contradicts itself: the first section says uart is the default, while the second section (line 59) correctly says PFs start as \u0027unset\u0027.\n\n**Suggestion**:\nRemove the `default_personality` module parameter references from README.rst. Document that PFs start with personality \u0027unset\u0027 and must be set via sysfs (`echo nvme \u003e /sys/bus/pci/devices/\u003cPF\u003e/vf_personality`) before enabling VFs.","commit_id":"cbc262d47285399a74084797a1f330b1c49c93aa"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"f8e0ed2121cb6bcf3429c51a9e23c187f2662231","unresolved":false,"context_lines":[{"line_number":56,"context_line":"file lists all supported personalities, with the current one in brackets."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"PFs start with personality ``unset``; the user must assign a personality"},{"line_number":59,"context_line":"before the PF can create VFs.  Currently supported personalities are"},{"line_number":60,"context_line":"``uart``; additional types (e.g. NVMe, mdev) may be added in the future."},{"line_number":61,"context_line":"Example::"},{"line_number":62,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"6e534612_cd64f95f","line":59,"updated":"2026-08-13 16:20:37.000000000","message":"Both README.rst (lines 59-60) and overview.rst (lines 25-26) contain the text \u0027Currently supported personalities are uart; additional types (e.g. NVMe, mdev) may be added in the future.\u0027 This commit implements the NVMe personality, making this documentation stale and misleading.\n\n**Severity**: SUGGESTION | **Confidence**: 0.9\n\n**Benefit**: Users reading the docs will not know that NVMe personality is available, and the statement about future addition is factually wrong after this commit. README.rst also has a duplicate VF personality section (first at lines 11-26 correctly mentions NVMe, second at lines 51-74 does not).\n\n**Recommendation**:\nUpdate both README.rst and overview.rst to list \u0027uart\u0027 and \u0027nvme\u0027 as currently supported personalities. Remove or update the \u0027may be added in the future\u0027 text. Consider removing the duplicate VF personality section in README.rst.","commit_id":"85c5e1594db0d8475029a94c8301ded3c6fac562"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"0f6e632238b0b5012d7e343ad6430918c8ed6ae5","unresolved":false,"context_lines":[{"line_number":120,"context_line":"   (stock nvme driver with memmap), driver rebind, and cross-personality"},{"line_number":121,"context_line":"   switching."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"``run_nvme_vfio_guest_probe.sh``"},{"line_number":124,"context_line":"   Automated QEMU NVMe guest passthrough probe.  Downloads an Ubuntu cloud"},{"line_number":125,"context_line":"   image, sets NVMe personality, creates a VF, binds to VFIO, launches QEMU,"},{"line_number":126,"context_line":"   and runs six guest checks."}],"source_content_type":"text/x-rst","patch_set":14,"id":"7a0ed250_59838d63","line":123,"updated":"2026-08-18 08:07:55.000000000","message":"pci-sim/README.rst (lines 123-130) and doc/source/contributor/pci-sim/testing.rst (line 81, plus surrounding text) present pci-sim/run_nvme_vfio_guest_probe.sh and run_nvme_vfio_guest_probe.py as shipped, working helpers that download an Ubuntu cloud image and run six guest checks automatically. Neither file exists in pci-sim/ (only the cirros variants run_cirros_vfio_guest_probe.* are present) and neither is added by this commit.\n\n**Severity**: WARNING | **Confidence**: 0.95\n\n**Impact**: A contributor following the NVMe guest verification instructions runs a nonexistent script and gets \u0027No such file or directory\u0027; the documented automated guest-probe workflow is unavailable, and the docs overstate what the change ships.\n\n**Suggestion**:\nEither add the two files in this change (if they exist but were omitted from the commit) or remove/adjust the two README entries and the testing.rst \u0027automated wrapper\u0027 paragraph to reference only what is shipped (e.g. the existing cirros VFIO probe scripts or manual QEMU steps).","commit_id":"d5c6e164d1ef30afc7d4a96e3dbd1adf9dc79fe4"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"dd8eae7587132645990f464e644baf7a13ff9733","unresolved":false,"context_lines":[{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Each PF selects a *personality* that determines the device type exposed by its"},{"line_number":15,"context_line":"VFs (device ID, PCI class, BAR layout, and VFIO emulation behavior).  The"},{"line_number":16,"context_line":"``default_personality`` module parameter sets the personality for"},{"line_number":17,"context_line":"all PFs at load time (default ``uart``)::"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"   modprobe fake_pci_sriov default_personality\u003duart"}],"source_content_type":"text/x-rst","patch_set":24,"id":"820bcbb0_e04c4fa0","line":16,"updated":"2026-09-03 18:53:50.000000000","message":"The new README.rst section (lines 14-19) states \u0027The default_personality module parameter sets the personality for all PFs at load time (default uart)\u0027 with an example \u0027modprobe fake_pci_sriov default_personality\u003duart\u0027. No such module parameter exists: fake_pci_sriov_core.c registers only vfio_guest_8250_compat, vfio_uart_trace, nvme_ns_size_mb, nvme_backing_file, nvme_memmap_start, nvme_memmap_size, num_pfs, mem_base and mem_stride; personality is selected solely via the vf_personality sysfs file or memmap pre-set.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Operators following the README pass an unknown parameter; insmod/modprobe rejects it with \u0027Unknown parameter\u0027 (module_param values are fatal on insmod), so the documented load line fails.\n\n**Suggestion**:\nEither implement the default_personality parameter (trivial: parse into the host probe personality selection) or delete the claim and document the sysfs vf_personality flow and the memmap auto-select as the only selection methods.","commit_id":"d9e746e72fe4d754603b5cc20a4b99609e981c96"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"dd8eae7587132645990f464e644baf7a13ff9733","unresolved":false,"context_lines":[{"line_number":120,"context_line":"   (stock nvme driver with memmap), driver rebind, and cross-personality"},{"line_number":121,"context_line":"   switching."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"``run_nvme_vfio_guest_probe.sh``"},{"line_number":124,"context_line":"   Automated QEMU NVMe guest passthrough probe.  Downloads an Ubuntu cloud"},{"line_number":125,"context_line":"   image, sets NVMe personality, creates a VF, binds to VFIO, launches QEMU,"},{"line_number":126,"context_line":"   and runs six guest checks."}],"source_content_type":"text/x-rst","patch_set":24,"id":"e2191e09_2a2611af","line":123,"updated":"2026-09-03 18:53:50.000000000","message":"The added documentation tells users to run an automated QEMU NVMe guest probe script that is not part of this change or the tree: README.rst:123-130 documents run_nvme_vfio_guest_probe.sh and run_nvme_vfio_guest_probe.py, and doc/source/contributor/pci-sim/testing.rst:81 instructs \u0027$ sudo bash pci-sim/run_nvme_vfio_guest_probe.sh\u0027. No file matching run_nvme_vfio_guest_probe* exists anywhere in the repository (ls pci-sim/ shows only cirros_vfio_*, run_fake_pci_*, run_cirros_vfio_* and test_pci_sim_* scripts).\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Contributors following the testing guide get \u0027No such file or directory\u0027 and conclude guest NVMe passthrough testing is available when it is not; the docs overstate what this change delivers.\n\n**Suggestion**:\nEither add the scripts in this change or remove/adjust the README and testing.rst sections until the tooling lands; at minimum describe the manual QEMU steps that actually work today.","commit_id":"d9e746e72fe4d754603b5cc20a4b99609e981c96"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"8ffbeab1893067fc5a41067d288f49961241db29","unresolved":false,"context_lines":[{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Each PF selects a *personality* that determines the device type exposed by its"},{"line_number":15,"context_line":"VFs (device ID, PCI class, BAR layout, and VFIO emulation behavior).  The"},{"line_number":16,"context_line":"``default_personality`` module parameter sets the personality for"},{"line_number":17,"context_line":"all PFs at load time (default ``uart``)::"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"   modprobe fake_pci_sriov default_personality\u003duart"}],"source_content_type":"text/x-rst","patch_set":27,"id":"c84f5b3b_1c33bb77","line":16,"updated":"2026-09-07 06:04:38.000000000","message":"Documentation added by this change instructs users to run artifacts that do not exist in the tree. README.rst:123-128 documents pci-sim/run_nvme_vfio_guest_probe.sh and run_nvme_vfio_guest_probe.py as shipped files, and doc/source/contributor/pci-sim/testing.rst:81 tells users to execute \u0027sudo bash pci-sim/run_nvme_vfio_guest_probe.sh\u0027; a repo search finds no such files (only the doc references). README.rst:16-19 also documents a \u0027default_personality\u0027 module parameter with a modprobe example, but no module_param named default_personality exists in fake_pci_sriov_core.c (parameters are vfio_guest_8250_compat, vfio_uart_trace, nvme_*, num_pfs, mem_base, mem_stride); \u0027modprobe fake_pci_sriov default_personality\u003duart\u0027 fails with an unknown-parameter error.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Users following the README/testing instructions hit \u0027No such file or directory\u0027 for the guest-probe script and \u0027Unknown parameter\u0027 from modprobe, so the documented quick-start flows fail; the docs also describe a personality-loading feature that is not implemented.\n\n**Suggestion**:\nEither add the missing run_nvme_vfio_guest_probe.{sh,py} files in this change or remove/defer those sections, and delete or implement the default_personality parameter documentation. Verify every command in the new doc sections runs against the tree as submitted.","commit_id":"797d4ff09639a1b281ec01b1d4967dec518b17ab"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"c8bf625f8db5753ee943267c11cac889421c1240","unresolved":false,"context_lines":[{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Each PF selects a *personality* that determines the device type exposed by its"},{"line_number":15,"context_line":"VFs (device ID, PCI class, BAR layout, and VFIO emulation behavior).  The"},{"line_number":16,"context_line":"``default_personality`` module parameter sets the personality for"},{"line_number":17,"context_line":"all PFs at load time (default ``uart``)::"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"   modprobe fake_pci_sriov default_personality\u003duart"}],"source_content_type":"text/x-rst","patch_set":30,"id":"feec9c35_47a8a619","line":16,"updated":"2026-09-08 13:05:13.000000000","message":"The new README section states \u0027The default_personality module parameter sets the personality for all PFs at load time (default uart)\u0027 with \u0027modprobe fake_pci_sriov default_personality\u003duart\u0027. No such module parameter exists anywhere in the module: core.c registers only mem_base, mem_stride, num_pfs, nvme_ns_size_mb, nvme_backing_file, nvme_memmap_start, nvme_memmap_size, vfio_guest_8250_compat and vfio_uart_trace; neither this commit nor the base (541b28d) defines default_personality. Following the documented command fails module load with an unknown-parameter error.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Operators or CI following the README get a module load failure (or, worse, assume personality defaults to uart at load time), and the documented load-time configuration workflow is unusable.\n\n**Suggestion**:\nEither remove the default_personality paragraph from README.rst and document the actual load-time behaviour (personality is unset until written to vf_personality, or nvme when memmap parameters are given), or implement the parameter in core.c.","commit_id":"b2c98611a875c9a2de076c5f4d346a52eb22ef78"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"c8bf625f8db5753ee943267c11cac889421c1240","unresolved":false,"context_lines":[{"line_number":120,"context_line":"   (stock nvme driver with memmap), driver rebind, and cross-personality"},{"line_number":121,"context_line":"   switching."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"``run_nvme_vfio_guest_probe.sh``"},{"line_number":124,"context_line":"   Automated QEMU NVMe guest passthrough probe.  Downloads an Ubuntu cloud"},{"line_number":125,"context_line":"   image, sets NVMe personality, creates a VF, binds to VFIO, launches QEMU,"},{"line_number":126,"context_line":"   and runs six guest checks."}],"source_content_type":"text/x-rst","patch_set":30,"id":"3060a367_3ee878a5","line":123,"updated":"2026-09-08 13:05:13.000000000","message":"README.rst describes \u0027run_nvme_vfio_guest_probe.sh\u0027 and \u0027run_nvme_vfio_guest_probe.py\u0027 (\u0027Automated QEMU NVMe guest passthrough probe...\u0027), and testing.rst instructs \u0027sudo bash pci-sim/run_nvme_vfio_guest_probe.sh\u0027 as an available automated wrapper. Neither file exists anywhere in the repository at this commit, and the commit message does not mention them. Per the project\u0027s AGENTS.md, series are unsquashed and each commit must be independently testable and correct, so documentation of files that do not exist yet breaks at this patchset.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Users following testing.rst get an immediate file-not-found failure, and the VFIO NVMe guest-verification workflow described around the wrapper has no in-tree automation at this patchset, weakening the commit\u0027s claim of enabling guest NVMe testing.\n\n**Suggestion**:\nEither add the two helper scripts in this commit or drop/relocate the descriptions to the commit that actually introduces them (the README \u0027test scripts\u0027 inventory and the testing.rst code-block both need updating).","commit_id":"b2c98611a875c9a2de076c5f4d346a52eb22ef78"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"8532d53823b705d2307eb3d086681401a75f6479","unresolved":false,"context_lines":[{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Each PF selects a *personality* that determines the device type exposed by its"},{"line_number":15,"context_line":"VFs (device ID, PCI class, BAR layout, and VFIO emulation behavior).  The"},{"line_number":16,"context_line":"``default_personality`` module parameter sets the personality for"},{"line_number":17,"context_line":"all PFs at load time (default ``uart``)::"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"   modprobe fake_pci_sriov default_personality\u003duart"}],"source_content_type":"text/x-rst","patch_set":31,"id":"e0b24753_a60a099a","line":16,"updated":"2026-09-09 05:39:42.000000000","message":"The README section added by this change states \u0027The default_personality module parameter sets the personality for all PFs at load time (default uart)\u0027 and gives \u0027modprobe fake_pci_sriov default_personality\u003duart\u0027. No such module parameter exists: fake_pci_sriov_core.c defines vfio_guest_8250_compat, vfio_uart_trace, nvme_ns_size_mb, nvme_backing_file, nvme_memmap_start/size, pf_personalities, num_pfs, mem_base, mem_stride only.\n\n**Severity**: WARNING | **Confidence**: 0.95\n\n**Impact**: A developer following the README runs \u0027modprobe fake_pci_sriov default_personality\u003dnvme\u0027 and the module load fails with an unknown-parameter error, blocking setup at the first documented step.\n\n**Suggestion**:\nEither add the default_personality module parameter to fake_pci_sriov_core.c or rewrite the README to describe the actual mechanism (sysfs vf_personality per PF, plus the memmap/pf_personalities pre-set path).","commit_id":"984f55716b417da2056c1c601ddd4ced9333fe72"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"bb9b000f0a0673e1493a0b07e6a388d7a32f4fd2","unresolved":false,"context_lines":[{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Each PF selects a *personality* that determines the device type exposed by its"},{"line_number":15,"context_line":"VFs (device ID, PCI class, BAR layout, and VFIO emulation behavior).  The"},{"line_number":16,"context_line":"``default_personality`` module parameter sets the personality for"},{"line_number":17,"context_line":"all PFs at load time (default ``uart``)::"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"   modprobe fake_pci_sriov default_personality\u003duart"}],"source_content_type":"text/x-rst","patch_set":33,"id":"b96c9da6_92b98637","line":16,"updated":"2026-09-09 15:26:55.000000000","message":"The README section added by this change tells users \u0027modprobe fake_pci_sriov default_personality\u003duart\u0027, but no default_personality module parameter exists anywhere in the module (module_param list: nvme_ns_size_mb, nvme_backing_file, nvme_memmap_start/size, pf_personalities, num_pfs, mem_base, mem_stride, vfio_*); the command fails with \u0027unknown parameter\u0027. The developer-guide parameter table still documents fake_intx_irq, which this change removed from fake_pci_sriov_core.c, omits the new pf_personalities parameter, and lists nvme_backing_file\u0027s default as \u0027(none)\u0027 when the code default is /tmp/pci-sim-nvme.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Contributors following the README get a module load failure; users passing fake_intx_irq (previously supported) likewise fail with unknown-parameter; pf_personalities usage is undiscoverable from the parameter table.\n\n**Suggestion**:\nRemove or correct the default_personality example in README.rst (sysfs vf_personality is the actual mechanism), drop the fake_intx_irq row, add pf_personalities, and fix the nvme_backing_file default in the developer-guide table.","commit_id":"ff0395aa92d19d85ae49c592b8bcdd0ad3801400"}],"pci-sim/fake_pci_sriov.h":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3f1619780058af2dc79e93fd0fb3d294ce4ca79e","unresolved":true,"context_lines":[{"line_number":51,"context_line":"#define FAKE_PCI_VENDOR_CLASS 0xff0000"},{"line_number":52,"context_line":"#define FAKE_PCI_SUBSYS_VENDOR FAKE_PCI_VENDOR_ID"},{"line_number":53,"context_line":"#define FAKE_PCI_SUBSYS_ID FAKE_PCI_PF_DEVICE_ID"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"/* \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":56,"context_line":" * SR-IOV / BAR configuration"},{"line_number":57,"context_line":" * \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":58,"context_line":" */"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"#define MAX_VFS 7"},{"line_number":61,"context_line":"#define FAKE_PCI_MAX_HOSTS 16"}],"source_content_type":"text/x-csrc","patch_set":22,"id":"f8a1b4e9_24953d39","line":58,"range":{"start_line":54,"start_character":1,"end_line":58,"end_character":3},"updated":"2026-08-26 19:25:29.000000000","message":"i have commented on this else where dont add block setcion comments\n\nthe kernel syl for this is `/* SR-IOV / BAR configuration */` if we do that at all.","commit_id":"e8ab207f032cf2778beb34ac6bdcecea9df54d2c"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"1daa79a349663ef155d31135baae8699ee6a4a17","unresolved":false,"context_lines":[{"line_number":162,"context_line":"\t * nvme driver can call pci_alloc_irq_vectors() successfully."},{"line_number":163,"context_line":"\t * Value \u003c\u003d 0 means not allocated."},{"line_number":164,"context_line":"\t */"},{"line_number":165,"context_line":"\tint sw_irq;"},{"line_number":166,"context_line":"};"},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"struct pci_sim_uart {"}],"source_content_type":"text/x-csrc","patch_set":23,"id":"68b72dc8_7ebd734e","line":165,"updated":"2026-09-01 12:06:53.000000000","message":"The new sw_irq member of struct fake_pci_host carries a comment stating it is \u0027Allocated in fake_pci_host_probe(), freed in fake_pci_host_remove()\u0027 and that \u0027fake_pci_map_irq() returns this value only for NVMe VFs so the stock nvme driver can call pci_alloc_irq_vectors() successfully\u0027. Neither is true in this commit: grep shows sw_irq is never assigned anywhere, and fake_pci_map_irq() returns -1 unconditionally (the commit message documents the -1 return as intentional). The field is therefore dead code whose comment describes behavior that does not exist.\n\n**Severity**: SUGGESTION | **Confidence**: 0.9\n\n**Impact**: A future maintainer wiring up host-side NVMe VF interrupt delivery will trust the comment, assume allocation already happens in probe, and either duplicate it or rely on a value that is always uninitialized/zero. The misleading invariant has no owner in the code that claims to own it.\n\n**Recommendation**:\nEither remove the sw_irq field and its comment until the software IRQ allocation actually lands (with the MSI-X domain commit it is written for), or rewrite the comment to state that allocation is planned in a follow-up commit and that map_irq currently returns -1 for all personalities.","commit_id":"ef7c3a02905f8b20910ce630fe68af640a0fdea6"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"dd8eae7587132645990f464e644baf7a13ff9733","unresolved":false,"context_lines":[{"line_number":162,"context_line":"\t * nvme driver can call pci_alloc_irq_vectors() successfully."},{"line_number":163,"context_line":"\t * Value \u003c\u003d 0 means not allocated."},{"line_number":164,"context_line":"\t */"},{"line_number":165,"context_line":"\tint sw_irq;"},{"line_number":166,"context_line":"};"},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"struct pci_sim_uart {"}],"source_content_type":"text/x-csrc","patch_set":24,"id":"838dc5a0_d74ae3e8","line":165,"updated":"2026-09-03 18:53:50.000000000","message":"fake_pci_sriov.h:150-165 adds \u0027int sw_irq\u0027 to struct fake_pci_host with a comment stating it is allocated in fake_pci_host_probe(), freed in fake_pci_host_remove(), and returned by fake_pci_map_irq() \u0027only for NVMe VFs so the stock nvme driver can call pci_alloc_irq_vectors()\u0027. None of this exists: grep shows sw_irq appears only at its declaration, nothing allocates or reads it, and fake_pci_map_irq() returns -1 unconditionally (fake_pci_sriov_core.c:97). The comment documents interrupt plumbing that was apparently deferred to the next commit.\n\n**Severity**: SUGGESTION | **Confidence**: 0.85\n\n**Impact**: A future maintainer tracing the stock-nvme bind path trusts the comment, assumes an INTx irq is provided, and wastes time or builds on plumbing that is not there; the invariant (who owns interrupt delivery) has a stale owner documented.\n\n**Recommendation**:\nRemove the sw_irq field and its comment, or rewrite the comment to state that INTx is intentionally unsupported (NVMe VFs use MSI-X via the software MSI-X domain added in a later commit) and that the field is reserved.","commit_id":"d9e746e72fe4d754603b5cc20a4b99609e981c96"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"a0f3dbcff174a9307f0fccc959174a336507ecf4","unresolved":false,"context_lines":[{"line_number":162,"context_line":"\t * nvme driver can call pci_alloc_irq_vectors() successfully."},{"line_number":163,"context_line":"\t * Value \u003c\u003d 0 means not allocated."},{"line_number":164,"context_line":"\t */"},{"line_number":165,"context_line":"\tint sw_irq;"},{"line_number":166,"context_line":"};"},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"struct pci_sim_uart {"}],"source_content_type":"text/x-csrc","patch_set":26,"id":"565ace59_361ff698","line":165,"updated":"2026-09-04 08:33:39.000000000","message":"fake_pci_sriov.h adds \u0027int sw_irq\u0027 to struct fake_pci_host with a comment stating it is allocated in fake_pci_host_probe(), freed in fake_pci_host_remove(), and that fake_pci_map_irq() returns it for NVMe VFs. None of this happens: sw_irq is never assigned or read anywhere (single grep hit is its declaration), fake_pci_map_irq() now returns -1 unconditionally, and no allocation/free of this IRQ exists. The comment describes behavior that was apparently planned for the Phase 2 IRQ path but not implemented.\n\n**Severity**: SUGGESTION | **Confidence**: 0.85\n\n**Impact**: A future contributor reading the comment will assume an INTx/sw-IRQ plumbing exists and build on it (or \u0027fix\u0027 map_irq to return sw_irq), creating the exact mismatch the comment already contains; it also obscures how Phase 2 interrupts actually work.\n\n**Recommendation**:\nRemove the unused sw_irq field and its stale comment, or if the software INTx IRQ is planned for the follow-up commit, move the field and an accurate comment there together with the code that allocates it.","commit_id":"dd700467f638287da18ba08c9bdce22f1f0dd047"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"8ffbeab1893067fc5a41067d288f49961241db29","unresolved":false,"context_lines":[{"line_number":155,"context_line":"\tstruct pci_sim_nvme nvme_state[MAX_VFS];"},{"line_number":156,"context_line":"\tstruct task_struct *poll_kthread;"},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"\t/*"},{"line_number":159,"context_line":"\t * Software INTx IRQ for NVMe VF host binding (Phase 2)."},{"line_number":160,"context_line":"\t * Allocated in fake_pci_host_probe(), freed in fake_pci_host_remove()."},{"line_number":161,"context_line":"\t * fake_pci_map_irq() returns this value only for NVMe VFs so the stock"}],"source_content_type":"text/x-csrc","patch_set":27,"id":"03ae44af_3e07ecf7","line":158,"updated":"2026-09-07 06:04:38.000000000","message":"fake_pci_sriov.h:158-165 adds \u0027int sw_irq\u0027 documented as \u0027Allocated in fake_pci_host_probe(), freed in fake_pci_host_remove(). fake_pci_map_irq() returns this value only for NVMe VFs so the stock nvme driver can call pci_alloc_irq_vectors() successfully.\u0027 Neither is true in this commit: nothing reads or writes host-\u003esw_irq anywhere (repo-wide grep finds only the declaration), and fake_pci_map_irq() in fake_pci_sriov_core.c:97 now returns -1 unconditionally — a behavior the commit message explicitly documents (\u0027fake_pci_map_irq() returns -1 unconditionally\u0027). The field is dead state whose comment describes behavior that does not exist, apparently left over from a removed Phase-2 INTx approach.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: A future maintainer implementing or debugging host-driver IRQ setup will trust the comment and expect map_irq to return a usable INTx for NVMe VFs; the mismatch conceals the real design (MSI-X via the software domain from the next commit) and invites \u0027fixing\u0027 the correct -1 return or wiring up a nonexistent allocation path.\n\n**Suggestion**:\nDelete the unused sw_irq field and its comment, or rewrite the comment to describe the actual design: NVMe VFs get interrupts via the software MSI-X domain (next commit), map_irq intentionally returns -1 for all devices. Keep dead state out of the host struct until the code that uses it lands.","commit_id":"797d4ff09639a1b281ec01b1d4967dec518b17ab"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"d71464234cca034a647f629acf77559699bca9d6","unresolved":false,"context_lines":[{"line_number":149,"context_line":"\tint num_vfs_enabled;"},{"line_number":150,"context_line":"\tint domain_nr;"},{"line_number":151,"context_line":"\tstruct mutex lock; /* Protects VF enable/disable, personality. */"},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"\t/* NVMe memmap mode: BAR0 backed by reserved memory */"},{"line_number":154,"context_line":"\tvoid __iomem *bar0_mapped;"},{"line_number":155,"context_line":"\tstruct pci_sim_nvme nvme_state[MAX_VFS];"}],"source_content_type":"text/x-csrc","patch_set":29,"id":"46f16ca9_4ae37496","line":152,"updated":"2026-09-08 10:47:11.000000000","message":"The new sw_irq member of struct fake_pci_host carries a multi-line comment asserting it is \u0027Allocated in fake_pci_host_probe(), freed in fake_pci_host_remove()\u0027 and that \u0027fake_pci_map_irq() returns this value only for NVMe VFs so the stock nvme driver can call pci_alloc_irq_vectors() successfully.\u0027 Nothing in this tree assigns sw_irq (only the declaration exists) and fake_pci_map_irq() returns -1 unconditionally, which the commit message itself confirms. The comment therefore contradicts the implementation and will mislead the maintainer who later wires up software MSI-X delivery (the follow-up commit referenced in the message).\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: A maintainer reading the header assumes host_probe allocates and map_irq returns sw_irq for NVMe VFs; neither is true, so debugging interrupt binding or implementing the follow-up MSI-X work starts from a false premise. Dead field adds contract surface with no user.\n\n**Suggestion**:\nEither remove sw_irq until the software MSI-X domain commit actually allocates it, or rewrite the comment to state that the field is reserved and currently unused, and that fake_pci_map_irq() returns -1 unconditionally (NVMe VFs use MSI-X, UART VFs are polled).","commit_id":"dff1cc943141d7f15518107f29e958bd829edfd9"}],"pci-sim/fake_pci_sriov_cfg.c":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"1daa79a349663ef155d31135baae8699ee6a4a17","unresolved":false,"context_lines":[{"line_number":573,"context_line":""},{"line_number":574,"context_line":"\tmutex_unlock(\u0026host-\u003elock);"},{"line_number":575,"context_line":""},{"line_number":576,"context_line":"\tif (host-\u003epersonality_ops \u0026\u0026 host-\u003epersonality_ops-\u003esriov_enable) {"},{"line_number":577,"context_line":"\t\terr \u003d host-\u003epersonality_ops-\u003esriov_enable(host, num_vfs);"},{"line_number":578,"context_line":"\t\tif (err) {"},{"line_number":579,"context_line":"\t\t\thandle_sriov_numvfs_write(host, 0);"}],"source_content_type":"text/x-csrc","patch_set":23,"id":"5b675243_c6a939f5","line":576,"updated":"2026-09-01 12:06:53.000000000","message":"In fake_pci_sriov_configure(), when host-\u003epersonality_ops-\u003esriov_enable() fails, the error branch only calls handle_sriov_numvfs_write(host, 0) and returns; it does not invoke sriov_disable, unlike the immediately following pci_enable_sriov() failure branch which does. For the NVMe personality, sriov_enable (pci_sim_nvme_sriov_enable) has already run pci_sim_nvme_poll_preinit_vfs(), which called pci_sim_nvme_init() for each VF - opening and truncating a per-VF backing file and holding struct file references - before pci_sim_nvme_poll_start() can fail (kthread_run failure). Those nvme_state entries are then left initialized while num_vfs_enabled is reset to 0.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: A failed SR-IOV enable (e.g. kthread creation failure under memory pressure) leaves open file handles leaked per VF on every retry, and leaves host-\u003ebar0_mapped mapped with stale nvme_state; subsequent enable attempts silently discard the old state. Bounded resource leak in an error path of a test module - recoverable by module reload.\n\n**Suggestion**:\nMake the sriov_enable failure branch symmetrical with the pci_enable_sriov failure branch: call host-\u003epersonality_ops-\u003esriov_disable(host) (which stops the kthread and runs pci_sim_nvme_poll_vf_cleanup over the enabled VFs) before resetting num_vfs_enabled.","commit_id":"ef7c3a02905f8b20910ce630fe68af640a0fdea6"}],"pci-sim/fake_pci_sriov_core.c":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"1daa79a349663ef155d31135baae8699ee6a4a17","unresolved":false,"context_lines":[{"line_number":277,"context_line":"\t * device\u0027s MSI domain and propagates it to the root bus.  VFs created"},{"line_number":278,"context_line":"\t * later by pci_enable_sriov() inherit it from the bus automatically."},{"line_number":279,"context_line":"\t */"},{"line_number":280,"context_line":"\terr \u003d pci_sim_msi_domain_init(host);"},{"line_number":281,"context_line":"\tif (err) {"},{"line_number":282,"context_line":"\t\tpr_err(\"fake_pci: failed to create MSI domain for domain %04x: %d\\n\","},{"line_number":283,"context_line":"\t\t       host-\u003edomain_nr, err);"}],"source_content_type":"text/x-csrc","patch_set":23,"id":"5c964eea_4d1dd0f5","line":280,"updated":"2026-09-01 12:06:53.000000000","message":"fake_pci_sriov_core.c calls pci_sim_msi_domain_init(host) at line 280 and pci_sim_msi_domain_fini(host) at lines 308 and 324, but neither function is declared in fake_pci_sriov.h (or any header) nor defined in any .c file in the module. grep across pci-sim/ finds only the three call sites and a comment reference in fake_pci_sriov_nvme_poll.c:33. The commit message itself states the software MSI-X domain is \u0027added in the next commit\u0027, confirming the definitions are not in this commit. The Makefile compiles fake_pci_sriov_core.o into fake_pci_sriov-y, so the build fails with implicit-function-declaration errors and undefined references at link time.\n\n**Severity**: CRITICAL | **Confidence**: 0.95\n\n**Impact**: The fake_pci_sriov.ko module fails to compile/link at this commit, so nothing the change adds can be exercised: \u0027make\u0027 in pci-sim/ fails, and test_pci_sim_nvme_host.sh (which insmods the module) cannot run. Any CI or developer building at this commit gets a broken build.\n\n**Priority**: Immediate\n**Recommendation**:\nEither move the pci_sim_msi_domain_init/fini call sites into the same commit that defines the MSI-X domain helpers, or stub/guard them in this commit (e.g. a weak no-op or a fake_pci_sriov_compat.h fallback) so each commit in the series builds standalone.","commit_id":"ef7c3a02905f8b20910ce630fe68af640a0fdea6"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"dd8eae7587132645990f464e644baf7a13ff9733","unresolved":false,"context_lines":[{"line_number":277,"context_line":"\t * device\u0027s MSI domain and propagates it to the root bus.  VFs created"},{"line_number":278,"context_line":"\t * later by pci_enable_sriov() inherit it from the bus automatically."},{"line_number":279,"context_line":"\t */"},{"line_number":280,"context_line":"\terr \u003d pci_sim_msi_domain_init(host);"},{"line_number":281,"context_line":"\tif (err) {"},{"line_number":282,"context_line":"\t\tpr_err(\"fake_pci: failed to create MSI domain for domain %04x: %d\\n\","},{"line_number":283,"context_line":"\t\t       host-\u003edomain_nr, err);"}],"source_content_type":"text/x-csrc","patch_set":24,"id":"0f312c4a_a99b2eed","line":280,"updated":"2026-09-03 18:53:50.000000000","message":"fake_pci_sriov_core.c calls pci_sim_msi_domain_init(host) at line 280 and pci_sim_msi_domain_fini(host) at lines 308 and 324, but neither function is defined or declared anywhere in the repository at this commit. A grep over all pci-sim sources finds only these three call sites plus a comment in fake_pci_sriov_nvme_poll.c. The commit message confirms the software MSI-X domain is \u0027added in the next commit\u0027, yet this commit already wires the calls into the host probe/remove paths unconditionally, so kbuild produces an implicit-declaration error and an undefined-reference link error for fake_pci_sriov.o.\n\n**Severity**: CRITICAL | **Confidence**: 0.95\n\n**Impact**: make -C pci-sim modules fails at this commit; every downstream test (test_pci_sim_nvme_host.sh, smoke scripts, Zuul builds) cannot run, and bisecting this series breaks at this commit.\n\n**Priority**: Immediate\n**Recommendation**:\nEither move the pci_sim_msi_domain_init/fini calls into the commit that defines the functions, or land the software MSI-X domain implementation in this commit. The commit message itself says the poll path should be a no-op until the domain exists, so guarding the calls (or deferring them) matches the stated intent.","commit_id":"d9e746e72fe4d754603b5cc20a4b99609e981c96"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"a0f3dbcff174a9307f0fccc959174a336507ecf4","unresolved":false,"context_lines":[{"line_number":277,"context_line":"\t * device\u0027s MSI domain and propagates it to the root bus.  VFs created"},{"line_number":278,"context_line":"\t * later by pci_enable_sriov() inherit it from the bus automatically."},{"line_number":279,"context_line":"\t */"},{"line_number":280,"context_line":"\terr \u003d pci_sim_msi_domain_init(host);"},{"line_number":281,"context_line":"\tif (err) {"},{"line_number":282,"context_line":"\t\tpr_err(\"fake_pci: failed to create MSI domain for domain %04x: %d\\n\","},{"line_number":283,"context_line":"\t\t       host-\u003edomain_nr, err);"}],"source_content_type":"text/x-csrc","patch_set":26,"id":"552d25e2_2c7bf5f6","line":280,"updated":"2026-09-04 08:33:39.000000000","message":"fake_pci_sriov_core.c calls pci_sim_msi_domain_init(host) (line 280) and pci_sim_msi_domain_fini(host) (lines 308 and 324) in fake_pci_host_probe()/fake_pci_host_remove(), but neither function is defined or declared anywhere in this commit. A repository-wide grep for \u0027msi_domain\u0027 finds only these three call sites and a comment in fake_pci_sriov_nvme_poll.c referring to it. The commit message itself states the software MSI-X domain is \u0027added in the next commit\u0027. Modern kernels build with -Werror\u003dimplicit-function-declaration, and the linker would fail on the undefined symbols regardless, so \u0027make -C pci-sim modules\u0027 (and the Makefile check/test-build targets) cannot succeed at this commit.\n\n**Severity**: CRITICAL | **Confidence**: 0.95\n\n**Impact**: The module cannot be compiled or loaded at this commit, so every make target (modules, check, test-build, test) fails, and the series is not independently testable per the project guardrail. Bisecting or checking out this commit yields a broken build.\n\n**Priority**: Immediate\n**Recommendation**:\nEither move the pci_sim_msi_domain_init()/fini() calls into the commit that defines the software MSI-X domain, or add a minimal stub/definition (e.g. in a new fake_pci_sriov_msi.c compiled into the module) in this commit so the module builds and the poll path degrades gracefully as described in the commit message.","commit_id":"dd700467f638287da18ba08c9bdce22f1f0dd047"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"2dcb3df0c9289d6b2e7bca0e0ea0e0eaf2a096e2","unresolved":false,"context_lines":[{"line_number":277,"context_line":"\t * device\u0027s MSI domain and propagates it to the root bus.  VFs created"},{"line_number":278,"context_line":"\t * later by pci_enable_sriov() inherit it from the bus automatically."},{"line_number":279,"context_line":"\t */"},{"line_number":280,"context_line":"\terr \u003d pci_sim_msi_domain_init(host);"},{"line_number":281,"context_line":"\tif (err) {"},{"line_number":282,"context_line":"\t\tpr_err(\"fake_pci: failed to create MSI domain for domain %04x: %d\\n\","},{"line_number":283,"context_line":"\t\t       host-\u003edomain_nr, err);"}],"source_content_type":"text/x-csrc","patch_set":27,"id":"9da12c42_d2d40c6a","line":280,"updated":"2026-09-05 05:58:42.000000000","message":"fake_pci_sriov_core.c calls pci_sim_msi_domain_init(host) (line 280) and pci_sim_msi_domain_fini(host) (lines 308, 324), but neither function is declared or defined anywhere in the tree at this commit. A grep of pci-sim/ shows only these three call sites plus a comment reference in fake_pci_sriov_nvme_poll.c:33. The kernel build will fail on implicit function declaration and modpost will fail on the undefined symbols, so fake_pci_sriov.ko cannot be produced.\n\n**Severity**: CRITICAL | **Confidence**: 0.97\n\n**Impact**: fake_pci_sriov.ko fails to compile/link at this commit, so all pci-sim functionality, the new NVMe host test script (test_pci_sim_nvme_host.sh), and the documented Tempest whitebox flow cannot run. This also violates the project guardrail in AGENTS.md that Gerrit series are unsquashed and \u0027each commit must be independently testable and correct\u0027.\n\n**Priority**: Immediate\n**Recommendation**:\nLand the software MSI domain implementation in this commit, or keep the commit self-contained by stubbing/gating the calls (e.g. compat wrappers in fake_pci_sriov_compat.h that return 0 until the follow-up commit provides the real domain), so the module builds and the poll path is a true no-op as the commit message claims.","commit_id":"797d4ff09639a1b281ec01b1d4967dec518b17ab"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"8ffbeab1893067fc5a41067d288f49961241db29","unresolved":false,"context_lines":[{"line_number":277,"context_line":"\t * device\u0027s MSI domain and propagates it to the root bus.  VFs created"},{"line_number":278,"context_line":"\t * later by pci_enable_sriov() inherit it from the bus automatically."},{"line_number":279,"context_line":"\t */"},{"line_number":280,"context_line":"\terr \u003d pci_sim_msi_domain_init(host);"},{"line_number":281,"context_line":"\tif (err) {"},{"line_number":282,"context_line":"\t\tpr_err(\"fake_pci: failed to create MSI domain for domain %04x: %d\\n\","},{"line_number":283,"context_line":"\t\t       host-\u003edomain_nr, err);"}],"source_content_type":"text/x-csrc","patch_set":27,"id":"a2a20164_7ac53738","line":280,"updated":"2026-09-07 06:04:38.000000000","message":"fake_pci_sriov_core.c calls pci_sim_msi_domain_init(host) in fake_pci_host_probe() (line 280) and pci_sim_msi_domain_fini(host) on the probe-error and host-remove paths (lines 308, 324), but neither function is defined or declared anywhere in this commit. A repo-wide grep finds only the two call sites and a comment reference in fake_pci_sriov_nvme_poll.c:33. The Makefile compiles all listed .c files into fake_pci_sriov.ko, so linking fails with undefined symbols and \u0027make -C pci-sim modules\u0027 cannot succeed at commit 797d4ff. The commit message itself says the software MSI-X domain is \u0027added in the next commit\u0027 and that \u0027the poll path is a no-op until then\u0027, yet the code unconditionally requires it at probe time.\n\n**Severity**: CRITICAL | **Confidence**: 0.92\n\n**Impact**: The pci-sim module fails to link at this commit; every mode (UART, VFIO, NVMe host char dev, memmap poll) is unusable until the follow-up commit lands. This breaks the project requirement that each commit in a Gerrit series build and pass tests independently, and makes bisecting the series impossible.\n\n**Priority**: Immediate\n**Recommendation**:\nMove the pci_sim_msi_domain_init()/fini() calls (and the error-path unwinding added for them) into the commit that adds the software MSI-X domain, or add the domain implementation to this commit. Alternatively make the calls conditional on a compatibility stub in fake_pci_sriov_compat.h so the module builds and the poll path stays a no-op as the commit message describes.","commit_id":"797d4ff09639a1b281ec01b1d4967dec518b17ab"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"6d9fb80205038548d9da0966a54d9907a86e0482","unresolved":false,"context_lines":[{"line_number":277,"context_line":"\t * device\u0027s MSI domain and propagates it to the root bus.  VFs created"},{"line_number":278,"context_line":"\t * later by pci_enable_sriov() inherit it from the bus automatically."},{"line_number":279,"context_line":"\t */"},{"line_number":280,"context_line":"\terr \u003d pci_sim_msi_domain_init(host);"},{"line_number":281,"context_line":"\tif (err) {"},{"line_number":282,"context_line":"\t\tpr_err(\"fake_pci: failed to create MSI domain for domain %04x: %d\\n\","},{"line_number":283,"context_line":"\t\t       host-\u003edomain_nr, err);"}],"source_content_type":"text/x-csrc","patch_set":28,"id":"8c95ade2_ff8a6c04","line":280,"updated":"2026-09-07 16:57:30.000000000","message":"fake_pci_sriov_core.c calls pci_sim_msi_domain_init() (line 280) and pci_sim_msi_domain_fini() (lines 308, 324), but neither function is defined or declared anywhere in the repository at commit ec86791. A tree-wide grep finds only these three call sites plus a comment in fake_pci_sriov_nvme_poll.c:33. The commit message itself states the software MSI-X domain is \u0027added in the next commit\u0027. The fake_pci_sriov.ko link step therefore fails with undefined references.\n\n**Severity**: HIGH | **Confidence**: 0.95\n\n**Impact**: This commit cannot be built, loaded, or tested on its own; the module link fails (undefined reference to pci_sim_msi_domain_init/fini), breaking the independently-testable-commit requirement for the series.\n\n**Priority**: Before merge\n**Recommendation**:\nMove the pci_sim_msi_domain_init/fini call sites (and the err_free_bridge handling) into the commit that adds the software MSI-X domain, or add minimal stub definitions in this commit so the module links standalone.","commit_id":"ec86791c7f606998a376188efbffaa4506ab92cf"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"c8bf625f8db5753ee943267c11cac889421c1240","unresolved":false,"context_lines":[{"line_number":212,"context_line":""},{"line_number":213,"context_line":"\tmutex_init(\u0026host-\u003elock);"},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"\thost-\u003epersonality \u003d PCI_SIM_VF_PERS_UNSET;"},{"line_number":216,"context_line":"\thost-\u003epersonality_ops \u003d NULL;"},{"line_number":217,"context_line":""},{"line_number":218,"context_line":"\t/*"}],"source_content_type":"text/x-csrc","patch_set":30,"id":"25fe8c87_b8841c37","line":215,"updated":"2026-09-08 13:05:13.000000000","message":"When nvme_memmap_start/nvme_memmap_size are set, fake_pci_host_probe() pre-sets host-\u003epersonality/ops and programs BAR addresses directly, but never calls ops-\u003ehost_init(). The only caller of host_init is vf_personality_store() (fake_pci_sriov_cfg.c:660). pci_sim_nvme_host_init() is what performs the ioremap into host-\u003ebar0_mapped, so in the pre-selected path bar0_mapped stays NULL: pci_sim_nvme_sriov_enable() returns 0 immediately (no poll kthread, no pci_sim_nvme_poll_preinit_vfs, no BAR0 CAP/VS pre-init), and pci_sim_nvme_host_probe() only declines the VF when host-\u003ebar0_mapped is set (fake_pci_sriov_nvme_host.c:323), so the fake VFs bind to the char driver instead of the stock nvme driver.\n\n**Severity**: HIGH | **Confidence**: 0.8\n\n**Impact**: In the documented memmap configuration that relies on module parameters alone (no sysfs personality re-write), VF BAR0 reserved memory is never initialized or polled, the stock nvme driver never binds, and VFs are silently claimed by the pci_sim_nvme_host char driver instead. The Phase 2 feature this commit describes is non-functional on that supported path.\n\n**Priority**: Before merge\n**Recommendation**:\nIn fake_pci_host_probe(), after pre-setting personality_ops for memmap mode, call host-\u003epersonality_ops-\u003ehost_init(host) and unwind on failure (or call it before pci host bridge registration completes), so the pre-selected path matches the sysfs path. Alternatively, have pci_sim_nvme_host_probe() decline based on the memmap module parameters rather than bar0_mapped.","commit_id":"b2c98611a875c9a2de076c5f4d346a52eb22ef78"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"b9da9f1b1a37991ff229b02fe09aa5f4532567e6","unresolved":false,"context_lines":[{"line_number":285,"context_line":"\t * Pre-set NVMe personality when memmap params are provided so the"},{"line_number":286,"context_line":"\t * SR-IOV BAR size probe during pci_host_probe() picks up the 16KB"},{"line_number":287,"context_line":"\t * NVMe BAR0 instead of the 4KB default."},{"line_number":288,"context_line":"\t */"},{"line_number":289,"context_line":"\tif (fake_pci_host_is_nvme(index)) {"},{"line_number":290,"context_line":"\t\thost-\u003epersonality \u003d PCI_SIM_VF_PERS_NVME;"},{"line_number":291,"context_line":"\t\thost-\u003epersonality_ops \u003d pci_sim_get_ops(PCI_SIM_VF_PERS_NVME);"}],"source_content_type":"text/x-csrc","patch_set":32,"id":"d22e9d5c_005f0e89","line":288,"updated":"2026-09-09 06:58:35.000000000","message":"fake_pci_host_probe() pre-sets personality/ops when nvme_memmap_start+size are given, but the only caller of pci_sim_personality_ops-\u003ehost_init() is vf_personality_store() (fake_pci_sriov_cfg.c:673). Consequently host-\u003ebar0_mapped stays NULL: pci_sim_nvme_sriov_enable() returns early at fake_pci_sriov_nvme.c:1392 (no pci_sim_nvme_poll_preinit_vfs, no BAR0 CAP/VS pre-init, no kthread), and pci_sim_nvme_host_probe() does not take its -ENODEV decline at fake_pci_sriov_nvme_host.c:323 because bar0_mapped is unset, so the char-device driver binds instead of the stock nvme driver. Memmap mode silently degrades to Phase 1 behavior with uninitialized reserved-RAM BAR0.\n\n**Severity**: HIGH | **Confidence**: 0.85\n\n**Impact**: The memmap/stock-nvme mode — the primary purpose of the new poll module — does not work when used as documented (load with memmap params and enable VFs): VFs bind to the char-device driver with BAR0 containing uninitialized reserved RAM instead of a pre-initialized NVMe register set, and no polling kthread runs.\n\n**Priority**: Before merge\n**Recommendation**:\nIn fake_pci_host_probe(), after pre-setting personality_ops, call host-\u003epersonality_ops-\u003ehost_init(host) and unwind on failure (mirroring the vf_personality_store() error handling). Alternatively make the test/docs require the explicit sysfs personality write in memmap mode, but the code fix matches the documented module-load flow.","commit_id":"346c240b00496988cb10b651472020e1f21b3537"}],"pci-sim/fake_pci_sriov_nvme.c":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"7d1aed30154fc155c41bbb6a0819c66b4ac4edfb","unresolved":false,"context_lines":[{"line_number":285,"context_line":"\tput_unaligned_le16(0x0008, id + 520); /* ONCS: Write Zeroes */"},{"line_number":286,"context_line":"\tid[524] \u003d 0x01; /* FNA: format all NS */"},{"line_number":287,"context_line":"\tid[525] \u003d 0x00; /* VWC */"},{"line_number":288,"context_line":"\tput_unaligned_le32(0x00000006, id + 328); /* SANICAP: BES + Overwrite */"},{"line_number":289,"context_line":"\tsnprintf((char *)(id + 768), 256,"},{"line_number":290,"context_line":"\t\t \"nqn.2024-01.org.openstack.cyborg:pci-sim-nvme-%04d\","},{"line_number":291,"context_line":"\t\t nvme-\u003evf_index);"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"4b5ef120_c3655808","line":288,"updated":"2026-08-07 08:38:46.000000000","message":"The SANICAP field is set to 0x6 (CES+BES) but the comment says \u0027BES + Overwrite\u0027. Overwrite (OWS, bit 0) is not set despite being implemented in the sanitize handler. The comment is factually wrong about which NVMe spec bits the value encodes.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: The comment misleads maintainers about which sanitize operations are advertised. If SANICAP should include Overwrite (since it is implemented), the value should be 0x7. If only CES+BES is intended, the comment should say \u0027CES + BES\u0027 to match the commit message.\n\n**Suggestion**:\nEither set SANICAP to 0x7 to advertise all three implemented operations (CES+BES+OWS) and update the comment, or fix the comment to say \u0027CES + BES\u0027 if Overwrite is intentionally omitted. Align with the commit message which says \u0027CES/BES\u0027.","commit_id":"8ea2eb20b6720e5177ebfbfede3670c608136ffc"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"198d83783d31f82835cc5deb92eccf9f47a508c8","unresolved":false,"context_lines":[{"line_number":274,"context_line":"\tid[77] \u003d PCI_SIM_NVME_MDTS; /* 2^MDTS * MPSMIN \u003d 128KB */"},{"line_number":275,"context_line":"\tput_unaligned_le16(nvme-\u003evf_index + 1, id + 78); /* CNTLID */"},{"line_number":276,"context_line":"\tput_unaligned_le32(0x00010400, id + 80); /* VS: NVMe 1.4 */"},{"line_number":277,"context_line":"\tput_unaligned_le16(0x0022, id + 256); /* OACS: Format + Sanitize */"},{"line_number":278,"context_line":"\tid[258] \u003d 3; /* ACL */"},{"line_number":279,"context_line":"\tid[259] \u003d 3; /* AERL */"},{"line_number":280,"context_line":"\tid[260] \u003d 0x02; /* FRMW */"}],"source_content_type":"text/x-csrc","patch_set":3,"id":"214a79c0_5f070261","line":277,"updated":"2026-08-07 18:07:47.000000000","message":"The Identify Controller OACS field at byte 256 is 0x0022 (bits 1 and 5). NVMe 1.4 defines OACS bit 1\u003dFormat, bit 3\u003dNamespace Management. The commit says \u0027oacs bit 3 for namespace management\u0027 but 0x22 does not set bit 3. Bit 5 is undefined in NVMe 1.4. Correct value for Format + NS Management is 0...\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: nvme-cli and the Cyborg NVMe driver see an undefined OACS bit set and namespace management not advertised. Tools checking this field will not attempt namespace management commands.\n\n**Suggestion**:\nChange the value to 0x000A (bits 1 and 3 \u003d Format + Namespace Management) to match the commit message intent, or 0x0002 if only Format is intended.","commit_id":"f3159e05b31f758c11457a19a686cf50759643e0"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"198d83783d31f82835cc5deb92eccf9f47a508c8","unresolved":false,"context_lines":[{"line_number":285,"context_line":"\tput_unaligned_le16(0x0008, id + 520); /* ONCS: Write Zeroes */"},{"line_number":286,"context_line":"\tid[524] \u003d 0x01; /* FNA: format all NS */"},{"line_number":287,"context_line":"\tid[525] \u003d 0x00; /* VWC */"},{"line_number":288,"context_line":"\tput_unaligned_le32(0x00000006, id + 328); /* SANICAP: BES + Overwrite */"},{"line_number":289,"context_line":"\tsnprintf((char *)(id + 768), 256,"},{"line_number":290,"context_line":"\t\t \"nqn.2024-01.org.openstack.cyborg:pci-sim-nvme-%04d\","},{"line_number":291,"context_line":"\t\t nvme-\u003evf_index);"}],"source_content_type":"text/x-csrc","patch_set":3,"id":"4104faa0_ebe8cef3","line":288,"updated":"2026-08-07 18:07:47.000000000","message":"The Identify Controller SANICAP field at byte 328 is 0x00000006 (bits 1+2 \u003d CES+OWS), but the comment says \u0027BES + Overwrite\u0027. NVMe spec: bit 0\u003dBES, bit 1\u003dCES, bit 2\u003dOWS. The controller supports all three (sanact\u003d2 Block Erase, 3 Overwrite, 4 Crypto Erase) but BES (bit 0) is not set. The Cyborg dr...\n\n**Severity**: HIGH | **Confidence**: 0.8\n\n**Risk**: The Cyborg NVMe driver discovery path reads SANICAP to determine HW_NVME_BES/CES traits. Missing BES means block-erase sanitize tests will have mismatched trait advertising. The misleading comment could confuse future maintainers.\n\n**Priority**: Before merge\n**Why This Matters**: The Cyborg NVMe driver discovery path reads SANICAP to determine HW_NVME_BES/CES traits. Missing BES means block-erase sanitize tests will have mismatched trait advertising. The misleading comment could confuse future maintainers.\n\n**Recommendation**:\nSet SANICAP to 0x00000007 to advertise all three supported methods (BES+CES+OWS). Alternatively, if only CES+OWS is intended, fix the comment to \u0027CES + Overwrite\u0027.","commit_id":"f3159e05b31f758c11457a19a686cf50759643e0"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"26d8237f5d381bcc64f3e965034465869e1bc1d8","unresolved":false,"context_lines":[{"line_number":863,"context_line":"\t\tstatus \u003d NVME_SC_INVALID_OPCODE;"},{"line_number":864,"context_line":"\t}"},{"line_number":865,"context_line":""},{"line_number":866,"context_line":"\tsq_head \u003d admin_sq-\u003esq_head;"},{"line_number":867,"context_line":"\tpr_debug(\"pci_sim_nvme: admin opcode\u003d0x%02x cid\u003d%u status\u003d0x%04x result\u003d0x%08x\\n\","},{"line_number":868,"context_line":"\t\t cmd-\u003eopcode, le16_to_cpu(cmd-\u003ecommand_id), status, result);"},{"line_number":869,"context_line":"\tnvme_sim_post_completion(nvme, 0, sq_head, 0,"}],"source_content_type":"text/x-csrc","patch_set":5,"id":"9c94248b_81d8eb77","line":866,"updated":"2026-08-11 11:04:26.000000000","message":"In nvme_sim_process_admin_cmd and nvme_sim_process_io_cmd, the CQE sq_head field is set to the current SQ head value before the head is incremented. Per the NVMe spec, the SQ Head pointer is incremented when the controller fetches a command, so the CQE should report the head value after advancing...\n\n**Severity**: HIGH | **Confidence**: 0.8\n\n**Risk**: Real NVMe drivers use CQE sq_head to track which SQ entries the controller has consumed. Reporting the current entry\u0027s index instead of the next index means the driver thinks fewer entries have been consumed than actually have. Under concurrent I/O workloads with multiple outstanding commands, th...\n\n**Priority**: Before merge\n**Why This Matters**: Real NVMe drivers use CQE sq_head to track which SQ entries the controller has consumed. Reporting the current entry\u0027s index instead of the next index means the driver thinks fewer entries have been consumed than actually have. Under concurrent I/O workloads with multiple outstanding commands, th...\n\n**Recommendation**:\nIncrement sq-\u003esq_head before reading it for the CQE, or pass (sq-\u003esq_head + 1) wrapped to sq_depth as the sq_head value to nvme_sim_post_completion. The simplest fix: move the head increment in nvme_sim_process_sq to before the command handler call, so the handler sees the already-advanced value.","commit_id":"48f7f9c8c2c7170a080284d9d2bb1d2d8941464b"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"dc7934f877c0b7af7cb63c87e2919599282e664e","unresolved":false,"context_lines":[{"line_number":1487,"context_line":"\tnvme-\u003enum_io_queues \u003d 0;"},{"line_number":1488,"context_line":"}"},{"line_number":1489,"context_line":""},{"line_number":1490,"context_line":"void pci_sim_nvme_close(struct pci_sim_nvme *nvme)"},{"line_number":1491,"context_line":"{"},{"line_number":1492,"context_line":"\tpci_sim_nvme_reset(nvme);"},{"line_number":1493,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":8,"id":"ed04a5a5_d250c24e","line":1490,"updated":"2026-08-12 16:58:47.000000000","message":"The function pci_sim_nvme_close() is implemented in fake_pci_sriov_nvme.c and declared in fake_pci_sriov_nvme.h, but no code path in any translation unit ever calls it. It duplicates pci_sim_nvme_reset + file zeroing logic.\n\n**Severity**: SUGGESTION | **Confidence**: 0.9\n\n**Benefit**: Dead exported function adds maintenance burden and potential confusion about which cleanup path to use. A future maintainer might call pci_sim_nvme_close instead of pci_sim_nvme_cleanup, introducing different teardown semantics (file zeroing vs file closing).\n\n**Recommendation**:\nRemove pci_sim_nvme_close() and its declaration, or add a comment explaining its intended future use if this is deliberate API scaffolding.","commit_id":"cbc262d47285399a74084797a1f330b1c49c93aa"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"3cc84dd82326911723c19f8732a75232bf07ae20","unresolved":false,"context_lines":[{"line_number":326,"context_line":"\tput_unaligned_le64(nvme-\u003enum_lbas, id + 0); /* NSZE */"},{"line_number":327,"context_line":"\tput_unaligned_le64(nvme-\u003enum_lbas, id + 8); /* NCAP */"},{"line_number":328,"context_line":"\tput_unaligned_le64(nvme-\u003enum_lbas, id + 16); /* NUSE */"},{"line_number":329,"context_line":"\tid[25] \u003d 1; /* NLBAF: 2 formats */"},{"line_number":330,"context_line":"\tid[26] \u003d (nvme-\u003elba_size \u003d\u003d 4096) ? 1 : 0; /* FLBAS */"},{"line_number":331,"context_line":"\tid[128 + 2] \u003d 9; /* LBAF[0] DS\u003d512B */"},{"line_number":332,"context_line":"\tid[132 + 2] \u003d 12; /* LBAF[1] DS\u003d4KB */"}],"source_content_type":"text/x-csrc","patch_set":9,"id":"4eec45df_fae72769","line":329,"updated":"2026-08-13 07:46:04.000000000","message":"In pci_sim_nvme_fill_identify_ns(), id[25] \u003d 1 is documented as \u0027NLBAF: 2 formats\u0027 but NVMe spec defines NLBAF as number of LBA formats minus 1. The code is correct but the comment is misleading.\n\n**Severity**: SUGGESTION | **Confidence**: 0.8\n\n**Benefit**: The code is correct but the comment could confuse future developers into misreading NLBAF\u003d1 as \u00271 format\u0027 and adding or removing LBAF entries incorrectly.\n\n**Recommendation**:\nClarify the comment: /* NLBAF: 1 (\u003d 2 formats: 512B and 4KB, per spec NLBAF \u003d count-1) */","commit_id":"91dee44dd0069b60f7d3833de32ccce976efb9dc"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"3cc84dd82326911723c19f8732a75232bf07ae20","unresolved":false,"context_lines":[{"line_number":1435,"context_line":"\t\tnvme-\u003ebacking_fp \u003d NULL;"},{"line_number":1436,"context_line":"\t\treturn err;"},{"line_number":1437,"context_line":"\t}"},{"line_number":1438,"context_line":"\terr \u003d vfs_truncate(\u0026nvme-\u003ebacking_fp-\u003ef_path, sz);"},{"line_number":1439,"context_line":"\tif (err) {"},{"line_number":1440,"context_line":"\t\tpr_err(\"pci_sim_nvme: failed to size backing file %s: %d\\n\","},{"line_number":1441,"context_line":"\t\t       path, err);"}],"source_content_type":"text/x-csrc","patch_set":9,"id":"da0b9a67_b6ba73b2","line":1438,"updated":"2026-08-13 07:46:04.000000000","message":"pci_sim_nvme_init() calls vfs_truncate() but fake_pci_sriov_nvme.c does not explicitly include \u003clinux/fs.h\u003e. The function may resolve transitively through other headers on some kernels but this is fragile.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: On some kernel configurations the build may produce implicit function declaration warnings or fail. At runtime, vfs_truncate may not size files correctly on all filesystems without proper locking.\n\n**Suggestion**:\nAdd #include \u003clinux/fs.h\u003e explicitly. Consider using vfs_fallocate or writing to the file end position for more portable file sizing.","commit_id":"91dee44dd0069b60f7d3833de32ccce976efb9dc"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"3cc84dd82326911723c19f8732a75232bf07ae20","unresolved":false,"context_lines":[{"line_number":1487,"context_line":"\tnvme-\u003enum_io_queues \u003d 0;"},{"line_number":1488,"context_line":"}"},{"line_number":1489,"context_line":""},{"line_number":1490,"context_line":"void pci_sim_nvme_close(struct pci_sim_nvme *nvme)"},{"line_number":1491,"context_line":"{"},{"line_number":1492,"context_line":"\tpci_sim_nvme_reset(nvme);"},{"line_number":1493,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":9,"id":"d731b0c0_9cd734b9","line":1490,"updated":"2026-08-13 07:46:04.000000000","message":"pci_sim_nvme_close() is declared in the header and defined in fake_pci_sriov_nvme.c, but no code anywhere in the module calls it. The cleanup path uses pci_sim_nvme_cleanup() instead.\n\n**Severity**: SUGGESTION | **Confidence**: 0.9\n\n**Benefit**: Dead exported function increases maintenance burden and may confuse future developers into thinking it is part of the cleanup path.\n\n**Recommendation**:\nRemove pci_sim_nvme_close() and its declaration, or add a caller if the zeroing-on-close behavior was intended.","commit_id":"91dee44dd0069b60f7d3833de32ccce976efb9dc"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"f8e0ed2121cb6bcf3429c51a9e23c187f2662231","unresolved":false,"context_lines":[{"line_number":863,"context_line":"\t\tstatus \u003d NVME_SC_INVALID_OPCODE;"},{"line_number":864,"context_line":"\t}"},{"line_number":865,"context_line":""},{"line_number":866,"context_line":"\tsq_head \u003d admin_sq-\u003esq_head;"},{"line_number":867,"context_line":"\tpr_debug(\"pci_sim_nvme: admin opcode\u003d0x%02x cid\u003d%u status\u003d0x%04x result\u003d0x%08x\\n\","},{"line_number":868,"context_line":"\t\t cmd-\u003eopcode, le16_to_cpu(cmd-\u003ecommand_id), status, result);"},{"line_number":869,"context_line":"\tnvme_sim_post_completion(nvme, 0, sq_head, 0,"}],"source_content_type":"text/x-csrc","patch_set":10,"id":"83071a50_73198a09","line":866,"updated":"2026-08-13 16:20:37.000000000","message":"In nvme_sim_process_admin_cmd and nvme_sim_process_io_cmd, the current sq_head is captured BEFORE nvme_sim_process_sq increments it. The CQE\u0027s sq_head field reports the index of the entry being consumed rather than the next expected entry. Per the NVMe spec, the CQE sq_head should indicate the cu...\n\n**Severity**: HIGH | **Confidence**: 0.8\n\n**Risk**: Guest NVMe drivers use CQE.SQHD to track consumed entries. Reporting a stale pre-increment value may cause the guest driver to believe entries have not been consumed, leading to incorrect queue management, potential command reprocessing, or stalls. For the host char-device path this is benign, bu...\n\n**Priority**: Before merge\n**Why This Matters**: Guest NVMe drivers use CQE.SQHD to track consumed entries. Reporting a stale pre-increment value may cause the guest driver to believe entries have not been consumed, leading to incorrect queue management, potential command reprocessing, or stalls. For the host char-device path this is benign, bu...\n\n**Recommendation**:\nMove the sq_head capture to AFTER the increment. Restructure nvme_sim_process_sq to increment sq_head before calling the command processor, or have the command processors read the incremented value. For example: increment sq-\u003esq_head first, pass the new value to the processor, then post completion with the already-incremented head.","commit_id":"85c5e1594db0d8475029a94c8301ded3c6fac562"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"638387b1b971bdf446b014c95604970d6f433843","unresolved":false,"context_lines":[{"line_number":274,"context_line":"\tid[77] \u003d PCI_SIM_NVME_MDTS; /* 2^MDTS * MPSMIN \u003d 128KB */"},{"line_number":275,"context_line":"\tput_unaligned_le16(nvme-\u003evf_index + 1, id + 78); /* CNTLID */"},{"line_number":276,"context_line":"\tput_unaligned_le32(0x00010400, id + 80); /* VS: NVMe 1.4 */"},{"line_number":277,"context_line":"\tput_unaligned_le16(0x0022, id + 256); /* OACS: Format + Sanitize */"},{"line_number":278,"context_line":"\tid[258] \u003d 3; /* ACL */"},{"line_number":279,"context_line":"\tid[259] \u003d 3; /* AERL */"},{"line_number":280,"context_line":"\tid[260] \u003d 0x02; /* FRMW */"}],"source_content_type":"text/x-csrc","patch_set":11,"id":"09d38f75_0845691f","line":277,"updated":"2026-08-14 17:39:44.000000000","message":"The commit message advertises \"oacs bit 3 for namespace management\", but pci_sim_nvme_fill_identify_ctrl() writes OACS\u003d0x0022 (bit 4 Format + bit 5 Sanitize only); bit 3 (Namespace Management) is clear. The NVMe namespace-management commands are not implemented anywhere in the emulator.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Reviewer/user expectation mismatch: Cyborg\u0027s cleanup flow will take the ns_mgmt\u003dFalse path for simulated devices, which is likely the intent, but the commit message and commit-message-derived docs claim a capability the emulator does not have, misinforming future maintenance and test authors.\n\n**Suggestion**:\nCorrect the commit message (drop the \"oacs bit 3 for namespace management\" claim) or set the OACS namespace-management bit and implement the NS identify/list/detach/attach commands; also reconcile with the test script\u0027s 0x22 assertion.","commit_id":"5e0f10479483b1d53407eacd8b81fce64a4ce13e"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"638387b1b971bdf446b014c95604970d6f433843","unresolved":false,"context_lines":[{"line_number":757,"context_line":"\tcase 2: /* Block Erase */"},{"line_number":758,"context_line":"\t\tif (nvme_sim_file_zero(nvme-\u003ebacking_fp, 0, nvme-\u003estorage_size))"},{"line_number":759,"context_line":"\t\t\treturn NVME_SC_INTERNAL;"},{"line_number":760,"context_line":"\t\tnvme-\u003esanitize_sstat \u003d 0x0101;"},{"line_number":761,"context_line":"\t\tnvme-\u003esanitize_progress \u003d 0xFFFF;"},{"line_number":762,"context_line":"\t\tbreak;"},{"line_number":763,"context_line":"\tcase 3: /* Overwrite */"}],"source_content_type":"text/x-csrc","patch_set":11,"id":"62e5ebbd_cb1fe5b8","line":760,"updated":"2026-08-14 17:39:44.000000000","message":"After a sanitize operation completes, sanitize_sstat is set to 0x0101 whose SSTAT status field (bits 2:0) is 1 \u003d \"operation in progress\", while sanitize_progress is set to 0xFFFF (100% complete). No code ever transitions the status to \"completed\" (2) or \"idle\" (0).\n\n**Severity**: HIGH | **Confidence**: 0.8\n\n**Risk**: Cyborg\u0027s NVMe driver cleanup path (the primary consumer this simulator exists to test) will time out with DeviceCleanupFailed after every sanitize on a simulated device, failing exactly the whitebox Tempest flow this patch is meant to enable.\n\n**Priority**: Before merge\n**Why This Matters**: Cyborg\u0027s NVMe driver cleanup path (the primary consumer this simulator exists to test) will time out with DeviceCleanupFailed after every sanitize on a simulated device, failing exactly the whitebox Tempest flow this patch is meant to enable.\n\n**Recommendation**:\nSet sanitize_sstat \u003d 0x0002 (completed, no failures) once the file zero/fill finishes, or report 0x0000 with SPROG 0xFFFF; add a state that _should_start_sanitize/_poll_sanitize in cyborg\u0027s driver recognizes as idle/complete.","commit_id":"5e0f10479483b1d53407eacd8b81fce64a4ce13e"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"d3677ade691b88d8973ba4ab2f10aaa5218e7241","unresolved":false,"context_lines":[{"line_number":677,"context_line":"\tu8 lid \u003d le32_to_cpu(cmd-\u003ecdw10) \u0026 0xFF;"},{"line_number":678,"context_line":"\tu16 numdl \u003d (le32_to_cpu(cmd-\u003ecdw10) \u003e\u003e 16) \u0026 0xFFFF;"},{"line_number":679,"context_line":"\tu16 numdu \u003d le32_to_cpu(cmd-\u003ecdw11) \u0026 0xFFFF;"},{"line_number":680,"context_line":"\tu32 num_dwords \u003d ((u32)numdu \u003c\u003c 16) | numdl;"},{"line_number":681,"context_line":"\tsize_t len \u003d ((size_t)num_dwords + 1) * 4;"},{"line_number":682,"context_line":"\tu8 *buf;"},{"line_number":683,"context_line":"\tint ret;"}],"source_content_type":"text/x-csrc","patch_set":12,"id":"693f1f31_77499dd2","line":680,"updated":"2026-08-15 18:21:04.000000000","message":"nvme_sim_get_log_page() clamps the requested dword count to 4096 bytes without adjusting the response or signalling, and any PRP transfer failure is folded into generic NVME_SC_INTERNAL.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Guests or nvme-cli invocations requesting log pages larger than 4KB receive silently truncated data; the log-page LID constants also advertise a version the controller does not declare, so well-behaved clients can misreport the device.\n\n**Suggestion**:\nReturn NVME_SC_INVALID_FIELD when the requested length exceeds the supported maximum instead of silently clamping, keep NUMDL/NUMDU handling consistent between the guest and host paths, and either bump VS to the version whose log LIDs are implemented or restrict LIDs to what NVMe 1.4 defines.","commit_id":"eb2ac338ef251974ab6df241a90c304c223124ae"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"060042c30ba61f1ac162de1c49ef7bf81521b6c0","unresolved":false,"context_lines":[{"line_number":274,"context_line":"\tid[77] \u003d PCI_SIM_NVME_MDTS; /* 2^MDTS * MPSMIN \u003d 128KB */"},{"line_number":275,"context_line":"\tput_unaligned_le16(nvme-\u003evf_index + 1, id + 78); /* CNTLID */"},{"line_number":276,"context_line":"\tput_unaligned_le32(0x00010400, id + 80); /* VS: NVMe 1.4 */"},{"line_number":277,"context_line":"\tput_unaligned_le16(0x0022, id + 256); /* OACS: Format + Sanitize */"},{"line_number":278,"context_line":"\tid[258] \u003d 3; /* ACL */"},{"line_number":279,"context_line":"\tid[259] \u003d 3; /* AERL */"},{"line_number":280,"context_line":"\tid[260] \u003d 0x02; /* FRMW */"}],"source_content_type":"text/x-csrc","patch_set":15,"id":"aad8d0e4_00ab934f","line":277,"updated":"2026-08-21 13:28:38.000000000","message":"The Identify Controller data sets OACS\u003d0x0022 with the comment \u0027Format + Sanitize\u0027, but in NVMe 1.4 OACS bit0\u003dFormat, bit1\u003dSecurity Send/Receive, bit2\u003dNVM Namespace Management, and bit5\u003dNVMe-MI; there is no OACS bit for Sanitize (that is SANICAP). 0x0022 therefore advertises Security Send/Receive and NVMe-MI Send/Receive, neither of which the admin dispatcher implements (both return Invalid Opcode), while namespace management - which the commit message explicitly claims (\u0027oacs bit 3 for namespace management\u0027) - is neither advertised nor implemented (no 0x0D/0x0C handling). The test script hard-codes the same wrong value with the same wrong rationale. Relatedly, SANICAP is set to 0x6 (BES+Overwrite) while the commit message claims CES/BES.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Guest/host tools that consult OACS before issuing commands (e.g. nvme-cli security or NVMe-MI paths) will attempt admin commands that are advertised but unimplemented and fail with Invalid Opcode; the namespace-management capability stated in the commit message is silently absent, so dependent tooling cannot discover it. Misleading capability bits also make the simulator diverge from real-device behavior it is meant to mimic for whitebox testing.\n\n**Suggestion**:\nSet OACS to the bits actually implemented (Format only, 0x0001, unless namespace management commands are added - then bit 2, 0x0005), fix the inline comment and the test-script assertion rationale, and align the commit-message capability list (including the CES/BES SANICAP claim) with the values actually programmed.","commit_id":"e75bcc46da049aeaab64e70f7d07d3fe48d90140"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3f1619780058af2dc79e93fd0fb3d294ce4ca79e","unresolved":true,"context_lines":[{"line_number":27,"context_line":""},{"line_number":28,"context_line":"#define PCI_SIM_MSIX_CAP_OFFSET 0x80"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"static void init_msix_capability(u8 *config)"},{"line_number":31,"context_line":"{"},{"line_number":32,"context_line":"\tu8 *cap \u003d \u0026config[PCI_SIM_MSIX_CAP_OFFSET];"},{"line_number":33,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":22,"id":"638a87e1_e57fa275","line":30,"updated":"2026-08-26 19:25:29.000000000","message":"so this does not work\n\nhttps://paste.opendev.org/show/brzM3rSSxxIzgVr0cuIR/\n\ntesting this locally the stock nvme driver cant bind properly because we are not properly implementing msix interupts\n\nwe should implement virtual interups and a seperate msix domain the asme as we emulat a pci domian","commit_id":"e8ab207f032cf2778beb34ac6bdcecea9df54d2c"},{"author":{"_account_id":12393,"name":"chandan kumar","display_name":"Chandan Kumar","email":"chkumar@redhat.com","username":"chkumar246"},"change_message_id":"9362458740d71149222537735fa8508573b469e0","unresolved":true,"context_lines":[{"line_number":27,"context_line":""},{"line_number":28,"context_line":"#define PCI_SIM_MSIX_CAP_OFFSET 0x80"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"static void init_msix_capability(u8 *config)"},{"line_number":31,"context_line":"{"},{"line_number":32,"context_line":"\tu8 *cap \u003d \u0026config[PCI_SIM_MSIX_CAP_OFFSET];"},{"line_number":33,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":22,"id":"1ae1d8eb_c6f117f2","line":30,"in_reply_to":"638a87e1_e57fa275","updated":"2026-08-27 05:08:20.000000000","message":"Thank you @smooney@redhat.com for testing it. \n\nYou are correct. The integration will be broken for stock driver without MSI.\n\nI never thought about Message Signaled Interrupt while doing the implementation. Based on nvmevirt code, I assumed adding memmap and Bar implementation will fully implement the nvme implementation. It somehow working in the guest side.\n\nLet me think about this one and add it.\n\nOnce I have the code ready with smi, I will let you know for further testing.","commit_id":"e8ab207f032cf2778beb34ac6bdcecea9df54d2c"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"1daa79a349663ef155d31135baae8699ee6a4a17","unresolved":false,"context_lines":[{"line_number":82,"context_line":"\t\treturn;"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"\t/* CQ full: tail is about to overwrite unprocessed entries */"},{"line_number":85,"context_line":"\tif (cq-\u003ecq_depth \u0026\u0026 (cq-\u003ecq_tail + 1) % cq-\u003ecq_depth \u003d\u003d cq-\u003ecq_head)"},{"line_number":86,"context_line":"\t\treturn;"},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"\tcqe \u003d (struct pci_sim_nvme_cqe *)cq-\u003ecq_base + cq-\u003ecq_tail;"}],"source_content_type":"text/x-csrc","patch_set":23,"id":"42756629_9d088ad3","line":85,"updated":"2026-09-01 12:06:53.000000000","message":"nvme_sim_post_completion() rejects a completion whenever (cq_tail + 1) % cq_depth \u003d\u003d cq_head, i.e. the classic ring-buffer check that sacrifices one slot to distinguish full from empty. NVMe completion queues carry a phase bit precisely so all cq_depth entries can be occupied. With an empty CQ (head \u003d\u003d tail \u003d\u003d 0), only depth-1 completions can ever be posted: posting the depth-th entry evaluates (depth-1+1)%depth \u003d\u003d 0 \u003d\u003d head and silently returns. Because nvme_sim_process_sq() already advanced sq_head before dispatch, the dropped completion is lost forever; no error is posted and the entry cannot be retried.\n\n**Severity**: HIGH | **Confidence**: 0.75\n\n**Impact**: Any driver that keeps queue_depth commands outstanding - the normal case for the stock nvme driver or guest kernels under queue-depth-saturating I/O, which is this fixture\u0027s stated purpose - loses the last completion and blocks until the command times out, triggering controller resets or I/O errors. The controller also permanently under-advertises usable CQ capacity relative to the depth it negotiated.\n\n**Priority**: Before merge\n**Recommendation**:\nTrack occupancy explicitly instead of sacrificing a slot: maintain a count or compute (cq_tail - cq_head) mod depth and treat the queue as full only when that equals cq_depth, relying on the existing cq_phase toggle for wrap detection (as the NVMe phase bit is designed for). At minimum, do not silently return; the current check makes the last CQ slot permanently unusable.","commit_id":"ef7c3a02905f8b20910ce630fe68af640a0fdea6"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"dd8eae7587132645990f464e644baf7a13ff9733","unresolved":false,"context_lines":[{"line_number":1446,"context_line":"\t\treturn -ENAMETOOLONG;"},{"line_number":1447,"context_line":"\t}"},{"line_number":1448,"context_line":"\tsnprintf(path, sizeof(path), \"%s.%d\", nvme_backing_file, vf_index);"},{"line_number":1449,"context_line":"\tnvme-\u003ebacking_fp \u003d filp_open(path, O_RDWR | O_CREAT, 0600);"},{"line_number":1450,"context_line":"\tif (IS_ERR(nvme-\u003ebacking_fp)) {"},{"line_number":1451,"context_line":"\t\terr \u003d PTR_ERR(nvme-\u003ebacking_fp);"},{"line_number":1452,"context_line":"\t\tpr_err(\"pci_sim_nvme: failed to open backing file %s: %d\\n\","}],"source_content_type":"text/x-csrc","patch_set":24,"id":"bde675f8_9f4e2385","line":1449,"updated":"2026-09-03 18:53:50.000000000","message":"pci_sim_nvme_init() opens the per-VF backing store with filp_open(path, O_RDWR | O_CREAT, 0600) and then vfs_truncate()s it to nvme_ns_size_mb, where path defaults to /tmp/pci-sim-nvme.\u003cvf_index\u003e (nvme_backing_file default \"/tmp/pci-sim-nvme\" in fake_pci_sriov_core.c). O_CREAT without O_EXCL/O_NOFOLLOW makes the open follow symlinks in the world-writable /tmp directory. Because this runs in kernel context as root (CAP_DAC_OVERRIDE), an unprivileged local user who pre-creates /tmp/pci-sim-nvme.0 as a symlink to any root-owned file causes the kernel to open that file for write and truncate it to 64 MB, destroying its contents.\n\n**Severity**: HIGH | **Confidence**: 0.8\n\n**Impact**: On any multi-user host where the module is loaded, an unprivileged user can make the kernel truncate or write zeros/patterns over an arbitrary root-owned file (data destruction / integrity loss), and can also read-modify-write the fixture\u0027s storage to influence tests.\n\n**Priority**: Before merge\n**Recommendation**:\nOpen with O_NOFOLLOW|O_EXCL (retry after unlinking an existing regular file), verify the resolved path stays under an administrator-owned directory, and change the default backing prefix to a root-owned location such as /var/lib/pci-sim/pci-sim-nvme instead of /tmp.","commit_id":"d9e746e72fe4d754603b5cc20a4b99609e981c96"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"a0f3dbcff174a9307f0fccc959174a336507ecf4","unresolved":false,"context_lines":[{"line_number":82,"context_line":"\t\treturn;"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"\t/* CQ full: tail is about to overwrite unprocessed entries */"},{"line_number":85,"context_line":"\tif (cq-\u003ecq_depth \u0026\u0026 (cq-\u003ecq_tail + 1) % cq-\u003ecq_depth \u003d\u003d cq-\u003ecq_head)"},{"line_number":86,"context_line":"\t\treturn;"},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"\tcqe \u003d (struct pci_sim_nvme_cqe *)cq-\u003ecq_base + cq-\u003ecq_tail;"}],"source_content_type":"text/x-csrc","patch_set":26,"id":"1abcb883_33ed2960","line":85,"updated":"2026-09-04 08:33:39.000000000","message":"When the guest\u0027s completion queue has no free slot, nvme_sim_post_completion() returns without writing a CQE (fake_pci_sriov_nvme.c:84-86, \u0027CQ full: tail is about to overwrite unprocessed entries\u0027). However nvme_sim_process_sq() (lines 1087-1106) advances sq_head and dispatches up to PCI_SIM_NVME_SQ_BATCH (64) commands per doorbell write regardless of CQ capacity, so every command whose completion would overflow the CQ is executed but never completed. Per NVMe semantics the controller must stop consuming SQ entries when the CQ is full and resume after the host advances the CQ head; dropping the completion leaves the guest\u0027s nvme driver waiting forever on that command_id.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Under bursty I/O or deep queue depths (e.g. fio or filesystem tests inside the guest, which the docs advertise), a dropped CQE causes the in-guest/in-host nvme driver command to time out, triggering controller reset and failed Tempest/smoke runs that are hard to reproduce.\n\n**Suggestion**:\nIn nvme_sim_process_sq(), check for a free CQE slot before consuming an SQ entry; when the CQ is full, leave sq_head un-advanced and break out of the loop so processing resumes on the next CQ-head doorbell write.","commit_id":"dd700467f638287da18ba08c9bdce22f1f0dd047"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"6d9fb80205038548d9da0966a54d9907a86e0482","unresolved":false,"context_lines":[{"line_number":274,"context_line":"\tid[77] \u003d PCI_SIM_NVME_MDTS; /* 2^MDTS * MPSMIN \u003d 128KB */"},{"line_number":275,"context_line":"\tput_unaligned_le16(nvme-\u003evf_index + 1, id + 78); /* CNTLID */"},{"line_number":276,"context_line":"\tput_unaligned_le32(0x00010400, id + 80); /* VS: NVMe 1.4 */"},{"line_number":277,"context_line":"\tput_unaligned_le16(0x0022, id + 256); /* OACS: Format + Sanitize */"},{"line_number":278,"context_line":"\tid[258] \u003d 3; /* ACL */"},{"line_number":279,"context_line":"\tid[259] \u003d 3; /* AERL */"},{"line_number":280,"context_line":"\tid[260] \u003d 0x02; /* FRMW */"}],"source_content_type":"text/x-csrc","patch_set":28,"id":"6373aac0_08e40dbd","line":277,"updated":"2026-09-07 16:57:30.000000000","message":"pci_sim_nvme_fill_identify_ctrl() writes OACS\u003d0x0022 with the comment \u0027OACS: Format + Sanitize\u0027, but per NVMe 1.4 OACS bit0 is Format NVM, bit1 is Security Send/Receive, and bit5 is Sanitize. 0x22 sets bits 1 and 5: the controller advertises Security Send/Receive (no such opcode is implemented in the admin dispatcher) while clearing Format NVM, which IS implemented (NVME_ADMIN_FORMAT_NVM handler). The correct value is 0x21.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Spec-compliant clients (nvme-cli, guest nvme drivers) gate \u0027nvme format\u0027 on OACS bit0 and will report Format as unsupported on the emulated device, while a capability bit is advertised for commands that fail with INVALID_OPCODE.\n\n**Suggestion**:\nChange the value to 0x0021 (Format | Sanitize), fix the comment, and update the test-script assertion from 0x22 to 0x21.","commit_id":"ec86791c7f606998a376188efbffaa4506ab92cf"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"6d9fb80205038548d9da0966a54d9907a86e0482","unresolved":false,"context_lines":[{"line_number":1322,"context_line":"\treturn 0;"},{"line_number":1323,"context_line":"}"},{"line_number":1324,"context_line":""},{"line_number":1325,"context_line":"static void pci_sim_nvme_vfio_close(void *state)"},{"line_number":1326,"context_line":"{"},{"line_number":1327,"context_line":"\tstruct pci_sim_nvme *nvme \u003d state;"},{"line_number":1328,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":28,"id":"c4cd65be_a350b73d","line":1325,"updated":"2026-09-07 16:57:30.000000000","message":"developer-guide.rst:1178 (VFIO NVMe guest flow, final step) states \u0027On VF close, storage is zeroed for multi-tenant data isolation\u0027, but no code path implements it. pci_sim_nvme_vfio_close() calls pci_sim_nvme_reset() and pci_sim_nvme_cleanup(); cleanup only filp_close()s the backing file. The only zeroing function, pci_sim_nvme_close() (line 1509), which zeroes the whole backing file, has zero callers anywhere in the tree. The host-driver remove path also calls cleanup, not close.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Data written by one guest persists in /tmp/pci-sim-nvme.N after the VF is closed and is served to the next VM or test that opens the VF; the documented isolation property does not hold, and the zeroing function is dead code.\n\n**Suggestion**:\nInvoke the zeroing logic (e.g. pci_sim_nvme_close()) from pci_sim_nvme_vfio_close() before cleanup, or correct the documentation if persistence across opens is intended; remove the unused function either way.","commit_id":"ec86791c7f606998a376188efbffaa4506ab92cf"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"d71464234cca034a647f629acf77559699bca9d6","unresolved":false,"context_lines":[{"line_number":1369,"context_line":"{"},{"line_number":1370,"context_line":"\tint i;"},{"line_number":1371,"context_line":""},{"line_number":1372,"context_line":"\tpci_sim_nvme_poll_stop(host);"},{"line_number":1373,"context_line":"\tfor (i \u003d 0; i \u003c host-\u003enum_vfs_enabled; i++)"},{"line_number":1374,"context_line":"\t\tpci_sim_nvme_poll_vf_cleanup(host, i);"},{"line_number":1375,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":29,"id":"e66007a9_7b0db811","line":1372,"updated":"2026-09-08 10:47:11.000000000","message":"Per-VF teardown (pci_sim_nvme_poll_vf_cleanup: filp_close of the backing file, pci_dev_put of the resolved VF pdev) is bounded by host-\u003enum_vfs_enabled in both pci_sim_nvme_host_fini and sriov_disable. On the PF-removal/rmmod path, fake_pci_pf_remove() runs during pci_remove_root_bus() and calls handle_sriov_numvfs_write(host, 0), setting num_vfs_enabled to 0 before fake_pci_host_remove() invokes host_fini, whose loop then iterates zero times. VFs still enabled at teardown therefore leak one open backing file (struct file plus the 64 MB truncated file) and one pdev reference each until reboot. The normal \u0027echo 0 \u003e sriov_numvfs\u0027 path is unaffected because sriov_disable runs before num_vfs_enabled is cleared.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Leaked struct file references and truncated backing files per VF on every memmap-mode session ended by rmmod or PF removal with VFs enabled; files stay open/leaked until reboot. Bounded resource leak, no data corruption.\n\n**Suggestion**:\nIn pci_sim_nvme_host_fini (and sriov_disable), iterate over MAX_VFS and clean up any nvme_state[i] that still has a backing_fp or pdev (pci_sim_nvme_poll_vf_cleanup already tolerates empty slots), or cache the initialized VF count in the NVMe state rather than reading num_vfs_enabled after it has been reset.","commit_id":"dff1cc943141d7f15518107f29e958bd829edfd9"}],"pci-sim/fake_pci_sriov_nvme_host.c":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"4a23e7d6624ff387761c870820cd7b4061ece3b9","unresolved":false,"context_lines":[{"line_number":359,"context_line":"\tpci_set_drvdata(pdev, dev);"},{"line_number":360,"context_line":""},{"line_number":361,"context_line":"\tdev-\u003echrdev \u003d"},{"line_number":362,"context_line":"\t\tdevice_create(pci_sim_nvme_host_class, \u0026pdev-\u003edev,"},{"line_number":363,"context_line":"\t\t\t      MKDEV(MAJOR(pci_sim_nvme_host_devt), dev-\u003eid),"},{"line_number":364,"context_line":"\t\t\t      dev, \"nvme%d\", dev-\u003eid);"},{"line_number":365,"context_line":"\tif (IS_ERR(dev-\u003echrdev)) {"}],"source_content_type":"text/x-csrc","patch_set":6,"id":"28ebf0a3_6bf5d332","line":362,"updated":"2026-08-11 18:09:20.000000000","message":"The NVMe host driver creates character devices named \"nvme%d\" via device_create (line 363), producing device nodes like /dev/nvme0. However, the accompanying test script test_pci_sim_nvme_host.sh consistently references /dev/pci_sim_nvme0 through /dev/pci_sim_nvmeN (21 occurrences). Every test as...\n\n**Severity**: CRITICAL | **Confidence**: 1.0\n\n**Risk**: The Phase 1 test suite will report failures for all char-device existence checks and all nvme-cli operations. The test cannot pass as written. Additionally, creating /dev/nvme0 via a test fixture risks confusing nvme-cli and udev on systems with real NVMe devices, since the naming collides with t...\n\n**Priority**: Immediate\n**Why This Matters**: The Phase 1 test suite will report failures for all char-device existence checks and all nvme-cli operations. The test cannot pass as written. Additionally, creating /dev/nvme0 via a test fixture risks confusing nvme-cli and udev on systems with real NVMe devices, since the naming collides with t...\n\n**Recommendation**:\nEither change device_create to use \"pci_sim_nvme%d\" so the device node matches the test script, or update the test script to reference /dev/nvme%d. Using \"pci_sim_nvme%d\" is safer because it avoids collisions with real /dev/nvmeN devices from the stock nvme driver.","commit_id":"b751927859bfe9d6bee3a5d261abbfa308e69f07"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"3cc84dd82326911723c19f8732a75232bf07ae20","unresolved":false,"context_lines":[{"line_number":437,"context_line":"\t  .class \u003d FAKE_PCI_NVME_CLASS,"},{"line_number":438,"context_line":"\t  .class_mask \u003d 0xFFFFFF },"},{"line_number":439,"context_line":"\t{}"},{"line_number":440,"context_line":"};"},{"line_number":441,"context_line":""},{"line_number":442,"context_line":"struct pci_driver pci_sim_nvme_host_driver \u003d {"},{"line_number":443,"context_line":"\t.name \u003d \"pci_sim_nvme_host\","}],"source_content_type":"text/x-csrc","patch_set":9,"id":"bfe3a725_432560b4","line":440,"updated":"2026-08-13 07:46:04.000000000","message":"The pci_sim_nvme_host_driver PCI driver ID table is not exported with MODULE_DEVICE_TABLE, unlike sibling PCI drivers in the same module.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Auto-loading via modprobe aliases will not work for NVMe-class VF devices. Module auto-loading is expected for production/devstack use.\n\n**Suggestion**:\nAdd MODULE_DEVICE_TABLE(pci, pci_sim_nvme_host_ids) after the pci_sim_nvme_host_ids definition at line 440.","commit_id":"91dee44dd0069b60f7d3833de32ccce976efb9dc"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"f8e0ed2121cb6bcf3429c51a9e23c187f2662231","unresolved":false,"context_lines":[{"line_number":359,"context_line":"\tpci_set_drvdata(pdev, dev);"},{"line_number":360,"context_line":""},{"line_number":361,"context_line":"\tdev-\u003echrdev \u003d"},{"line_number":362,"context_line":"\t\tdevice_create(pci_sim_nvme_host_class, \u0026pdev-\u003edev,"},{"line_number":363,"context_line":"\t\t\t      MKDEV(MAJOR(pci_sim_nvme_host_devt), dev-\u003eid),"},{"line_number":364,"context_line":"\t\t\t      dev, \"nvme%d\", dev-\u003eid);"},{"line_number":365,"context_line":"\tif (IS_ERR(dev-\u003echrdev)) {"}],"source_content_type":"text/x-csrc","patch_set":10,"id":"02e090fe_744d3232","line":362,"updated":"2026-08-13 16:20:37.000000000","message":"The device_create call in the host NVMe driver creates character devices named \"nvme%d\", producing /dev/nvme0, /dev/nvme1, etc. However, the test script test_pci_sim_nvme_host.sh checks for /dev/pci_sim_nvme0, /dev/pci_sim_nvme1 (lines 89, 104, 128, 137, 144, 169, 188, 210, 292). These will never...\n\n**Severity**: HIGH | **Confidence**: 1.0\n\n**Risk**: Every Phase 1 test assertion in test_pci_sim_nvme_host.sh that checks for /dev/pci_sim_nvmeN will fail. Additionally, creating /dev/nvme0 risks collision with real NVMe block devices on the host, which is dangerous for a test fixture.\n\n**Priority**: Before merge\n**Why This Matters**: Every Phase 1 test assertion in test_pci_sim_nvme_host.sh that checks for /dev/pci_sim_nvmeN will fail. Additionally, creating /dev/nvme0 risks collision with real NVMe block devices on the host, which is dangerous for a test fixture.\n\n**Recommendation**:\nChange the device_create format string from \"nvme%d\" to \"pci_sim_nvme%d\" so the device nodes are /dev/pci_sim_nvmeN, matching the test expectations and avoiding collision with real NVMe devices.","commit_id":"85c5e1594db0d8475029a94c8301ded3c6fac562"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"d3677ade691b88d8973ba4ab2f10aaa5218e7241","unresolved":false,"context_lines":[{"line_number":359,"context_line":"\tpci_set_drvdata(pdev, dev);"},{"line_number":360,"context_line":""},{"line_number":361,"context_line":"\tdev-\u003echrdev \u003d"},{"line_number":362,"context_line":"\t\tdevice_create(pci_sim_nvme_host_class, \u0026pdev-\u003edev,"},{"line_number":363,"context_line":"\t\t\t      MKDEV(MAJOR(pci_sim_nvme_host_devt), dev-\u003eid),"},{"line_number":364,"context_line":"\t\t\t      dev, \"nvme%d\", dev-\u003eid);"},{"line_number":365,"context_line":"\tif (IS_ERR(dev-\u003echrdev)) {"}],"source_content_type":"text/x-csrc","patch_set":12,"id":"848ab75d_be178560","line":362,"updated":"2026-08-15 18:21:04.000000000","message":"The commit message claims \u0027Host char device (/dev/nvmeN) ... for nvme-cli admin passthrough\u0027, but the registered chrdev region name and device_create() format produce /dev/pci_sim_nvmeN, and only Phase 2 (memmap) yields /dev/nvmeN.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Contributors following the commit message or docs will look for /dev/nvme0 and conclude the feature failed, when the actual node is /dev/pci_sim_nvme0; the sysfs symlink is also pci_sim_nvme/nvmeN rather than the real nvme/nvmeN glue-dir name.\n\n**Suggestion**:\nReword the commit-message bullet and the doc narrative to state that the host driver creates /dev/pci_sim_nvmeN with an \u003cpci_addr\u003e/nvme compat symlink, reserving /dev/nvmeN for the Phase 2 memmap mode.","commit_id":"eb2ac338ef251974ab6df241a90c304c223124ae"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"0f6e632238b0b5012d7e343ad6430918c8ed6ae5","unresolved":false,"context_lines":[{"line_number":358,"context_line":""},{"line_number":359,"context_line":"\tpci_set_drvdata(pdev, dev);"},{"line_number":360,"context_line":""},{"line_number":361,"context_line":"\tdev-\u003echrdev \u003d"},{"line_number":362,"context_line":"\t\tdevice_create(pci_sim_nvme_host_class, \u0026pdev-\u003edev,"},{"line_number":363,"context_line":"\t\t\t      MKDEV(MAJOR(pci_sim_nvme_host_devt), dev-\u003eid),"},{"line_number":364,"context_line":"\t\t\t      dev, \"nvme%d\", dev-\u003eid);"}],"source_content_type":"text/x-csrc","patch_set":14,"id":"065d1df1_21eb034d","line":361,"updated":"2026-08-18 08:07:55.000000000","message":"pci_sim_nvme_host_probe() calls device_create(..., \"nvme%d\", dev-\u003eid) so the character devices appear as /dev/nvme0, /dev/nvme1 (matching the commit message). However the shipped smoke test checks [ -c /dev/pci_sim_nvme$i ] and runs every nvme-cli command against /dev/pci_sim_nvme0 (test_pci_sim_nvme_host.sh lines 87-169), and developer-guide.rst (lines 118, 190, 203, 271, 286, 910) documents the node as /dev/pci_sim_nvmeN. The paths the change itself ships cannot exist, so every Phase 1 check fails from the first assertion. Naming the fake device nvme%d also collides with real NVMe controller char devices on hosts that have one: devtmpfs gets a duplicate node name for a different major, and nvme-cli / tests may open the real controller instead of the fixture.\n\n**Severity**: HIGH | **Confidence**: 0.9\n\n**Impact**: test_pci_sim_nvme_host.sh Phase 1 fails at the first device-node assertion, so the change\u0027s own verification cannot pass; users following developer-guide.rst get \u0027No such file\u0027 from nvme-cli; on machines with real NVMe hardware the nvme%d name can shadow or collide with real /dev/nvmeN nodes.\n\n**Priority**: Before merge\n**Recommendation**:\nPick one name and align all three artifacts. Prefer renaming the node to \"pci_sim_nvme%d\" in device_create (the test, README and developer-guide already use it, and it avoids collisions with the real nvme driver\u0027s /dev/nvmeN); alternatively fix the test and both docs. The sysfs \u0027nvme\u0027 compat symlink logic is unaffected because it links the class glue directory, not the node name.","commit_id":"d5c6e164d1ef30afc7d4a96e3dbd1adf9dc79fe4"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"060042c30ba61f1ac162de1c49ef7bf81521b6c0","unresolved":false,"context_lines":[{"line_number":358,"context_line":""},{"line_number":359,"context_line":"\tpci_set_drvdata(pdev, dev);"},{"line_number":360,"context_line":""},{"line_number":361,"context_line":"\tdev-\u003echrdev \u003d"},{"line_number":362,"context_line":"\t\tdevice_create(pci_sim_nvme_host_class, \u0026pdev-\u003edev,"},{"line_number":363,"context_line":"\t\t\t      MKDEV(MAJOR(pci_sim_nvme_host_devt), dev-\u003eid),"},{"line_number":364,"context_line":"\t\t\t      dev, \"nvme%d\", dev-\u003eid);"}],"source_content_type":"text/x-csrc","patch_set":15,"id":"52a17762_69f40a77","line":361,"updated":"2026-08-21 13:28:38.000000000","message":"pci_sim_nvme_host_probe() calls device_create(..., \"nvme%d\", dev-\u003eid), so the Phase-1 host character devices appear as /dev/nvme0, /dev/nvme1, ... However both the documentation and the shipped smoke test consistently expect /dev/pci_sim_nvmeN: testing.rst (\u0027Phase 1 (char device /dev/pci_sim_nvmeN)\u0027), developer-guide.rst (\u0027/dev/pci_sim_nvmeN char device\u0027, \u0027/dev/pci_sim_nvme\u003cN\u003e character devices appear\u0027), README.rst, and test_pci_sim_nvme_host.sh, which checks \u0027[ -c /dev/pci_sim_nvme$i ]\u0027 and runs \u0027nvme id-ctrl /dev/pci_sim_nvme0\u0027. Only the commit message says /dev/nvmeN. Beyond the test failing deterministically, taking the \u0027nvme%d\u0027 name from an uncoordinated private IDA collides with the kernel nvme driver\u0027s device namespace: on hosts that already have a real (or Phase-2 stock-nvme) controller named nvme0, the devtmpfs node name conflicts, the simulated node may never appear, and nvme-cli admin passthrough aimed at /dev/nvme0 would silently target the real controller.\n\n**Severity**: HIGH | **Confidence**: 0.85\n\n**Impact**: test_pci_sim_nvme_host.sh Phase 1 fails deterministically (every char-device existence check and nvme-cli call targets a nonexistent node), so the shipped validation of the new driver cannot pass. On machines with existing NVMe controllers (common on bare-metal CI), the uncoordinated nvme%d naming conflicts with real device nodes and can misdirect nvme-cli admin commands such as format/sanitize to a physical controller.\n\n**Priority**: Before merge\n**Recommendation**:\nName the Phase-1 device unambiguously, e.g. device_create(pci_sim_nvme_host_class, \u0026pdev-\u003edev, devt, dev, \"pci_sim_nvme%d\", dev-\u003eid), matching the docs, README, and test script. Keep /dev/nvmeN exclusively for the stock nvme driver (Phase 2). If /dev/nvmeN is truly intended, instead update the docs and test script and derive the instance number without colliding with existing nvme controllers.","commit_id":"e75bcc46da049aeaab64e70f7d07d3fe48d90140"}],"pci-sim/fake_pci_sriov_nvme_poll.c":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"638387b1b971bdf446b014c95604970d6f433843","unresolved":false,"context_lines":[{"line_number":80,"context_line":" * \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":81,"context_line":" */"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"static void poll_reinit_bar0(struct fake_pci_host *host, int vf_idx)"},{"line_number":84,"context_line":"{"},{"line_number":85,"context_line":"\tvoid __iomem *bar \u003d vf_bar0(host, vf_idx);"},{"line_number":86,"context_line":"\tu64 cap \u003d (u64)PCI_SIM_NVME_MQES | (1ULL \u003c\u003c 16) | (1ULL \u003c\u003c 24);"}],"source_content_type":"text/x-csrc","patch_set":11,"id":"936ce8f9_ecec3a4e","line":83,"updated":"2026-08-14 17:39:44.000000000","message":"poll_reinit_bar0() calls memset_io(bar + NVME_REG_AQA, ...) and writel() on the pointer returned by vf_bar0() without checking for NULL, unlike poll_check_regs() and poll_check_doorbells() which both guard with \"if (!bar) return;\".\n\n**Severity**: HIGH | **Confidence**: 0.8\n\n**Risk**: A NULL-pointer MMIO write in kernel context (oops) whenever the SR-IOV VF BAR configuration and the mem_resource window disagree (e.g., mis-set nvme_memmap_start/size or a VF BAR programmed outside the window), reachable from a guest or test-triggered controller disable.\n\n**Priority**: Before merge\n**Why This Matters**: A NULL-pointer MMIO write in kernel context (oops) whenever the SR-IOV VF BAR configuration and the mem_resource window disagree (e.g., mis-set nvme_memmap_start/size or a VF BAR programmed outside the window), reachable from a guest or test-triggered controller disable.\n\n**Recommendation**:\nAdd the same \"if (!bar) return;\" guard at the top of poll_reinit_bar0(), matching its two sibling functions in the same file.","commit_id":"5e0f10479483b1d53407eacd8b81fce64a4ce13e"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"d3677ade691b88d8973ba4ab2f10aaa5218e7241","unresolved":false,"context_lines":[{"line_number":82,"context_line":""},{"line_number":83,"context_line":"static void poll_reinit_bar0(struct fake_pci_host *host, int vf_idx)"},{"line_number":84,"context_line":"{"},{"line_number":85,"context_line":"\tvoid __iomem *bar \u003d vf_bar0(host, vf_idx);"},{"line_number":86,"context_line":"\tu64 cap \u003d (u64)PCI_SIM_NVME_MQES | (1ULL \u003c\u003c 16) | (1ULL \u003c\u003c 24);"},{"line_number":87,"context_line":"\tu32 vs \u003d 0x00010400;"},{"line_number":88,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":12,"id":"1d98614d_9c7065e5","line":85,"updated":"2026-08-15 18:21:04.000000000","message":"poll_reinit_bar0() and preinit_bar0_regs() dereference the iomem pointer from vf_bar0() without validating it, unlike poll_check_regs()/poll_check_doorbells() which do check.\n\n**Severity**: HIGH | **Confidence**: 0.9\n\n**Risk**: A mis-sized nvme_memmap_start/nvme_memmap_size module parameter combination turns every controller disable/re-enable and every sriov_enable into an oops on the host running the simulation, taking down the CI node instead of failing gracefully.\n\n**Priority**: Before merge\n**Why This Matters**: A mis-sized nvme_memmap_start/nvme_memmap_size module parameter combination turns every controller disable/re-enable and every sriov_enable into an oops on the host running the simulation, taking down the CI node instead of failing gracefully.\n\n**Recommendation**:\nCheck the vf_bar0() return value (or the offset bound) in poll_reinit_bar0() and preinit_bar0_regs() and skip/log, matching the pattern already used in poll_check_regs()/poll_check_doorbells().","commit_id":"eb2ac338ef251974ab6df241a90c304c223124ae"}],"pci-sim/test_pci_sim_nvme_host.sh":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"198d83783d31f82835cc5deb92eccf9f47a508c8","unresolved":false,"context_lines":[{"line_number":86,"context_line":""},{"line_number":87,"context_line":"# Check char devices exist"},{"line_number":88,"context_line":"for i in $(seq 0 $((NUM_VFS - 1))); do"},{"line_number":89,"context_line":"    if [ -c \"/dev/pci_sim_nvme$i\" ]; then"},{"line_number":90,"context_line":"        pass \"/dev/pci_sim_nvme$i exists\""},{"line_number":91,"context_line":"    else"},{"line_number":92,"context_line":"        fail \"/dev/pci_sim_nvme$i missing\""}],"source_content_type":"text/x-sh","patch_set":3,"id":"419034fa_0e448cbf","line":89,"updated":"2026-08-07 18:07:47.000000000","message":"The kernel module creates character devices named \u0027nvme%d\u0027 via device_create (line 364), producing /dev/nvme0. However, test_pci_sim_nvme_host.sh checks for /dev/pci_sim_nvme0 at lines 89, 104, 128, 137, 144, 169, 188, and globs /dev/pci_sim_nvme* at lines 210, 292. Every Phase 1 device existence...\n\n**Severity**: HIGH | **Confidence**: 0.9\n\n**Risk**: All Phase 1 character device tests will fail when run. The test suite is the primary validation for the NVMe host driver functionality and would report false failures.\n\n**Priority**: Before merge\n**Why This Matters**: All Phase 1 character device tests will fail when run. The test suite is the primary validation for the NVMe host driver functionality and would report false failures.\n\n**Recommendation**:\nUpdate the test script to reference /dev/nvme* (matching the kernel), or change device_create to use \u0027pci_sim_nvme%d\u0027 to avoid conflicts with real NVMe devices and match the test expectations.","commit_id":"f3159e05b31f758c11457a19a686cf50759643e0"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"26d8237f5d381bcc64f3e965034465869e1bc1d8","unresolved":false,"context_lines":[{"line_number":86,"context_line":""},{"line_number":87,"context_line":"# Check char devices exist"},{"line_number":88,"context_line":"for i in $(seq 0 $((NUM_VFS - 1))); do"},{"line_number":89,"context_line":"    if [ -c \"/dev/pci_sim_nvme$i\" ]; then"},{"line_number":90,"context_line":"        pass \"/dev/pci_sim_nvme$i exists\""},{"line_number":91,"context_line":"    else"},{"line_number":92,"context_line":"        fail \"/dev/pci_sim_nvme$i missing\""}],"source_content_type":"text/x-sh","patch_set":5,"id":"15713db5_3f5df42e","line":89,"updated":"2026-08-11 11:04:26.000000000","message":"The NVMe host driver creates character devices named \u0027nvme%d\u0027 via device_create (e.g., /dev/nvme0, /dev/nvme1). However, the test script test_pci_sim_nvme_host.sh checks for /dev/pci_sim_nvme0 and passes /dev/pci_sim_nvme0 to nvme-cli commands. These paths do not match, causing test assertions to...\n\n**Severity**: HIGH | **Confidence**: 0.9\n\n**Risk**: All Phase 1 test assertions that check for device existence or invoke nvme-cli will fail because /dev/pci_sim_nvmeN does not exist. The test reports FAIL for char device existence, nvme id-ctrl, nvme id-ns, write-zeroes, sanitize, and rebind tests. This makes the test suite non-functional.\n\n**Priority**: Before merge\n**Why This Matters**: All Phase 1 test assertions that check for device existence or invoke nvme-cli will fail because /dev/pci_sim_nvmeN does not exist. The test reports FAIL for char device existence, nvme id-ctrl, nvme id-ns, write-zeroes, sanitize, and rebind tests. This makes the test suite non-functional.\n\n**Recommendation**:\nReplace all occurrences of /dev/pci_sim_nvme with /dev/nvme in test_pci_sim_nvme_host.sh. For example, line 89 should check `[ -c \"/dev/nvme$i\" ]` and line 104 should use `nvme id-ctrl /dev/nvme0`. Consider also handling potential name collisions with real NVMe devices on hosts that have them.","commit_id":"48f7f9c8c2c7170a080284d9d2bb1d2d8941464b"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"3cc84dd82326911723c19f8732a75232bf07ae20","unresolved":false,"context_lines":[{"line_number":86,"context_line":""},{"line_number":87,"context_line":"# Check char devices exist"},{"line_number":88,"context_line":"for i in $(seq 0 $((NUM_VFS - 1))); do"},{"line_number":89,"context_line":"    if [ -c \"/dev/pci_sim_nvme$i\" ]; then"},{"line_number":90,"context_line":"        pass \"/dev/pci_sim_nvme$i exists\""},{"line_number":91,"context_line":"    else"},{"line_number":92,"context_line":"        fail \"/dev/pci_sim_nvme$i missing\""}],"source_content_type":"text/x-sh","patch_set":9,"id":"c2211502_3abbc4fe","line":89,"updated":"2026-08-13 07:46:04.000000000","message":"The smoke test script references /dev/pci_sim_nvme$i for char device existence checks and nvme-cli invocations, but device_create() in the host driver creates /dev/nvme%d. The test will fail every device existence and nvme-cli check in Phase 1.\n\n**Severity**: HIGH | **Confidence**: 0.9\n\n**Risk**: The Phase 1 smoke test (NVMe host char device) will always fail: device existence checks fail because /dev/pci_sim_nvmeN does not exist, and nvme-cli commands target the wrong device path.\n\n**Priority**: Before merge\n**Why This Matters**: The Phase 1 smoke test (NVMe host char device) will always fail: device existence checks fail because /dev/pci_sim_nvmeN does not exist, and nvme-cli commands target the wrong device path.\n\n**Recommendation**:\nEither change the test script to check /dev/nvmeN, or change device_create() to use \"pci_sim_nvme%d\" as the device name. The driver comment at line 5 says \u0027/dev/nvmeN\u0027 so the test is likely wrong. Update all /dev/pci_sim_nvme references to /dev/nvme in the test script.","commit_id":"91dee44dd0069b60f7d3833de32ccce976efb9dc"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"d71464234cca034a647f629acf77559699bca9d6","unresolved":false,"context_lines":[{"line_number":101,"context_line":"fi"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"echo \"--- Testing nvme id-ctrl ---\""},{"line_number":104,"context_line":"id_out\u003d$(nvme id-ctrl /dev/nvme0 2\u003e\u00261)"},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"vid\u003d$(echo \"$id_out\" | grep \u0027^vid\u0027 | awk \u0027{print $3}\u0027)"},{"line_number":107,"context_line":"if [ \"$vid\" \u003d \"0x1d55\" ]; then"}],"source_content_type":"text/x-sh","patch_set":29,"id":"882efcdd_bd30e629","line":104,"updated":"2026-09-08 10:47:11.000000000","message":"The new smoke test validates that /dev/nvme0 identifies as the fake device (vid 0x1d55), but a mismatch only calls fail(), which increments a counter and continues. The script then runs \u0027nvme write-zeroes /dev/nvme0\u0027 and \u0027nvme sanitize /dev/nvme0 -a 2\u0027 (block erase). The fake char device is created as nvme0 (first ida id \u003d 0), so on any host that already has a real NVMe controller as /dev/nvme0 (e.g. an NVMe boot disk, very common on build/CI hosts), id-ctrl succeeds against the real disk, the vid check fails non-fatally, and the script write-zeroes LBA 0 and block-erases the real, possibly boot, disk.\n\n**Severity**: HIGH | **Confidence**: 0.75\n\n**Impact**: Irreversible data loss (write-zeroes on LBA 0 and sanitize block erase) on a real NVMe disk when the documented root-run test is executed on a host with a real NVMe controller, because the script never aborts on identity mismatch.\n\n**Priority**: Before merge\n**Recommendation**:\nAbort (exit 1) when the id-ctrl vendor id is not 0x1d55, and/or resolve the target device via the fake VF\u0027s sysfs path (e.g. /sys/bus/pci/devices/0001:00:00.1/pci_sim_nvme/nvme*/dev or the device\u0027s PCI address via nvme-cli) instead of the hardcoded /dev/nvme0 name before any destructive command.","commit_id":"dff1cc943141d7f15518107f29e958bd829edfd9"}]}