)]}'
{"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"}],"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"}],"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"}],"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"}],"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"}],"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"}],"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"}]}