)]}'
{"/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":"67d40fba7ef6abe8ffbc6ca5d1747fc0c55fabd3","unresolved":false,"context_lines":[{"line_number":1,"context_line":"Parent:     346c240b (pci-sim: add NVMe host kernel module)"},{"line_number":2,"context_line":"Author:     Chandan Kumar (raukadah) \u003cchkumar@redhat.com\u003e"},{"line_number":3,"context_line":"AuthorDate: 2026-08-06 10:46:37 +0530"},{"line_number":4,"context_line":"Commit:     Chandan \u003cchkumar@redhat.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":34,"id":"cf474260_871f14d8","line":1,"updated":"2026-09-09 07:18:34.000000000","message":"The commit message states the fsuid/fsgid elevation is needed \u0027since QEMU runs as a non-root user that cannot access the 0600 backing file\u0027, but the harness added by this same change launches QEMU through sudo (launch_qemu() builds a command starting with \u0027sudo\u0027, \u0027-n\u0027), so QEMU runs as root and the elevation is a no-op in every shipped path. The in-code comment contradicts the message: \u0027The shipped test harness runs QEMU as root, so this is a no-op there.\u0027\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: The permanent history gives an incorrect account of why a security-sensitive pattern (kernel root fsuid override) exists, misleading future readers auditing the module and overstating the tested coverage of the elevation path.\n\n**Suggestion**:\nAmend the message to state that the shipped harness runs QEMU as root via sudo and that the elevation is a defensive measure for unprivileged deployments, matching the in-code comment.","commit_id":"38d27c8b1a85aca071f83f12e33978cfff36c63a"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":12393,"name":"chandan kumar","display_name":"Chandan Kumar","email":"chkumar@redhat.com","username":"chkumar246"},"change_message_id":"c7f0673a61c8e3f5d166025e493eaa3e2467fc02","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":15,"id":"a9cbee29_86150f48","updated":"2026-08-17 15:50:57.000000000","message":"recheck","commit_id":"04b150486200f659f36979d03e8317c726e2cfea"},{"author":{"_account_id":12393,"name":"chandan kumar","display_name":"Chandan Kumar","email":"chkumar@redhat.com","username":"chkumar246"},"change_message_id":"c643fa211df6792a16b007ebe9ae97e2adae0d01","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":29,"id":"5f73fb7c_ba97158c","updated":"2026-09-07 05:35:57.000000000","message":"recheck","commit_id":"4c950d32202978c9cf1c8be730eed34fef371ec5"}],"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":"de9a0a9d3eae74d60f1888fbde61bf5b3bb945ec","unresolved":false,"context_lines":[{"line_number":1201,"context_line":"   $ echo $VF | sudo tee /sys/bus/pci/drivers_probe"},{"line_number":1202,"context_line":"   # VF reprobe lands on nvme automatically (no driver_override set)"},{"line_number":1203,"context_line":""},{"line_number":1204,"context_line":"The handoff is also automated in ``run_nvme_vfio_guest_probe.sh`` and in"},{"line_number":1205,"context_line":"the Phase 2 rebind section of ``test_pci_sim_nvme_host.sh``."},{"line_number":1206,"context_line":""},{"line_number":1207,"context_line":""}],"source_content_type":"text/x-rst","patch_set":25,"id":"3ef16eeb_5b1039cd","line":1204,"updated":"2026-09-01 12:18:47.000000000","message":"The new handoff section says the handoff \u0027is also automated ... in the Phase 2 rebind section of test_pci_sim_nvme_host.sh\u0027. In that script, the driver rebind exercise is the \u0027\u003d\u003d\u003d Driver rebind test \u003d\u003d\u003d\u0027 block at lines 151-191, inside Phase 1; \u0027Phase 2: Stock nvme driver with BAR0 memory\u0027 (line 218) is a different scenario that reloads the module for memmap-backed stock nvme probing and contains no VFIO rebind steps.\n\n**Severity**: SUGGESTION | **Confidence**: 0.9\n\n**Impact**: Contributors looking for the automated rebind coverage are sent to a section that tests something else, costing time and making the new handoff appear less covered than it is.\n\n**Recommendation**:\nReword to \u0027... and in the Driver rebind test section of test_pci_sim_nvme_host.sh\u0027 (or link to the Phase 1 rebind block explicitly).","commit_id":"5f1c29e27702391d91288d1cd7373069b0de45aa"},{"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":"aa229b665ee2467992b33358dcbd23ce32c5f53f","unresolved":false,"context_lines":[{"line_number":1177,"context_line":"#. The VFIO driver traps BAR0 writes and dispatches to the NVMe emulator."},{"line_number":1178,"context_line":"#. On VF close, storage is zeroed for multi-tenant data isolation."},{"line_number":1179,"context_line":""},{"line_number":1180,"context_line":"NVMe host → VFIO handoff"},{"line_number":1181,"context_line":"-------------------------"},{"line_number":1182,"context_line":""},{"line_number":1183,"context_line":"Only one VF at a time may be handed from the host ``nvme`` driver to VFIO"}],"source_content_type":"text/x-rst","patch_set":28,"id":"18be6aa2_f31e03b9","line":1180,"updated":"2026-09-04 08:48:55.000000000","message":"The developer guide states \u0027On VF close, storage is zeroed for multi-tenant data isolation\u0027 immediately above the handoff section added by this change, and the new test_nvme_data_persistence.sh asserts the opposite: guest-written data must survive VFIO close and be readable on the host after rebind. The implementation confirms the test is right and the doc bullet is stale: pci_sim_nvme_vfio_close() calls pci_sim_nvme_cleanup(), which only closes the backing file and never calls nvme_sim_file_zero(), so data persists. The change adds a test that codifies persistence behavior while leaving the adjacent isolation claim that directly contradicts it.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Contributors reading the guide will assume VF close wipes tenant data for isolation, while the shipped emulator and the new test prove data persists across guest teardown. If real multi-tenant flows are later modeled on this sim, the documented (absent) zeroing guarantee is the unsafe assumption; at minimum the permanent docs are now self-contradictory.\n\n**Suggestion**:\nUpdate the lifecycle bullet in developer-guide.rst to match the actual behavior, e.g. \u0027On VF close the backing file is closed; data persists across VF close (see test_nvme_data_persistence.sh). Storage is only zeroed by Format/Sanitize or pci_sim_nvme_close() on the host path\u0027, or implement zeroing in vfio_close if isolation is intended (and then adjust the persistence test).","commit_id":"05d34c1a015ec50d3968251583af30678ba95bda"},{"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":"c952b33b3e437c123e97566cf66dafb452a3832e","unresolved":false,"context_lines":[{"line_number":1201,"context_line":"   $ echo $VF | sudo tee /sys/bus/pci/drivers_probe"},{"line_number":1202,"context_line":"   # VF reprobe lands on nvme automatically (no driver_override set)"},{"line_number":1203,"context_line":""},{"line_number":1204,"context_line":"The handoff is also automated in ``run_nvme_vfio_guest_probe.sh`` and in"},{"line_number":1205,"context_line":"the Phase 2 rebind section of ``test_pci_sim_nvme_host.sh``."},{"line_number":1206,"context_line":""},{"line_number":1207,"context_line":""}],"source_content_type":"text/x-rst","patch_set":29,"id":"39524b92_0e08bcee","line":1204,"updated":"2026-09-07 06:16:44.000000000","message":"The new developer-guide paragraph states the handoff is automated \u0027in the Phase 2 rebind section of test_pci_sim_nvme_host.sh\u0027. In that script the \u0027Driver rebind test\u0027 starts at line 151, which is before the \u0027Phase 2: Stock nvme driver with BAR0 memory\u0027 header at line 218; the rebind sequence belongs to the Phase 1 (NVMe host char device) section. A contributor following the pointer will land in the wrong phase when trying to find the automated handoff example.\n\n**Severity**: SUGGESTION | **Confidence**: 0.9\n\n**Impact**: Small but concrete navigation error in contributor documentation for the exact workflow this change documents.\n\n**Recommendation**:\nReword to reference the \u0027Driver rebind test\u0027 section (in the Phase 1 run of test_pci_sim_nvme_host.sh) by name rather than by phase number, or reference test_nvme_data_persistence.sh Phase 2, which is the new script that actually automates the pre-armed handoff.","commit_id":"4c950d32202978c9cf1c8be730eed34fef371ec5"},{"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":"3b8a116280ba126c28b27b8833e6f9c92b103176","unresolved":false,"context_lines":[{"line_number":1202,"context_line":"   # VF reprobe lands on nvme automatically (no driver_override set)"},{"line_number":1203,"context_line":""},{"line_number":1204,"context_line":"The handoff is also automated in ``run_nvme_vfio_guest_probe.sh`` and in"},{"line_number":1205,"context_line":"the Phase 2 rebind section of ``test_pci_sim_nvme_host.sh``."},{"line_number":1206,"context_line":""},{"line_number":1207,"context_line":""},{"line_number":1208,"context_line":"Kernel references and design influences"}],"source_content_type":"text/x-rst","patch_set":29,"id":"703d9fad_1a06f3e7","line":1205,"updated":"2026-09-05 06:10:28.000000000","message":"The new \u0027NVMe host -\u003e VFIO handoff\u0027 section says the handoff is automated \u0027in the Phase 2 rebind section of test_pci_sim_nvme_host.sh\u0027. In that script the \u0027Driver rebind test\u0027 block (host-\u003eVFIO and VFIO-\u003ehost rebind via driver_override) appears before the \u0027\u003d\u003d\u003d Phase 2: Stock nvme driver with BAR0 memory \u003d\u003d\u003d\u0027 header, i.e. it is part of Phase 1.\n\n**Severity**: SUGGESTION | **Confidence**: 0.85\n\n**Impact**: Contributors following the pointer look in the wrong phase and may conclude the automation is missing. Minor factual error in newly added docs with a one-line fix.\n\n**Recommendation**:\nReword to \u0027the driver rebind test in Phase 1 of test_pci_sim_nvme_host.sh\u0027 (or cite the exact \u0027Driver rebind test\u0027 heading).","commit_id":"4c950d32202978c9cf1c8be730eed34fef371ec5"},{"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":"f76268230489bc89cd8318cce8e7e4930e747db6","unresolved":false,"context_lines":[{"line_number":1177,"context_line":"#. The VFIO driver traps BAR0 writes and dispatches to the NVMe emulator."},{"line_number":1178,"context_line":"#. On VF close, storage is zeroed for multi-tenant data isolation."},{"line_number":1179,"context_line":""},{"line_number":1180,"context_line":"NVMe host → VFIO handoff"},{"line_number":1181,"context_line":"-------------------------"},{"line_number":1182,"context_line":""},{"line_number":1183,"context_line":"Only one VF at a time may be handed from the host ``nvme`` driver to VFIO"}],"source_content_type":"text/x-rst","patch_set":30,"id":"65c51580_1d3e3088","line":1180,"updated":"2026-09-07 17:09:03.000000000","message":"The developer guide states \u0027On VF close, storage is zeroed for multi-tenant data isolation\u0027 (developer-guide.rst:1178), but this change adds a host-to-VFIO handoff flow and test_nvme_data_persistence.sh that require guest data to survive VF close and be read back on the host after the guest is destroyed. The NVMe vfio_close path (pci_sim_nvme_vfio_close -\u003e pci_sim_nvme_cleanup) only closes the backing file without zeroing it, so the new behavior works, but the guide now contains two contradictory claims about guest data lifecycle.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Contributors reading the guide receive contradictory guidance about whether guest data survives passthrough, making the multi-tenant isolation expectation unclear and the doc unreliable for the exact scenario the new tests exercise.\n\n**Suggestion**:\nReconcile the two sections: state explicitly in the handoff section that the backing file is not wiped on VFIO close in this flow, and either remove/correct line 1178 or move the wipe guarantee to where it actually occurs (e.g. VF removal or personality reset).","commit_id":"a7a4e67b38629534e32e9e2400515b19f1d6d3cd"},{"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":"a050254eb408acb808060ae0bb95a67339655ca5","unresolved":false,"context_lines":[{"line_number":1177,"context_line":"#. The VFIO driver traps BAR0 writes and dispatches to the NVMe emulator."},{"line_number":1178,"context_line":"#. On VF close, storage is zeroed for multi-tenant data isolation."},{"line_number":1179,"context_line":""},{"line_number":1180,"context_line":"NVMe host → VFIO handoff"},{"line_number":1181,"context_line":"-------------------------"},{"line_number":1182,"context_line":""},{"line_number":1183,"context_line":"Only one VF at a time may be handed from the host ``nvme`` driver to VFIO"}],"source_content_type":"text/x-rst","patch_set":31,"id":"df4e8379_d99c8f8a","line":1180,"updated":"2026-09-08 11:01:28.000000000","message":"The added \u0027NVMe host -\u003e VFIO handoff\u0027 section and the new test_nvme_data_persistence.sh assert that guest-written data survives VFIO close and is readable after the VF returns to the host nvme driver. The same developer guide (line 1178, \u0027VFIO NVMe guest flow\u0027) still states \u0027On VF close, storage is zeroed for multi-tenant data isolation.\u0027 The code does not zero: pci_sim_nvme_vfio_close() calls pci_sim_nvme_cleanup(), which only closes backing_fp; the zeroing pci_sim_nvme_close() is not on the VFIO path. The changed file is now internally contradictory.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Contributors reading the guide cannot tell whether VF data is wiped at guest exit; someone relying on the zeroing claim for multi-tenant isolation would pass guest data across tenants, while someone relying on the new section expects persistence.\n\n**Suggestion**:\nUpdate the \u0027VFIO NVMe guest flow\u0027 step to match the code: state that the backing file persists across VF close (wiped only by guest-issued sanitize/format or module cleanup), or restore actual zeroing on close if isolation-by-default was the intended contract and drop the persistence expectation.","commit_id":"37e98285e2188b48f7f181467e7aab60776b3e0c"},{"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":"2df24ac08d53b4a9ea573682590fd2c02724be67","unresolved":false,"context_lines":[{"line_number":1175,"context_line":"   (Identify, Create CQ/SQ, Set Features)."},{"line_number":1176,"context_line":"#. Guest performs I/O through submission/completion queue doorbells."},{"line_number":1177,"context_line":"#. The VFIO driver traps BAR0 writes and dispatches to the NVMe emulator."},{"line_number":1178,"context_line":"#. On VF close, the backing file persists (data survives across guest"},{"line_number":1179,"context_line":"   sessions).  Guests may issue NVMe Sanitize or Format NVM commands to"},{"line_number":1180,"context_line":"   wipe data explicitly; module unload cleans up all backing files."},{"line_number":1181,"context_line":""}],"source_content_type":"text/x-rst","patch_set":32,"id":"97d60978_49453bb6","line":1178,"updated":"2026-09-08 13:17:54.000000000","message":"The rewritten VFIO close section states: \u0027On VF close, the backing file persists (data survives across guest sessions)... module unload cleans up all backing files.\u0027 No code path in the module deletes backing files. pci_sim_nvme_cleanup() (fake_pci_sriov_nvme.c:1536-1543) only filp_close()s the file, and the module exit path (fake_pci_sriov_exit -\u003e fake_pci_remove_all_hosts) never unlinks anything. cleanup_fake_pci_sriov.sh has no reference to nvme_backing_file or the default /tmp/pci-sim-nvme.* files either. The default nvme_backing_file is /tmp/pci-sim-nvme (fake_pci_sriov_core.c:30), so guest-written data silently survives module unload and unattended reboots only.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Contributors running the new persistence flow will assume guest data is wiped when the module is removed; stale /tmp/pci-sim-nvme.* files with previous guests\u0027 NVMe contents are left on shared dev/CI hosts, defeating the isolation expectation the old wording described and causing confusing carry-over data on the next run.\n\n**Suggestion**:\nEither delete the backing files in pci_sim_nvme_cleanup (or a module-exit walk over VF indices, e.g. via kernel_unlink/filp_unlink under the module parameter path) or reword the guide to say data persists until the backing files are manually removed, and note where they live (/tmp/pci-sim-nvme.\u003cvf_index\u003e by default).","commit_id":"b6c3e5396b7f171c9b8799dfdca1e8dcef5d9873"}],"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":"f9552ab72b6059f7ea621ec3f1a757ce311ff0cb","unresolved":false,"context_lines":[{"line_number":133,"context_line":"echo path, and then deletes the test VM and tagged floating IP.  Use"},{"line_number":134,"context_line":"``--cleanup`` to remove leftovers from interrupted runs."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"DevStack Nova/Cyborg NVMe passthrough test"},{"line_number":137,"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"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"After stacking with ``PCI_SIM_DEVICES\u003d\"cyborg:nvme\"`` (or ``nova:nvme``),"}],"source_content_type":"text/x-rst","patch_set":2,"id":"a8f86261_c4f29b5b","line":136,"updated":"2026-08-06 09:43:55.000000000","message":"The new \u0027DevStack Nova/Cyborg NVMe passthrough test\u0027 section in testing.rst instructs users to run tools/run-devstack-nvme-passthrough-test.sh, but that script does not exist anywhere in the repository.\n\n**Severity**: WARNING | **Confidence**: 1.0\n\n**Impact**: Users following the documentation will encounter a \u0027No such file or directory\u0027 error, undermining trust in the documentation and blocking the documented workflow.\n\n**Suggestion**:\nEither add the referenced tools/run-devstack-nvme-passthrough-test.sh script or remove the documentation section until the script is available.","commit_id":"b83f88e0832852e91855e958d376e9a5f89bcb04"}],"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":"5922ec24155eedccc69e2b164412baeb53f0cdac","unresolved":false,"context_lines":[{"line_number":488,"context_line":"\tpci_unregister_driver(\u0026pci_sim_nvme_host_driver);"},{"line_number":489,"context_line":"\tpci_sim_nvme_host_unregister();"},{"line_number":490,"context_line":"\tpci_unregister_driver(\u0026pci_sim_vfio_driver);"},{"line_number":491,"context_line":"\tcancel_work_sync(\u0026pci_sim_nvme_handoff_work);"},{"line_number":492,"context_line":"\tpci_sim_tty_unregister_driver();"},{"line_number":493,"context_line":""},{"line_number":494,"context_line":"\tiommu_device_unregister(\u0026fake_iommu_dev);"}],"source_content_type":"text/x-csrc","patch_set":4,"id":"53f02154_61b23c00","line":491,"updated":"2026-08-07 08:49:33.000000000","message":"On module unload, cancel_work_sync may cancel a pending handoff work item. When the work function never runs, the pci_dev reference taken by pci_dev_get in pci_sim_vfio_close_device is never released via pci_dev_put, leaking the reference count on the pci_dev structure.\n\n**Severity**: SUGGESTION | **Confidence**: 0.8\n\n**Benefit**: On module unload with a pending handoff (VF just closed, work not yet executed), the pci_dev structure leaks a reference count. For a test fixture this is low-impact, but it is a concrete resource leak that a reviewer familiar with kernel lifecycle would note.\n\n**Recommendation**:\nAfter cancel_work_sync, drain the pending pointer: add \u0027pci_sim_nvme_handoff_pending \u003d NULL;\u0027 under the handoff lock and if the old value was non-NULL, call pci_dev_put() on it. Alternatively, check the return value of cancel_work_sync (true means work was pending) and release the pending reference if so.","commit_id":"45d6aee6924cc65f30a6bd2847bc383e5dace922"},{"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":"802a6ec49a5a3ae2a9883845e65fc581fe90876f","unresolved":false,"context_lines":[{"line_number":488,"context_line":"\tpci_unregister_driver(\u0026pci_sim_nvme_host_driver);"},{"line_number":489,"context_line":"\tpci_sim_nvme_host_unregister();"},{"line_number":490,"context_line":"\tpci_unregister_driver(\u0026pci_sim_vfio_driver);"},{"line_number":491,"context_line":"\tcancel_work_sync(\u0026pci_sim_nvme_handoff_work);"},{"line_number":492,"context_line":"\tpci_sim_tty_unregister_driver();"},{"line_number":493,"context_line":""},{"line_number":494,"context_line":"\tiommu_device_unregister(\u0026fake_iommu_dev);"}],"source_content_type":"text/x-csrc","patch_set":7,"id":"b2c9057b_8e7d6748","line":491,"updated":"2026-08-11 11:12:36.000000000","message":"The NVMe handoff deferred work acquires a pci_dev reference via pci_dev_get() in close_device and stores it in pci_sim_nvme_handoff_pending. The work function releases it with pci_dev_put(). However, if cancel_work_sync() in module exit cancels a pending (not-yet-running) work item, the work func...\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: If a guest is destroyed and the module is immediately unloaded before the workqueue runs, the pci_dev kref leaks. This prevents the pci_dev structure from being freed and can cause problems if the module is reloaded. The window is narrow but reachable in test/CI scenarios.\n\n**Suggestion**:\nAfter cancel_work_sync() in fake_pci_sriov_exit, check and release the pending reference: \u0027cancel_work_sync(\u0026pci_sim_nvme_handoff_work); if (pci_sim_nvme_handoff_pending) { pci_dev_put(pci_sim_nvme_handoff_pending); pci_sim_nvme_handoff_pending \u003d NULL; }\u0027","commit_id":"20d852e26b1d22e84c74bddf1a4d3472482ab058"}],"pci-sim/fake_pci_sriov_vfio.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":"06010c6dde19a46460b449746ab71eae1cb28d98","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"\tif (do_handoff) {"},{"line_number":138,"context_line":"\t\tmutex_lock(\u0026pci_sim_nvme_handoff_lock);"},{"line_number":139,"context_line":"\t\tpci_sim_nvme_handoff_pending \u003d pci_dev_get(sim-\u003ecore.pdev);"},{"line_number":140,"context_line":"\t\tmutex_unlock(\u0026pci_sim_nvme_handoff_lock);"},{"line_number":141,"context_line":"\t\tschedule_work(\u0026pci_sim_nvme_handoff_work);"},{"line_number":142,"context_line":"\t}"}],"source_content_type":"text/x-csrc","patch_set":3,"id":"9889ea1f_1aca27ff","line":139,"updated":"2026-08-06 13:50:56.000000000","message":"In pci_sim_vfio_close_device, pci_sim_nvme_handoff_pending is unconditionally overwritten with pci_dev_get(sim-\u003ecore.pdev) whenever do_handoff is true. If a previous handoff work is still queued (not yet executed), the previous pci_dev reference stored in pci_sim_nvme_handoff_pending is overwritt...\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: Leaked pci_dev references accumulate when two NVMe VFs are used sequentially without waiting for handoff work to complete. On systems with multiple VFs (the test script sets NUM_VFS\u003d2), this can cause kernel reference count leaks, potentially preventing clean module reload or causing kernel warni...\n\n**Suggestion**:\nBefore assigning pci_sim_nvme_handoff_pending, check if it is already non-NULL and call pci_dev_put on the previous value. Alternatively, call flush_work(\u0026pci_sim_nvme_handoff_work) before allowing a new VFIO open to ensure the previous handoff completes first.","commit_id":"8b71a3cf41ddc57f2b73646714e5e605a2e2160f"},{"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":"56d97e1b0a7663b41b9a489b98d2af74b789cd46","unresolved":false,"context_lines":[{"line_number":134,"context_line":""},{"line_number":135,"context_line":"\tvfio_pci_core_close_device(core_vdev);"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"\tif (do_handoff) {"},{"line_number":138,"context_line":"\t\tmutex_lock(\u0026pci_sim_nvme_handoff_lock);"},{"line_number":139,"context_line":"\t\tpci_sim_nvme_handoff_pending \u003d pci_dev_get(sim-\u003ecore.pdev);"},{"line_number":140,"context_line":"\t\tmutex_unlock(\u0026pci_sim_nvme_handoff_lock);"}],"source_content_type":"text/x-csrc","patch_set":10,"id":"b6b50c2e_a934d873","line":137,"updated":"2026-08-12 17:14:18.000000000","message":"The handoff work\u0027s pending pointer (pci_sim_nvme_handoff_pending) acquires a pci_dev_get reference in close_device but can be overwritten by a subsequent close or left set when cancel_work_sync cancels the work, leaking the pci_dev_get reference in both cases.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: A leaked pci_dev_get reference prevents the PCI device reference count from reaching zero, which can block proper device cleanup during repeated test cycles or module reload. In the concurrent-close path, the leaked reference is on a specific VF device that may never be properly cleaned up. For a...\n\n**Suggestion**:\nAdd a guard in close_device to check if pending is already set and release the previous reference before overwriting: if (pci_sim_nvme_handoff_pending) pci_dev_put(pci_sim_nvme_handoff_pending);. For the module-unload path, add a cleanup step after cancel_work_sync in fake_pci_sriov_exit (or a small helper exported from vfio.c) that checks and releases any residual pending reference.","commit_id":"bbf1820e6246a0718955fb2e375e813250724eae"},{"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":"6a6c222acdc3c6b07d03deb148d3113e443e96a9","unresolved":false,"context_lines":[{"line_number":24,"context_line":"static struct pci_dev *pci_sim_nvme_handoff_pending;"},{"line_number":25,"context_line":"struct work_struct pci_sim_nvme_handoff_work;"},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"void pci_sim_nvme_handoff_work_fn(struct work_struct *work)"},{"line_number":28,"context_line":"{"},{"line_number":29,"context_line":"\tstruct pci_dev *pdev;"},{"line_number":30,"context_line":"\tconst char *drv_name;"}],"source_content_type":"text/x-csrc","patch_set":13,"id":"0c2922c1_49f8803a","line":27,"updated":"2026-08-14 17:52:47.000000000","message":"pci_sim_nvme_handoff_work_fn() swaps the pending pointer under pci_sim_nvme_handoff_lock, then polls up to 4s (40 x msleep(100)) outside the mutex, while open_device()/close_device() take the same mutex and close_device() can re-arm pci_sim_nvme_handoff_pending and schedule_work() while the worke...\n\n**Severity**: CRITICAL | **Confidence**: 0.9\n\n**Risk**: Under concurrent VFIO open/close of NVMe VFs (one guest exiting while another boots, or repeated bind/unbind), a handoff can be silently dropped (pending overwritten), the system workqueue worker is pinned for 4s, and module unload can stall for ~4s.\n\n**Priority**: Immediate\n**Why This Matters**: Under concurrent VFIO open/close of NVMe VFs (one guest exiting while another boots, or repeated bind/unbind), a handoff can be silently dropped (pending overwritten), the system workqueue worker is pinned for 4s, and module unload can stall for ~4s.\n\n**Recommendation**:\nRun the rebind wait on a dedicated single-thread workqueue so the poll does not pin system_wq; serialize pending handoffs (list, or a busy flag checked under the mutex before arming pending); re-check pending after the poll loop so a handoff armed while the worker polled is not lost; flush the work before unregistering the VFIO driver in module exit.","commit_id":"44e91a755138621acbb9675d2d93ddc61c0b9918"},{"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":"6a6c222acdc3c6b07d03deb148d3113e443e96a9","unresolved":false,"context_lines":[{"line_number":107,"context_line":"err_disable:"},{"line_number":108,"context_line":"\tvfio_pci_core_disable(\u0026sim-\u003ecore);"},{"line_number":109,"context_line":"err_handoff:"},{"line_number":110,"context_line":"\tif (sim-\u003eops \u003d\u003d \u0026pci_sim_nvme_ops) {"},{"line_number":111,"context_line":"\t\tmutex_lock(\u0026pci_sim_nvme_handoff_lock);"},{"line_number":112,"context_line":"\t\tpci_sim_nvme_handoff_owner \u003d NULL;"},{"line_number":113,"context_line":"\t\tmutex_unlock(\u0026pci_sim_nvme_handoff_lock);"}],"source_content_type":"text/x-csrc","patch_set":13,"id":"bbf513e0_b76c88dc","line":110,"updated":"2026-08-14 17:52:47.000000000","message":"The err_handoff block in pci_sim_vfio_open_device() unconditionally sets pci_sim_nvme_handoff_owner \u003d NULL when a later open stage fails, without verifying the owner equals sim-\u003ecore.pdev - unlike close_device() in the same patch, which checks ownership before acting. If any path reaches err_hand...\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: The single-owner handoff invariant can be violated, allowing two NVMe VFs to be assigned simultaneously or leaving the lock pointing at a stale owner until module reload.\n\n**Suggestion**:\nMirror close_device(): in the err_handoff block, only clear the owner if pci_sim_nvme_handoff_owner \u003d\u003d sim-\u003ecore.pdev. Two-line change that makes the invariant explicit and refactor-safe.","commit_id":"44e91a755138621acbb9675d2d93ddc61c0b9918"},{"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":"aa229b665ee2467992b33358dcbd23ce32c5f53f","unresolved":false,"context_lines":[{"line_number":38,"context_line":"\tif (!pdev)"},{"line_number":39,"context_line":"\t\treturn;"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"\tdevice_set_driver_override(\u0026pdev-\u003edev, NULL);"},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"\tret \u003d device_reprobe(\u0026pdev-\u003edev);"},{"line_number":44,"context_line":"\tif (ret) {"}],"source_content_type":"text/x-csrc","patch_set":28,"id":"f8751447_881f5a64","line":41,"updated":"2026-09-04 08:48:55.000000000","message":"The new handoff code calls device_set_driver_override() unconditionally with no compat gate. That helper and its exported backing symbol __device_set_driver_override() are absent from every released kernel checked (v6.12 through v6.19 drivers/base/dd.c and include/linux/device.h); it exists only in current mainline. fake_pci_sriov_compat.h explicitly documents that the module supports 6.12 (Debian 13, CentOS Stream 10) and 6.15+ kernels and carefully gates other post-6.12 APIs with PCI_SIM_HAS_615_API, so building against any supported released kernel fails with an implicit-declaration error / undefined symbol for device_set_driver_override.\n\n**Severity**: HIGH | **Confidence**: 0.75\n\n**Impact**: On every kernel version the module claims to support (6.12 through at least 6.19), \u0027make modules\u0027 fails, so the module cannot be loaded at all on those systems and the project\u0027s make test-build/lint-build-warnings targets fail there. Only a current mainline/git kernel builds.\n\n**Priority**: Before merge\n**Recommendation**:\nGate the call in fake_pci_sriov_compat.h (e.g. reuse PCI_SIM_HAS_615_API-style version detection) and provide a fallback for older kernels, such as writing to the device\u0027s driver_override via the sysfs-style path used elsewhere, or clearing the override from the userspace scripts only and documenting that the automated handoff requires a newer kernel.","commit_id":"05d34c1a015ec50d3968251583af30678ba95bda"},{"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":"aa229b665ee2467992b33358dcbd23ce32c5f53f","unresolved":false,"context_lines":[{"line_number":38,"context_line":"\tif (!pdev)"},{"line_number":39,"context_line":"\t\treturn;"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"\tdevice_set_driver_override(\u0026pdev-\u003edev, NULL);"},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"\tret \u003d device_reprobe(\u0026pdev-\u003edev);"},{"line_number":44,"context_line":"\tif (ret) {"}],"source_content_type":"text/x-csrc","patch_set":28,"id":"3b444c15_49ef340b","line":41,"updated":"2026-09-04 08:48:55.000000000","message":"pci_sim_nvme_handoff_work_fn() calls device_set_driver_override(\u0026pdev-\u003edev, NULL) to clear the driver_override before reprobe. In the upstream kernel, __device_set_driver_override() begins with \u0027if (!s) return -EINVAL;\u0027 and its helper\u0027s documentation states an empty string (\"\"), not NULL, must be passed to clear the override. The return value is ignored, so the clear silently fails, driver_override stays set to \"pci_sim_vfio_pci\", and device_reprobe() re-binds the VF to pci_sim_vfio_pci itself. The subsequent 40x100ms poll only accepts \"nvme\" or \"pci_sim_nvme_host\", so it always times out and logs \"NVMe handoff: host driver did not rebind after 4s\". The automated host return path added by this change therefore cannot work.\n\n**Severity**: HIGH | **Confidence**: 0.85\n\n**Impact**: After a guest exits, the VF is re-bound to pci_sim_vfio_pci instead of the stock nvme driver; the VF stays assigned to the VFIO sim driver, host nvme never sees it again without manual sysfs intervention, and every guest teardown logs a spurious 4-second timeout warning. The change\u0027s primary stated purpose (automated VF return to host nvme) silently fails.\n\n**Priority**: Before merge\n**Recommendation**:\nPass an empty string instead of NULL and check the return value, e.g.: ret \u003d device_set_driver_override(\u0026pdev-\u003edev, \"\"); if (ret) { pci_warn(...); goto out; }. Update the test scripts accordingly, since they currently work around this by doing the unbind/override-clear/reprobe sequence from userspace themselves.","commit_id":"05d34c1a015ec50d3968251583af30678ba95bda"}],"pci-sim/run_nvme_vfio_guest_probe.py":[{"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":"027da03818edc01d42ee8575c817c64de3a35c47","unresolved":false,"context_lines":[{"line_number":51,"context_line":""},{"line_number":52,"context_line":"def launch_qemu(image: str, vf: str) -\u003e tuple[subprocess.Popen[bytes], int]:"},{"line_number":53,"context_line":"    \"\"\"Launch QEMU with ``vf`` assigned and return the process and PTY FD.\"\"\""},{"line_number":54,"context_line":"    qemu_bin \u003d os.environ.get(\"QEMU_BIN\", \"qemu-system-x86_64\")"},{"line_number":55,"context_line":"    cmd \u003d ["},{"line_number":56,"context_line":"        \"sudo\","},{"line_number":57,"context_line":"        \"-n\","}],"source_content_type":"text/x-python","patch_set":15,"id":"cff1364c_bcfa8a92","line":54,"updated":"2026-08-17 16:09:54.000000000","message":"launch_qemu() prefixes the QEMU command with \u0027sudo -n\u0027, so the guest process runs as root; the newly added override_creds() elevation for non-root QEMU users is therefore untested by every script added in this patch.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: The primary justification for the override_creds() change (non-root QEMU against a 0600 root-owned backing file) has no automated coverage, so regressions in that path (e.g. wrong creds scope, filp_open failing for the qemu user) would not be caught by the new tests.\n\n**Suggestion**:\nAdd a variant (env knob such as QEMU_AS_ROOT\u003d0) that launches QEMU as an unprivileged user (e.g. sudo -u qemu or runuser) and asserts the VFIO open still succeeds, or document explicitly in the script header that the non-root path is validated manually elsewhere.","commit_id":"04b150486200f659f36979d03e8317c726e2cfea"},{"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":"de9a0a9d3eae74d60f1888fbde61bf5b3bb945ec","unresolved":false,"context_lines":[{"line_number":51,"context_line":""},{"line_number":52,"context_line":"def launch_qemu(image: str, vf: str) -\u003e tuple[subprocess.Popen[bytes], int]:"},{"line_number":53,"context_line":"    \"\"\"Launch QEMU with ``vf`` assigned and return the process and PTY FD.\"\"\""},{"line_number":54,"context_line":"    qemu_bin \u003d os.environ.get(\"QEMU_BIN\", \"qemu-system-x86_64\")"},{"line_number":55,"context_line":"    cmd \u003d ["},{"line_number":56,"context_line":"        \"sudo\","},{"line_number":57,"context_line":"        \"-n\","}],"source_content_type":"text/x-python","patch_set":25,"id":"5ae4a81b_a0e55f99","line":54,"updated":"2026-09-01 12:18:47.000000000","message":"The commit message justifies elevating fsuid/fsgid to root around the backing-file filp_open()/vfs_truncate() in pci_sim_nvme_init() because \u0027QEMU runs as a non-root user that cannot access the 0600 backing file\u0027. However, the shipped end-to-end harness never runs QEMU as a non-root user: run_nvme_vfio_guest_probe.py builds the QEMU command as [\"sudo\", \"-n\", qemu_bin, ...], and test_nvme_data_persistence.sh drives that same helper (it must already run as root). With QEMU running as root the backing-file open would succeed without any credential override, so the scenario the kernel change exists for is dead code in the only flow the change ships.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: The stated motivation for a privileged-credential code path in the kernel module is never exercised by any shipped test, so the non-root scenario is unvalidated; contributors following the docs will also conclude sudo-launched QEMU is the intended mode, which is heavier than needed for a downloaded cloud image and diverges from how a real Cyborg/libvirt deployment assigns devices.\n\n**Suggestion**:\nPick one and make code, docs and message agree: either drop sudo from launch_qemu() (run QEMU as the invoking user, which actually exercises the fsuid elevation and matches the commit message), or keep sudo and update the commit/doc text to say QEMU runs as root and the elevation is a safety net for non-root launches. Add a sentence to the developer-guide handoff section describing the intended privilege mode.","commit_id":"5f1c29e27702391d91288d1cd7373069b0de45aa"},{"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":"67d40fba7ef6abe8ffbc6ca5d1747fc0c55fabd3","unresolved":false,"context_lines":[{"line_number":149,"context_line":"            sent \u003d True"},{"line_number":150,"context_line":"            buf \u003d \"\""},{"line_number":151,"context_line":"            continue"},{"line_number":152,"context_line":"        if \"GUEST_NVME_END\" in buf:"},{"line_number":153,"context_line":"            failures \u003d re.findall(r\"GUEST_NVME_FAIL_(\\S+)\", buf)"},{"line_number":154,"context_line":"            if failures:"},{"line_number":155,"context_line":"                print(f\"\\nFailed checks: {\u0027, \u0027.join(failures)}\", flush\u003dTrue)"}],"source_content_type":"text/x-python","patch_set":34,"id":"8f047d07_4e3b0cbd","line":152,"updated":"2026-09-09 07:18:34.000000000","message":"run_guest_commands() writes the entire GUEST_COMMANDS block to the serial console in one os.write() and then scans the accumulated output buffer for GUEST_NVME_FAIL_* and GUEST_NVME_END. The guest tty echoes input as it is received, so the injected script is echoed back before its own first line (\u0027stty -echo\u0027) can execute. The echoed text contains the literal marker strings, so the failure scan finds GUEST_NVME_FAIL_lsblk, GUEST_NVME_FAIL_id-ctrl, etc. in the echo of the commands themselves and returns False even when every guest-side check passes.\n\n**Severity**: HIGH | **Confidence**: 0.8\n\n**Impact**: The new NVMe VFIO guest probe prints \u0027Failed checks: lsblk, id-ctrl, ...\u0027 and exits non-zero on essentially every run, even when all guest probes succeed, defeating the change\u0027s stated purpose of validating the passthrough flow end to end.\n\n**Priority**: Before merge\n**Recommendation**:\nSuppress echo before sending the marker-producing block: send \u0027stty -echo\u0027 as its own command and wait for the shell prompt before sending GUEST_COMMANDS; additionally exclude the sent text from the evaluated buffer (e.g. only scan output received after a freshly echoed sentinel with a per-run nonce) so only real command output is scored.","commit_id":"38d27c8b1a85aca071f83f12e33978cfff36c63a"}],"pci-sim/test_nvme_data_persistence.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":"e0748030830f36e758d9ed20c03f3f92058e2b84","unresolved":false,"context_lines":[{"line_number":77,"context_line":"fi"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"# Parse memmap\u003d from /proc/cmdline"},{"line_number":80,"context_line":"MEMMAP_ENTRY\u003d$(grep -oP \u0027memmap\u003d\\S+\u0027 /proc/cmdline | head -1)"},{"line_number":81,"context_line":"if [ -z \"$MEMMAP_ENTRY\" ]; then"},{"line_number":82,"context_line":"    echo \"ERROR: no memmap\u003d kernel boot param — stock nvme cannot bind\""},{"line_number":83,"context_line":"    echo \"       add memmap\u003dSIZE\\$START to kernel cmdline and reboot\""}],"source_content_type":"text/x-sh","patch_set":9,"id":"472ababf_6574cde1","line":80,"updated":"2026-08-12 11:55:16.000000000","message":"On line 80, the pipeline `grep -oP \u0027memmap\u003d\\S+\u0027 /proc/cmdline | head -1` is used in a command substitution assignment. Under `set -euo pipefail`, if /proc/cmdline does not contain `memmap\u003d`, grep exits with status 1. With pipefail, the pipeline returns 1, and under set -e the assignment command f...\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: When the system lacks a memmap\u003d boot parameter, the user sees an unhelpful `pipefail` abort instead of the intended guidance: \u0027add memmap\u003dSIZE$START to kernel cmdline and reboot\u0027. This makes debugging test failures harder.\n\n**Suggestion**:\nAppend `|| true` to the pipeline to suppress the non-zero exit, e.g.: `MEMMAP_ENTRY\u003d$(grep -oP \u0027memmap\u003d\\S+\u0027 /proc/cmdline | head -1 || true)`. This allows the `if [ -z \"$MEMMAP_ENTRY\" ]` check on line 81 to handle the missing-parameter case as intended.","commit_id":"1f031d3cac6a1064d428b58046d0a441a344d627"},{"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":"6a6c222acdc3c6b07d03deb148d3113e443e96a9","unresolved":false,"context_lines":[{"line_number":339,"context_line":"msg \"Phase 3: Guest destroyed — verify data on host\""},{"line_number":340,"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":341,"context_line":""},{"line_number":342,"context_line":"# Unbind VF from VFIO, clear override, let stock nvme rebind"},{"line_number":343,"context_line":"if [ -e \"/sys/bus/pci/devices/$VF_BDF/driver/unbind\" ]; then"},{"line_number":344,"context_line":"    echo \"$VF_BDF\" \u003e \"/sys/bus/pci/devices/$VF_BDF/driver/unbind\""},{"line_number":345,"context_line":"fi"}],"source_content_type":"text/x-sh","patch_set":13,"id":"dd9af146_2324fee5","line":342,"updated":"2026-08-14 17:52:47.000000000","message":"Phase 3 of the persistence test manually unbinds the VF from pci_sim_vfio_pci, clears driver_override, and reprobes - replicating in shell what the kernel handoff work introduced by this same patch is supposed to do automatically on VFIO close. The script neither waits for nor asserts the kernel-...\n\n**Severity**: HIGH | **Confidence**: 0.8\n\n**Risk**: Regressions in the patch\u0027s core automatic-handoff mechanism are hidden by the shell fallback, and the sysfs writes can race the deferred worker producing flaky results.\n\n**Priority**: Before merge\n**Why This Matters**: Regressions in the patch\u0027s core automatic-handoff mechanism are hidden by the shell fallback, and the sysfs writes can race the deferred worker producing flaky results.\n\n**Recommendation**:\nIn Phase 3, poll the driver symlink for up to the worker\u0027s ~4s budget and assert the rebind happened without manual unbind/override-clear; keep the manual path only as a documented fallback after the wait times out.","commit_id":"44e91a755138621acbb9675d2d93ddc61c0b9918"}]}