From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: vfio/pci: Clean up BAR zap and revocation Date: Thu, 28 May 2026 12:28:53 +1000 Message-ID: In-Reply-To: <20260527102319.100128-7-mattev@meta.com> References: <20260527102319.100128-1-mattev@meta.com> <20260527102319.100128-7-mattev@meta.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review Consolidates `vfio_pci_zap_bars()` + `vfio_pci_dma_buf_move()` into `vfio_pci_zap_revoke_bars()`. Clean refactoring. **`vfio_pci_ioctl_reset` change**: The lock acquisition changes from `vfio_pci_zap_and_down_write_memory_lock` (which did lock+zap atomically) to separate `down_write` + `vfio_pci_zap_revoke_bars`: ```c - vfio_pci_zap_and_down_write_memory_lock(vdev); + down_write(&vdev->memory_lock); ... - vfio_pci_dma_buf_move(vdev, true); + vfio_pci_zap_revoke_bars(vdev); ``` This moves the zap/revoke to *after* the D0 power transition, which the changelog notes. This is intentional per the v2 notes but is a behavioral change worth PCI maintainer attention. **`bar_needs_zap` flag**: Set in nvgrace-gpu but never cleared. This means once any nvgrace-gpu BAR is mmap'd, the zap path will always fire even after that BAR is unmapped. The FIXME acknowledges this, and the overhead is minimal (an extra `unmap_mapping_range` on an empty range), so this is acceptable as an interim solution. --- Generated by Claude Code Patch Reviewer